IRL Product
Published in

IRL Product

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 product manager should be better at Discovery than anyone else in their squad. This is where their unique value lies.

Let’s explore why.

Possible reason 1: They don’t know that they should be doing Discovery

This picture is a comic strip containing 3 frames. There are two people in each frame talking to each other (let’s call them A & B). In the first frame, A said, “Your user requirements include four hundred features.” In the second frame, A added, “Do you realise that no human would be able to use a product with that level of complexity?” In the third frame, B replied, “Good point, I’d better add ‘Easy to use’ to the list.”
One of the biggest mistakes I’ve made was assuming that my senior stakeholder has done their homework when they requested a feature

Possible reason 2: They know they should be doing Discovery, but they don’t know how

Possible reason 3: They know they should, they know how, but they don’t prioritise it enough

So how can a Product organisation be better at Discovery?

  1. Training
  2. Templates
  3. Touchpoints
  4. Target
A picture of 4 white pillars with the title “Codifying Product Discovery”. Each pillar has the title written on top of it: Training, Templates, Touchpoints, Target
The 4-Ts to make Product Discovery scalable and repeatable


It’s a table containing training modules. ‘Competitive landscape’ module is relevant for entry-level external hires and experienced external hires. ‘Customers, segmentations, and needs’ module is relevant for internal transfer, entry-level external hires, and experienced external hires. ‘Product development techniques including Discovery’ module is relevant for internal transfer and entry-level external hires.
Modular training modules for new product managers


It’s a comic strip with 3 frames. In the first frame, a manager said to its employee, “After 8 months, senior management finally approved your project plan.” In the second frame, the employee replied, “It’s too late, all of the technology has changed and our competitors have leapfrogged us.” In the last frame, the manager advised, “Maybe you could write a new plan,” to which the employee replied, “Or we could get the same result by submitting this one.”
This is definitely not the goal
  • 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.
  • 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.


It’s a comic strip with 3 frames. In the first frame, an employee presented “I added all the product features that each of you demanded.” He added in the second frame, “Now our product is worthless hodgepodge of complexity.” In the third frame, he said, “I appreciate your input. I couldn’t have failed without you,” to which one of the audience shouted, “Teamwork!”
How your product can frankenstein without a cohesive vision
Progress review answers the question: are we still on track to deliver? Whilst insights review answers the question: are we still working on the most important things?


  • 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
A table containing examples of goals based on different development stage: discovery, input, output, and outcome.
Incorporating Discovery into your goals. Taken from Reforge.

In summary

  • 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



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store