This post comes courtesy of a direct request from one of my supporters over at Patreon, who asked me if I could give them a 10,000 foot-level overview of the Product Lifecycle from ideation to delivery. While nothing here should be terribly earth-shattering or world-changing, I think it’s important for us as Product Managers to stop on occasion and think about how things should work for us from the point of an idea to the days supporting a thriving product. So here’s my personal take on the subject — as always, if you have thoughts or comments, feel free to drop them here or hit me up on Twitter!
Discovery
Discovery is the phase during which you’re actively seeking out information about your customers and your market – the precise definition of which may change as the process. In this phase, we’re mostly interested in asking open-ended questions of those whom we think might have a problem that’s worth solving. Our goal is to collect and collate this feedback into some form that we can analyze and determine what the biggest problems this market has, so that we can then think about solutions that we might be able to deliver to them based upon these problems. The primary output of this phase is a list of problems and struggles that your potential market experiences. A secondary output of this phase might be user and/or buyer personas, which help you to focus on archetypes within your market in later phases.
Ideation
Ideation is the stage where we’re taking the information that we got during Discovery and actually starting to think critically about what we’ve learned. We should have a vague idea of the problem or problems that we want to solve, and this is where we start digging into the solutions that we might provide. We need to be especially critical about the assumptions that we’re making about our customers, market, and solution, and be sure that we’re creating testable hypotheses around these assumptions so that we can prove ourselves right or wrong. We also need to be very aware of the wide variety of risks that we might face in building our solutions and create hypotheses to test those as well. The output of this phase is a list of testable hypotheses that you’ve developed based on what you understand about the market and their needs.
Confirmation
Confirmation is the process of taking those hypotheses that we’ve created during Ideation and taking them out to the market to test them. This is an iterative process, because we’re likely to learn new things about the market when we test our hypotheses, which will lead to more discovery, which will lead to more ideation, which will lead to more confirmation. This is the phase during which you’re going to want to start developing your concept of your MVP – so that you don’t get stuck in “analysis paralysis” and remain in a discovery/ideation/confirmation loop that never ends. The output of this phase should be a list of problems and solutions that you’ve confirmed are valuable to the market.
Prioritization
Once we’ve got a list of the things that we want to do, we need to put them in some form that we can being actually executing against. We can’t possibly do everything that we want to do, all at once – so we need to ensure that we’re making some form of prioritized list from the problems and solutions that we’ve collected so far. We should also do a quick check back to the market to ensure that what we think is the most important aligns with what they think is the most important. We can prioritize against any number of metrics or factors that we want – I usually like to keep these small, light, and somewhat subjective. My preferred list would be: Customer Value, Technical Complexity, and Competitive Advantage. Plot your solutions against these three axes, assign them some numeric value, and see what comes out on top. Validate that with your customer segment, and you should be good to go. The output of this phase should be a prioritized list of solutions that you’re ready to start designing.
Design
Once we’ve got our prioritized list of solutions that we want to deliver, we know what the first thing is that we want to do…and the second…and the third…etc. This means that we need to start the process of actually designing the solution. So we take all the data that we’ve collected and start piecing together the technical definition that’s necessary for our teams to start work on. Different companies will expect different levels of specification – some will require complex Business Requirement Documents, others might just need a backlog of well-written User Stories. The point here is that you shouldn’t start designing something until you know that you’re ready to start working on it, and you’ve confirmed that there’s actual value to be had in doing the thing. A lot of Product Management teams wind up wasting time and energy (not just their own) putting together specifications for things that might be done sometime in the future, rather than focusing on the things that they know that they want to do now. Don’t fall into that trap – technology and markets change too fast to even consider writing requirements for something that’s not going to be started for 6, 9, or 12 months. Also, don’t fall into the trap of doing your design work in a vacuum – involving your UX team, your architecture team, your marketing team, your support team, and even your development teams in the Design process is essential to ensuring success. The sooner you can confirm or disprove the feasibility of your solution, wherever that feedback comes from, the better and the cheaper it is. Also, the more people are involved in the Design phase, the easier it is to manage expectations during the Implementation phase. The output of this phase is going to be the specifications necessary to hand something over to the development team to actually build.
Implementation
This is where the rubber meets the road, and where most people focus not only their attention, but the vast majority of their efforts – neglecting so many of the steps that need to come before this. In some ways, though, this is the “fun” part, because we get to work with teams who are actually making our ideas come to life! This is the home of the sprint, of the reviews and negotiations, of protecting the scope of your MVP while making sure people feel heard and understood. This is the most critical part of the process in many ways – but remember that it’s also the most expensive. The sooner we can de-risk our implementation work, the better. We also need to keep in mind (and in the minds of everyone involve din implementation) that our goal is not just to deliver what’s been designed – but to deliver a valuable solution to an actual problem the customer is facing. If there’s a better way to do it, we should consider it. If there’s skepticism that what we’re doing solves the problem, let’s address it. We don’t want to cut something that we’ve started working on, but we must go where the data tells us, and sacrifice our egos on the altar of customer empowerment when necessary. The output of this phase is going to be our actual, marketable solution.
Release
Now we’re getting excited! Our Implementation teams are delivering on a regular cadence, showing off their hard work to everyone involved and interested, and we’re getting closer and closer to actually putting our solution out there and making it a “real” product. But it requires more than just a finished product to be successful in this day and age – we need to make sure that we have the right go-to-market plan around that solution so that it leaves our doors with the best chance to succeed that we can give it! The most important thing to remember about Release is that it needs to be a continuous process from day one of the Implementation phase – in fact these two phases are not so much serial as parallel paths that the development of our solution has to take. We need to make sure as Product Managers that we’re enabling our Marketing and Sales team to fully understand the problems that we’re solving, the solutions that we’re delivering, and most importantly what the valueis of these solutions to the customer. We’ve all seen sales teams struggling to sell “value” and relying on “features” to close the deal – and this is as much our fault as it is theirs, because all too often we’ve done a poor job as Product Managers actually describing the value to Marketing and Sales, considering it “their job” to figure that out. Instead, we should be delivering regular updates to those teams regarding not only what we’re building but why we’re building it and what value our customers will get from it. If you can’t quickly describe the feature/benefit breakdown of what you’re working on, you’re either not working on the right thing, or you haven’t done the right preparation for building it in the first place. We need to work with our Sales and Marketing teams to understand what their go-to-market strategy is, so that we can provide feedback and supporting information for them to achieve success, and in turn allow our product to achieve success. The output of this phase is going to be your go-to-market strategy, as well as any supporting collateral that’s needed by the Sales & Marketing teams to succeed.
Sustainment
Finally, we’ve launched! Hooray, people are buying the product, customers are happy, sales people are making their commissions, etc. But our work doesn’t stop there as Product Managers – we need to ensure that we’re working closely with our technical sales teams, with our support teams, and even with our internal services teams to hear what they’re hearing back from the people who are actually buying and using the product. This is the most critical phase for finding out where you’ve missed some critical need that slipped through the cracks, and adjusting the plan (and the product) as soon as possible. It’s also the beginning of your next product cycle, as this is where your Discovery starts all over again. The outputs from this phase are numerous, but the most important is new information, ideas, and problems from your market to start all over with.
