Welcome to Product Management Challenges!
Welcome to real-world advice for software product management! Subscribers have access to a treasure trove of over 100 articles covering the full range of topics that a product manager must master. Start your paid subscription to this unmatched content by clicking Subscribe to the right, under Log In.
Recent Articles
07002 The Four Phases of Implementation
March 29, 2007
In today’s issue I’m going to write about something that is near and dear to my heart, something that I have found tremendously helpful working with customers to implement new software and working on my own and with teammates to make important things happen. It’s a way to understand the psychological stages which you – and everyone else I have ever met – go through when you work on a major new undertaking such as buying and implementing a software product. I call it the Four Phases of Implementation.
The Four Phases of Implementation is by no means my original idea. I first read about it in a book about proposal writing, I believe, and I believe the author did not claim the idea as his own. Rather, he was passing along an idea that was widespread. I, however, had never heard it before, and have found it extremely helpful ever since.
I have found the Four Phases of Implementation to be so useful, in fact, that at my current company I started paying a visit to each and every class of trainees in our product for the express purpose of describing the Four Phases. I know that by imparting this information to my customers, I can help them better work through the implementation of our software product. Not only does it help them directly, but I charge them with taking the Four Phases idea and walking their teammates through it when they get back at the office, all in the interest of making our product easier to adopt and making its implementation more successful.
Read on below for a description of the Four Phases of Implementation.
07001 Ten Myths About Software Requirements
March 15, 2007
Again and again, I see organizations struggle with requirements, that component of making software where the needs and desires for new and changed capabilities are defined and handed to Development to build into the product. The challenges stem from one or more important misconceptions about requirements. These misconceptions in turn prevent the team in various ways from providing, creating, selecting, or transmitting requirements so that work can begin on enhancing the product.
Read on for a discussion of ten common misconceptions about requirements that hold organizations back from good requirements and more effective product development.
Recent Discussions