#007: Product Discovery and Definition
Crucial steps to undertake prior to writing the first line of code.
Prior to writing a single line of code there is an awful amount of work to be done which is an integral part of the product building process.
It essentially consists of two parts:
Product discovery: Understand who has what problem.
Product definition: Define the solution to a specific problem a specific user (persona) has.
Before diving into details, let me clarify what happens with great certainty if you don’t follow the two steps above:
You may build a product nobody needs
…because it fails to solve a real problem that real people have.
If you are a startup this implies you may either have to successfully pivot pretty quickly after having found out that your product is useless or you will have to fold the company.
As a corporation you will most likely bury the project.
So let’s have a look at the step-by-step process to follow prior to starting to build.
First, usually somebody has a presumably great idea for a product.
I’ll give you two examples from my own life:
Product idea A): Electric baby stroller
An electric baby stroller with a platform at the rear side so that parents can step on it similar to how e-scooters work. As I am a young dad, I feel like young parents living in urban areas have been left out in the recent e-mobility development.
Product idea B): Translation app
A real-time translation app with voice output so that I can have a sophisticated conversation in real time with my parents-in-law who only speak Korean (and no, Google translate does not do the job yet. Maybe and hopefully, soon OpenAI’s Whisper will get there).
Typically, product ideas where the product team or founder feel the pain point themselves are much easier to follow-up on than solving a problem that you don’t experience yourself (as a product person).
Ironically, often such ideas turn into consumer products which then are much harder to sell successfully than B2B products which address a pain point you may not experience yourself.
In any case, after you’ve had your epiphany you should follow what is described next.
1. Discovery: Understand the user pain point
Define the - possibly multiple - user personas and describe for each of them the specific pain point that they experience.
Understand and validate your assumptions about that pain point.
Here, it is very important to underline that
you can only validate your assumptions by getting out of your comfort zone and talk to your potential users or customers.
This point cannot be emphasized enough.
Technical founders or visionaries often falsely like to believe that they can directly jump to development and then come out of stealth mode and their product will be used.
Corporate innovators, in turn, often falsely believe that survey’s and market research replaces the need to talk to potential future customers.
The truth is, to build a successful product you need to get your hands really dirty.
Talk, talk and talk to your future potential customers.
A good strategy when talking to potential future customers is to try to understand how they are getting around the problem that you believe you have a solution for today.
Coming back to my product ideas A) and B) described above: As I don’t have an electric baby stroller, currently, I might simply walk or take the car or bus to go around.
And since I don’t have a real-time translation app that solves my problem, I started to study Korean (which may take several years to be “applicable”). In the meantime, my wife translates and I miss out on lots of opportunities to exchange thoughts with people that are very close to me.
A way not to talk to customers is by asking them if they would like “such and such product or feature”?
You will get counterproductive answers which can be fatal for your business (e.g. read “The Mom Test” for details).
2. Early definition, ideation and validation
After you have made sure you crystal-clearly understand the problem and the user you have to refine your product idea.
A simple approach here is to prioritize which sub-problems to tackle first.
This, in turn, means also to decide what not to tackle first, i.e. what is “in scope” and what is “out of scope” of your first product.
In-scope you only need the core features that provide maximum value.
That’s enough to drive early adoption (if you get it right).
Everything else is distraction in the process of building an MVP.
I’ll illustrate this concept by coming back to the example B) above (translation app).
If the user persona is a consumer whose in-laws don’t speak English (like in my case), then in-scope features would be:
Real-time translation with displayed transcription only on the (mobile) screen from a foreign languange to English (no voice output yet).
This already adds massive value as the user could then follow conversations in real-time that happen at the dinner table for example (you would have figured that out by talking to potential future customers of this service like myself).
So input = microphone, output = screen display.
Build only 1 app for either iPhone or Android but not for both.
The translation should happen on the edge (i.e. the device) and not through an API (think about all the privacy concerns and spy-ware-related issues).
App should work in non-noisy environment, i.e. don’t waste your time at the beginning to make it work in noisy environments like bars and the like.
Everything else should be pretty much out-of-scope.
No fancy app features, no voice output yet, no on-prem hosting functionality for teams yet, no subscription plans (i.e. think of product-led growth).
Side note 1:
Your first user-persona for the translation app could also be a B2B user working for a government organization where simultaneous translation settings are common (e.g. U.N. panels etc). Then your “in-scope“ vs “out-of-scope“ prioritization would look different.
Side note 2:
We are not talking about business models here but only about products.
Obviously, a B2B business model for a real-time translation app seems to be easier to monetize than a B2C model.
But in our context, we are only trying to build a great product following the observation about “why great products succeed”.
So now, you can start with a simple prototype, think about a user flow and, again, further validate it with your potential future customers.
3. Core product definition
So far, you have nailed down the user persona, the specific pain point and through talking to users you know that the identified problem is worth solving.
You have prioritized what are the “must haves“ and deprioritized the “nice to have“ features.
Because you already have talked to potential future customers you also already vaguely know how to distribute the first version of your product: i.e. by providing it to the people you have talked to.
Yet, now is the moment where you must figure out some core product aspects such as
Distribution and customer journey: how will users discover your product (we’ll deep-dive into this topic in another post)? This is important as distribution often is part of the product itself (e.g. a feature).
Product risks and feasibility: Can you build the product, what are the edge cases and risks? Think about the example of the translation app that must run on an edge-device. Otherwise, people might have privacy concerns and may not use it even if it perfectly addresses the underlying pain point.
Create a product requirement document (“PRD“, we’ll also talk about this in another post).
Resource planning: Can you build the MVP yourself or can you team up with somebody?
Each of the above points deserves a specific deep-dive, which I’ll deliver in future posts.
But for the moment remember: We have not yet started to write code.
In fact, product discovery and definition is very important so that
we don’t write unnecessary or even useless code
we can write faster code later
we ensure our code is extendable
we don’t start with building tech debt on day one.
Stay tuned for more insights.
Happy product discovery.
If you’d like to learn more, there are 3 ways I can help you:
Subscribe to this newsletter if you want to get actionable tips on software product management.
Email me at danielschmitter@substack.com to provide suggestions about blog topics.
Follow or connect with me on LinkedIn here.