PRODUCTHEAD: (Re)discovering discovery
you and whose product?
Posted on Monday, 23 August 2021
Subscribe by email to PRODUCTHEAD — I Manage Products
PRODUCTHEAD is my free curated newsletter of the best product management articles, videos and podcasts. Subscribe to receive it each week.
Discovery is about understanding the problem space experienced by people
When on a tight budget for discovery, mitigate bias where possible and document all the biases you see
A relaxed participant will open up and be more honest with you
A discovery can prompt one or more possible solutions, or tell you the problem is not worth pursuing
a favour: please share this with other product people
every PRODUCTHEAD edition is online for you to refer back to
It’s not taken that long — maybe 10 years or so — for discovery to go from being a mostly unknown concept to one that you’ve almost certainly already heard about, and probably do in practice.
Steve Blank was one of the first people to popularise discovery and validation in his 2005 book, The Four Steps To The Epiphany. Many of his concepts were based on Extreme Programming Explained by Kent Beck, one of the co-authors of the Agile Manifesto (2001).
Blank also mentored Eric Ries ( “the best student I ever had”), who in turn took Blank’s Customer Development process, elaborated on it and made into a more practically applicable model in The Lean Startup (2011).
So the concept’s been around for a while.
There’s still some confusion though. Is discovery something you do up-front for a new product idea? (Yes) Or is discovery something you’re always doing in some form as you go through your build-measure-learn loops? (Also yes)
Who does discovery? How much discovery is enough? What do you do next? All excellent questions, which you can answer by reading and watching the great content linked below.
Discovery is one of a few important activities you should do before you get to the expensive bit of building something for real. As Einstein didn’t say,
“If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is.”
You do discovery to learn more about the problem you’re interested in solving from the people you think have that problem. In the process of doing do, you end up discovering that several of your initial guesses and assumptions were incorrect.
That’s actually great news because it helps you to start asking better questions. And best of all the cost of asking questions is negligible versus the cost of building something for real, only to find you’ve built something that doesn’t solve anybody’s problem, or solves a problem nobody cares enough about.
One of my favourite ways to illustrate the value of discovery is an old TV advert by The Guardian newspaper from 1986. It’s grainy, black and white and perfect. Watch it now — it’s only 30 seconds long.
Over the course of 30 seconds, your brain (or ‘System 1’ for Kahnemann enthusiasts) constructs three internally consistent but mutually conflicting narratives for what you believe is going on. Each additional bit of information you gain from the different camera perspectives radically changes your opinion. The scary bit is how easily your System 1 lets you flit from assumption to assumption without even a glimmer of scrutiny. It just accepts the new reality and moves on from there.
If it’s that easy for you to form and discard these narratives, imagine how many incorrect assumptions you must be making before you go and do your discovery. Discovery forces you to experience what you assume is the problem from different angles, which helps you to find the insights that radically change your perspective.
Discovery is all about reducing uncertainty. Your uncertainty is highest when you first approach a new problem. Uncertainty correlates to risk (= likelihood of not succeeding), so anything you can do to reduce your uncertainty also reduces your risk. You can’t eliminate all uncertainty, but each new perspective-changing insight increases your chance of success.
Speak to you soon,
 The quote probably originates from an unnamed academic at Yale University in the 1950s or 1960s.
what to think about this week
A great series of short videos by Steve Blank giving you a practical idea of how to go about your discovery and what to do next.
[STEVE BLANK / STARTUP WEEKEND]
Before you commit to building a service, you need to understand the problem that needs to be solved.
This is an excerpt from the UK government’s Service Manual, a distillation of the agile delivery practices adopted over the last ten years. It’s very clearly written, and a great resource for any organisation, not just ones in the public sector.
Discovery is inherently different when you work at a nonprofit, startup, or fledgling small business. It may be a design team of one (you), with zero dollars to spend, and only a handful of people aware the business even exists. There are no clients to interview and no existing data to examine. This may also be the case at large businesses when they want to test the waters on a new direction without overcommitting (or overspending). Whenever you are constrained on budget, data, and stakeholders, you need to be flexible and crafty in how you conduct discovery research.
[MEG DICKEY-KURDZIOLEK / A LIST APART]
Whether you’re new to product management or have been a product manager for years, a coaching session can help you to step up your career.
We’ve coached people wanting to get into product management, product people with nobody in their organisation to manage them, and experienced product managers preparing to apply for a promotion.
We can help you prepare for your product manager interview, including mock interviews.
A proportion of the fees from every coaching session is donated to charity.
“Jock has been instrumental in my personal growth as a product leader but also as a person.”
The goal of interviewing users is to learn about everything that might influence how the users might use what you’re creating. Good interviewing is a skill you develop with practice. The great myth is that you need to be a good talker. Conducting a good interview is actually about shutting up. This can be very hard, especially when you’re enthusiastic about the topic.
[ERIKA HALL / A LIST APART]
A discovery process is about understanding the user need and the realm of the possible entirely unconstrained by thinking about how to solve the problem.
[MICHAEL BRUNTON-SPALL / MEDIUM]
There’s recently been chatter about the discovery phase within the government digital community here in the UK, acknowledging that it can be hard to do well and that we can improve. This is something that’s emerged here at the Ministry of Justice (where I’m lead product manager) and across government during the development of a cross-government product management community of practice).
I bet you’ve found yourself in this situation. You’re trying to get your head around the main user problem your new product is going to solve. The thing is, for every question you try to answer, several more questions arise.
[I MANAGE PRODUCTS]
Imagine yourself jumping into your car, strapping in, and firing up the engine. You have a quick look around then pull on a blindfold before launching yourself into traffic. Likelihood of an accident? (Quite high.)
So why do so many take the exact same approach when it comes to creating products?
[I MANAGE PRODUCTS]
When companies set out to improve a service or redesign a product, the results can sometimes be underwhelming. Instead of delivering service transformation, the team recommends only minor efficiency tweaks. If this has been happening to you, there can be many underlying causes. I’ve identified a few common problems and what you can you do about them.
[I MANAGE PRODUCTS]
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from the sound of silence.