The Product Discovery Plan
In my last article, I discussed the situation where Product Discovery is essentially not discovery at all, but rather just a mad dash of just-in-time spec writing so that the engineers can be kept busy. I discussed how important it is that the date not be driving everything at the expense of the value of what will be created.
In this article, I’d like to discuss the opposite problem. There are some companies that believe strongly in Product Discovery, but they waste precious time by not planning their work and ensuring that every day in discovery is getting the most learning possible, and that they are making rapid progress towards identifying the minimum viable product.
The level of precise planning required or desired is very much a function of the culture of the company and the skills of the people involved, but in many company cultures, especially larger companies, I find the team needs to create a “Product Discovery Plan” that spells out what the team believes must be done for this project, what resources are needed, and at least a rough timeframe.
What follows are common components of a product discovery plan. I don’t like for people to consider this a “template” because then teams tend to include things they really don’t need to do just because it’s in the template. Rather, think of this as a list of tools each for a different purpose, and your job is to select the right tools for the job. And your manager’s job is to review the plan and then ensure adequate progress is made.
- Discovery Core Team: At the very minimum, the product discovery plan should identify the product manager, lead designer and lead engineer for this project, and then ensure that these people are available for the product discovery activities.
- Discovery Extended Team: Who will be supporting the core team? Do you expect to need the help of a visual designer? Prototyping assistance? A usability testing resource? A specific developer? Someone from QA? Someone from marketing?
- Key Stakeholders: Who must approve this project (who has “veto power”)? Also this can include a list of just generally smart people that you think you should talk to about this project.
- Customer Development Plan: Will this project utilize a charter customer/user/application program? If so, who will be leading this? If not, who are the customers or users that you intend to validate your product ideas with?
- Key Risks: What are the key risks for this project and how to you intend to address them?
- User Research Tools: Does the project need to do some persona work? A review of the site and business analytics?
- User Testing Plan: How do you intend to test these product ideas on actual users? What is the preliminary testing schedule?
- Product Strategy/Vision: Does this area need a longer-term vision before the specific project can be defined?
- Product Principles: Does this area need its own set of product principles?
- Required Level of Supporting Documentation: The core team should agree on what level of additional documentation is required for this particular project – stories, use cases, test plans, etc.
So creating this plan is one step, but the bigger issue is usually ensuring that the product discovery team is actually making real progress towards minimum viable product, and converging on the point where you can begin building this product.
There are two parts to this progress tracking.
First, I argue that it is the job of the leaders of the product organization (head of product management and/or head of user experience) to be providing this level of very active oversight in terms of making real progress on identifying a strong product. To be clear about what I mean by “oversight” here are a set of questions I like to ask the product discovery team at least once a week:
- What customers and users have you actually talked to personally this week?
- What did you learn from these discussions? Were you surprised by anything you learned? What insights did you gain?
- Did you encounter any potential pivots (see http://www.svpg.com/your-business-plan-is-wrong/)?
- Based on what you learned, what are you going to try differently tomorrow?
- When was the last time the engineer on this team reviewed your work and your learnings?
- What feedback did the engineer have in terms of feasibility and also potential solutions?
- Are users responding to the value of this idea? If not, why not?
- What are the main usability issues with the current prototype? What do you intend to do to try to correct these problems?
- What are the areas of the prototype that the engineer is most nervous about in terms of feasibility, and what are your contingency plans on those?
- Overall, do you believe we can get to minimum viable product within two more weeks? If not, should we continue with this effort or move our focus to another opportunity?
The other area of oversight refers to the project management activities of making sure the product discovery plan is executed and that everything is prepared for implementation. This includes making sure that engineering has everything they need to begin work, understanding and managing any timing considerations, making sure there is good communication between engineering, product management and design, and in general moving things through the process and ensuring that time isn’t wasted.
A project manager can be a big help to everyone involved; just make sure that the primary objective remains the goal of coming up with the minimum viable product, and not just document something for engineering.
However you do it, if your organization is enlightened enough to allow you to pursue product discovery rather than simply document requirements, then by all means I hope you don’t waste even one day of this precious time. If you are having a hard time focusing your efforts and converging quickly on a great product, then I hope you’ll try creating a product discovery plan.