3 Steps to Mastering the Product Lifecycle

When we think of the Product Lifecycle, a common image to grasp is that of the upwards line curve that goes from  Product Introduction, Growth and into Product Maturity and finally on to the decline. In a conventional product  lifecycle, these are indeed the four phases of life of a product.

However, this hardly takes into consideration the real world evolution of a product or business that iterates and pivots to stay competitive. Look at AOL.com — in the early stages it was purely a business to get consumers connected to the internet. Now the product is all about content and very little about getting customers  connected. Sure this is truer with a business, but then core products, within the product lifecycle define the business.

So the point of this as you will see is to provide you a different vision of the product lifecycle. The image below, broken down and explained into individual components, demonstrates the evolving product which always starts with introduction, and might end with an end of life. However, the evolving product can have multiple  stages of maturity, and quite possibly multiple stages of introduction and growth as the product evolves and the  core business pivots.


It’s so easy to get sucked into the minutia when defining product releases, but DON’T DO IT! STOP WHAT YOU’RE  DOING!! Seriously, you are doing yourself a disservice by jumping into the details before you have laid out what you  want to achieve and the high level concepts. Write down on a napkin or a piece of paper brief objectives, some  ideas for what is important in the next product release (not just the full product).

As you move on down to the bottom right of the product  lifecycle triangle, your goal is to clearly define the product iteration. Getting there involves activities including iteration planning, roadmapping, writing out the business requirements and of course prioritization. Prioritization may be trickier because the critical trade-off is  cost to build versus potential revenue. (Cost-benefit modeling). However you get there, the deliverable should be a clear PRD (product requirements document) with use cases and/or wireframes.

Why do we need this? This PRD is used to communicate between business and technical teams. Do this wrong or  incomplete and the engineering team builds the wrong thing driving up costs. Being able to clearly articulate your requirements up front can mean the difference between success and failure in the lifecycle.


Now that you have a definition for your product release, relax for a minute and take a breath. Now all you have  to do is engage the engineering team and build it. You can equate this to taking a polished movie script and  turn it into a film. Think how easy it is to ruin a movie with a great script. Your challenge now is taking your  product definition and selling it to the engineering team. Your goal is for them to stay engaged, they can  visualize it and understand why it is you’re building it.

On the way from definition to product release are a slew of activities including overall project management, product design, engineering and wireframing. The most important thing to keep in mind is to keep the iteration  agile and concise so that the time to market is nothing more than 30 to 60 days. If it takes longer than this,  your iteration is getting too big and you may want to prune it down to something where 60% of the features are  in this release. That way you can get meaningful feedback to drive the next product iteration.

As a product manager, you need to be very much engaged at this stage. Be the project manager and keep your eyes  on the development milestones. Have multiple code drops so you can consistently provide feedack so when the  iteration is complete there are little to no surprises.

Also, for every product release you need to make sure there is a feedback loop for your customers. Have a link to a form where customers can provide feedback and report bugs. This will be invaluable information to give you  the feedback you need to drive future iterations. Without this, your ignoring the market and your customers who  you are building this for in the first place.


Now that you have a viable/tangible release in market, this is where the fun starts. The biggest mistake you can make is to  sit back and not watch the metrics and stay focused to how your customers (the market) reacts to the release.  It’s this information that will drive the subsequent releases and ultimately your product’s strategy.

Some of the things (if not all of these) that you should now be doing with this release are as follows:
1. If this is a marketing change which will impact customer acquisition, A:B Test the current version to see how  it performs. If it doesn’t perform well, throw it out and start over. Don’t waste time on something that  customers don’t care about.
2. For new features, are customers clicking on it, are they using it, if so, are they asking questions about it.  Is it clear?
3. Consider reaching out to some power customers, offer them a free month to get their feedback on the new  feature.
4. If the new feature is improving revenue, is there any impact on Churn? Nothing worse than getting more money  up front but eroding the life-time value of your customers.

The basic theme of the product lifecycle triangle is “test before invest”. That is, see how the iteration of the produce release  works before investing more of your valuable engineering resources. There is always a massive opportunity cost  at work here.  Invest your revenue back into the product the right way. You do this with smaller releases that  are testable and measurable. If you are building something that takes three months, prior to testing and  measuring, STOP, and reread.

Leave a Reply

Your email address will not be published. Required fields are marked *