Codifying the product discovery process
Product discovery is where PMs can bring their unique value. Let’s explore how you can codify it into your product development process.
A PM friend once said, “Being a PM is like committing to a constant identity crisis.” Designers create beautiful, usable prototypes. Software engineers code and turn those prototypes into a working product. Product managers, a cynical voice might say (i.e. usually their own voice), is just a glorified secretary that brings everyone together and makes sure they have what they need to do their work.
That is probably the truth in many companies who don’t empower their Product teams and just dictate what to build. Product development consists of two elements: Discovery and Delivery. Put simply, Discovery is about figuring out what to build, whilst Delivery is about building and shipping it.
A product manager should be better at Discovery than anyone else in their squad. This is where their unique value lies.
Yet most PMs don’t spend enough time on Discovery.
Let’s explore why.
Possible reason 1: They don’t know that they should be doing Discovery
Aka they thought a PM’s job is Delivery.
It’s understandable how this misconception still exists. Many PM training focuses on practical Delivery skills such as user story writing and backlog prioritisation. The misconception also propagates from the senior leaders’ side. They hire a PM to deliver the work that they’ve decided on, not realising that they shouldn’t even bother to hire a PM to do that.
In most companies, there’s no system in place that defines the Discovery process. It means that this process if often skipped, as they assumed somebody, perhaps a stakeholder who requested the feature, already did the homework and go straight to building the feature.
Possible reason 2: They know they should be doing Discovery, but they don’t know how
Product Discovery can be an elusive concept. If a company doesn’t invest in proper training and coaching for PMs, the PM’s best bet is learning from or observing other PMs around them. If they’re unlucky, the other PMs are as clueless as they are.
And because they aren’t sure how to do Discovery, they use Delivery as a crutch activity. Crutch activity is a concept introduced by Tim Ferriss — which refers to the activities people do to make them feel busy and productive, whilst they’re actually avoiding the real important thing.
Therefore, many PMs spend a lot of time writing tickets, clarifying requirements for the engineers, unblocking them, making sure that they’re shipping in time… Then the same PMs would complain that ‘they don’t have time to do the strategic work.’
Possible reason 3: They know they should, they know how, but they don’t prioritise it enough
Some companies subconsciously discourage their PMs to do Discovery by setting goals and performance evaluation that focus on Delivery.
Every time a company celebrates a feature launch without A/B tests or learning goals, a tiny Discovery spirit dies.
It’ll be an uphill battle for product managers to insist on taking their time doing Discovery if everything works against them. It requires a mindset shift on the company level to put emphasis on innovation and experimentation.
So how can a Product organisation be better at Discovery?
Notice that the title of this section doesn’t talk about how a single PM can be better at Discovery. I believe that the whole Product organisation should strive to be better — the onus is mainly on Product leaders to set up an environment where PMs are trained, encouraged, and incentivised to do Discovery.
These are the four pillars you need to codify Discovery into your organisation:
- Training
- Templates
- Touchpoints
- Target
You have to build all four — otherwise it can get wobbly like a table with only three legs.
Let’s dive in.
Training
This pillar is the most self-explanatory. It’s particularly important if your company supports internal transfers from other parts of the business into PM roles. Spend at least a week or two training them on Discovery techniques, such as user interviews, competitor analysis, Double Diamond method, user journey mapping, optimisation and A/B testing, etc.
Even if you hire experienced PMs, it’s still beneficial to train them on your industry, its competitive landscape, your customers and their needs.
A rough training plan can look like this:
Training isn’t just for new people — continuous upskilling is also important! Discovery technique evolves and your PMs need to keep sharpening their frameworks. Jobs-to-be-done is an example of the more recent frameworks that every PM needs to be familiar with.
Templates
Templates are such a simple but powerful tool. Templates transform elusive actions into explicit requirements.
Most companies have some kind of Product Requirements or Product Specs templates. I hope at this point it has become clear to you why Product Specs isn’t a great way to encourage PMs to do Discovery. It focuses on Delivery — it’s merely a tool to capture what to build and how to build it, not the why.
I would strongly advocate to create two more types of templates: Problem Brief and Problem Definition. Both have to be created before they even start thinking about the solutions captured in a Product Specs document.
It’s worth reminding that the documents are only a by-product of the thinking process. The goal of using the templates is to encourage thinking, not to create unnecessary hoops.
A PM should start their thinking by writing a Problem Brief.
It’s a document outlining the rough thinking around the problem. It could include:
- Problem symptoms, e.g. anecdotal stories, NPS comments, some oddities they noticed in the data.
- Business requirements, e.g. compliance issues, expansion plan.
- External landscape, e.g. industry trend or competitor analysis.
At this point, they think there might be a problem, but they haven’t fully defined it. They certainly don’t know what the solution is.
The goal of writing the Problem Brief is to get a better sense whether the problem is worth solving at all, and what actions are needed to refine the problem.
The second template worth having is Problem Definition. The document has to answer the following questions:
- What problem are we trying to solve? A succinct statement of the problem. Also specify if this is a customer problem or a business problem.
- How do we know it’s a problem? It has to contain data and customer insights, both qualitative and quantitative.
- Why is it important to solve the problem? How will this impact the company’s future? How will it impact the product strategy?
- What happens if we do nothing? How does the problem develop with inaction?
- How will we know if we’ve solved the problem? What business metrics is it going to move? What will customers say?
- What are the criteria of a good solution? At this point, we don’t know what the solution is going to be. We’re only describing the principles of how we want to solve this problem. It has to include the constraints we need to work within. It can also include the platform (e.g. app vs web or both), the market segments (e.g. the solution has to work for all members, or are we ok if it’s only for smart members?), the time/resources allocation (e.g. the solution has to be feasible to build by 2 engineers in 4 weeks).
It’s probably a good idea to say again that these templates are meant to encourage research and thinking, not to produce documents that nobody wants to read or revisit.
Touchpoints
The third pillar after writing the Templates is creating Touchpoints to discuss what you’ve discovered within the Product team.
Engineers usually start their development process by writing a Technical Design Document (TDD). This TDD is then shared with other engineers and everyone can give input. If the company has a principal engineer, that person definitely has to review and approve the approach before the first line of code is written.
It’s an important process because if all engineers just start building whatever they want, the codebase can frankenstein out of control with no clear way to make it scalable and clean.
Similarly, the documents produced by PMs should be reviewed by other PMs. This ensures cohesiveness in the product strategy.
“But,” you might say, “I thought an empowered Product team should be given space to work on whatever they want?”
I like to quote Marty Cagan’s answer to this: Having an empowered team doesn’t mean it requires less management — it requires better management.
The goal of the review process isn’t to stifle the PMs — it’s to make sure that all the Product squads are working on the most important problem areas that align with the overall strategy.
The review process can be done asynchronously, complemented by a regular session (e.g. weekly or fortnightly) where PMs can share where they are in the Discovery process and gain useful input from other PMs.
Many companies also have some kind of roadmap review process, either monthly or once in the middle of of the quarter. The meeting usually focuses on “Are we on track to deliver what we said we’re going to deliver?”
Whilst it’s important to discuss deliverables, don’t forget that it’s also crucial to check whether you’re still working on the most important thing.
Target
The last pillar in codifying Product Discovery process is by embedding it into the expectations for PMs, usually in a form of performance review, progression framework, and quarterly goals. I use the word Target to encapsulate these things (although admittedly, it’s mainly because I want to have 4-Ts as the four pillars).
Quarterly goals usually sound like this: ‘Increase X metric by Y%’. Which is a great goal, assuming that:
- We’ve decided that X metric is the most important thing to achieve our business vision
- We know what levers influence X
- We believe lever A is the best one to pull right now based on customer and industry insights
- We believe this feature we’re building will move lever A
The problem is, more often than not, we haven’t actually taken the time to figure out the above. Allowing goals that focus on Discovery can solve this. This article from Reforge is worth reading.
In summary
You can upskill your PM team to be better at Discovery by codifying them into four areas:
- Training PMs on doing better discovery
- Using Templates to ensure consistency
- Reviewing the insights and learnings in the Touchpoints
- And making it a part of your Target
Special thanks to Andy Xu for his inputs on the template and the naming of the pillars and Zoe Price for downloading her thoughts on Discovery!
👋 Hi, I’m Debbie. I’ve been building products and solving customer problems in tech companies for over a decade. I write about how a PM can bring 10x value to their company, not just 10% improvement. Stay ahead of the game and get insights delivered straight to your inbox — subscribe to my newsletter today!
