Discovery in Product Development
A recap from the Dynamic Product Discovery Fishbowl Discussion at ProductTank Des Moines/Ames on November 19, 2024.
On Tuesday November 19th, ProductTank Des Moines/Ames held a fishbowl discussion focused on Discovery in Product Development. We stocked the fishbowl with Matt Crawford VP of Product at Mural and Catherine (Cat) Schoenthal-Muse, Senior Lead Transformation Coach at Wells Fargo, who bring unique perspectives and insights from their own discovery journeys.
Following their introductions, we opened up the floor for a fishbowl conversation, allowing attendees to join in on the conversation.
Here are my notes on the key points from the conversation.
There were a lot of farming stories during the discussion, but you had to be there for those…
What Discovery is
Continuously calling an audible on your assumptions.
Discovery is asking yourself a series of questions early and often:
Why do we think that this thing is going to work?
Why do we think this is the most important thing?
Is this the right thing?
Are we following the right approach?
These questions help you test and validate your assumptions. In order to answer those questions properly you need to engage your actual customers and users as often as possible.
Continuously means repeating that activity on an ongoing basis along the way from the problem space to the solution space.
Reducing uncertainty to Mitigating product risks
You test and validate your assumptions to mitigate product risks:
Value risk: Will users care about what you've built?
Usability risk: Will people be able to use what you’ve built?
Feasibility risk Can you can actually build the thing and technically solve the problem?
Viability risk: Can you can afford to build it and does it makes sense for your organization to build?
Discovery helps you answer those questions before you’ve built the entire solution so you don’t waste time and effort.
When discovery is done best, it’s all about reducing uncertainty. That holds true for all different kinds of companies.
What Discovery is not
Just for B2B and B2C
It's easy to assume that discovery is just for people who build products for paying customers who aren’t part of your organization.
It’s just as important and useful when you build products for people who work inside your organization.
Just about the product
Discovery isn't just product discovery or solution discovery.
A lot of teams spend most of their discovery efforts trying to figure out what customers and users think of their product. They build something such as a prototype or their actual product and conduct user testing and usability testing.
While those are helpful activities for a specific purpose, the best kinds of discovery aren't that at all.
The more impactful discovery is when you seek to understand your customers and their needs. You need to make sure you’re targeting the right people, and targeting the right problem.
That kind of discovery is more impactful, because you can spend a lot less time and money to find out you’re wrong via discovery than building a product and only then find out no one wants it.
Something you do only once
Discovery is not a phase or a project.
It’s not something you check a box and you’re done.
It’s also not something you only do at the beginning of a project and then switch into waterfall mode.
You want to incorporate Continuous Discovery Habits so that you’re always doing discovery to gradually reduce uncertainty. First about your customer and their needs, and then about aspects of your product.
Tips for effective discovery
Talk to customers and users about their situation, not your product
Before you spend a lot of time and money building a product based on what the experts inside your company think, talk to the people who might use it. Find out what situation they’re in and whether they’ll actually find your solution helpful.
For example, if you want to build automated farm equipment, understand the circumstances that farmers face to know whether that will actually help them or not. You may find that they don’t trust automated equipment to do planting for them, because if it messes that up, their whole growing season is wasted. You may just find that you’re building the wrong product, or targeting the wrong market.
Start the conversation talking about their experience. Use questions such as: “tell me about the last time you did [X].”
You're just learning about what the context they're bringing to the problem you may or may not choose to solve.
Make sure you’re talking to the right people.
It’s important to know who uses your product and who chooses your product (ie your customer.)
You may talk to someone who would use your product and get great feedback, but if they aren’t the ones who make the choice to use your product in the first place, it’s not going to help you much.
If you’re trying to figure out how you’ll get people to buy your product, you need to be clear on who your choosers are and how they make that choice.
If you want to figure out how to get people to keep using your product, you need to be clear on who uses your product and what makes will make them keep using it.
Users and choosers are not always the same people.
You need a different mindset for discovery.
People in product - whether you’re a product manager, engineer, or designer - you’re a builder. You like to imagine things, and you like to realize them.
To do discovery well, you have to put that desire to build something aside, and instead be curious and be willing to be wrong.
Doing discovery requires humility. You need to think “I'm probably going to be wrong when I start with this thing.”
You need to be able to quantify the problem
If you say that customers have a problem, you should be able to measure the frequency, the extent, the degree of that problem. That becomes your success criteria.
So then when you've built it and you've released it, you should be able to measure the same thing that was defining the problem before.
The easiest definition of success is that the problem is decreased or eliminated. You want to be able to answer “how do we know we've solved the problem enough to move on to the next most important thing?”
Use discovery to determine what’s acceptable
Once you’ve quantified the problem, you need to understand what target is acceptable to consider it solved. Rather than debating whether 10% or 20% reduction is sufficient, talk to your customers about their situation.
You may find that the problem needs to be completely resolved, in which case you may realize it doesn’t make sense for you to try to solve that problem.
When you do discovery, remember you’re biased.
People are hardwired with confirmation biases. To address that fundamental issue, build the discipline of saying “I might be wrong.” Looking through different lenses as you approach discovery can be helpful.
Ask yourself what could make that fail, or how could this go wrong?
You ask those questions to identify other, potential options.
Don’t get married to a single solution.
Teresa Torres introduced the idea of an opportunity solution tree, to help you consider different solutions.
The opportunity solution tree encourages you to start with what outcomes you’re trying to influence, and then helps you determine how to learn about what opportunities might exist to influence those outcomes.
Opportunity solution trees help you clarify the assumptions you have about your ability to create those outcomes, and then you craft questions around how you would know that you're influencing those things.
The more clearly you can articulate the assumptions you have about the problems you're solving and the solutions you have in mind and be honest with yourself and your team, the better off you’ll be.
Frame discovery around customer and context
Two things you can do to make sure you and your team approach discovery in the right way.
Find out why everyone on your product team thinks the team exists. If a product team thinks that they're there to fix problems for customers in a valuable way for the business, they’ll be less likely to get wrapped up in their own biases. If they think they're there to build things, the team will measure success based on we built it, we built it on time, it doesn’t break, we did our job.
Have a user researcher hybrid connected with a product team. They aren’t always with that core team. In addition, they participate in discovery calls, but don’t lead them so they can point out the blindspots that the core team might have.
Use discovery to help convince people who don’t think they’re wrong… that they are wrong.
We’ll inevitably run into someone who’s convinced they have a great product idea. More often than not, that person is in a position of power.
Discovery can help you address those situations when the idea is not the best. Talk to potential customers and users, learn about their situation, and find out what their true underlying problems are. The key is to do it quickly so you can find out if there’s a there there before too much work is done.
Then, if you find that the idea will not address those problems, explain what you found using stories about money.
You move quickly to give them a sanity check on the idea and then report back, “here’s what we’re hearing, hear’s what we’re learning.”
Prioritizing speed and context is important in these situations.
It’s better to find out you’re wrong now, rather than later.
You can think you're right and you might be right, but if you're wrong, everyone is going to know. If you work for a company that sells things, everyone will know if the thing you built isn't selling.
The key is to figure out how to connect the dots of being right now is much less important than being right later.
One way to do that is to talk in terms of risk.
For example, “hey, we are making a bet of $1 million, $2 million, $10 million over the next year. Do we want to make that bet based upon a feeling?”
And if they do want to make that bet, follow up with “Give me a week. Let's see if we can find some data and see some questions we might ask.”
You may need to call discovery something else.
There are times where you're trying to figure out how to build what you're building. Part of that is understanding what's needed to be built. You may find the people you’re working with are more comfortable with the idea of a spike. It's two weeks.
It's basically discovery, you just don't think it is. So it's really finding their background, their language, what their word for discovery is.
If you’re just starting discovery, start in the solution space
Although doing discovery on customers and their problems is ideal, if you need to get people comfortable talking to customers and users, start with the solution space. Show users and customers what you’re working on and ask them:
What has to be true in order for them to want to take the next step?
What has to be true for them to know how to take the next step?
What had to be true for them to take the next step?
To champion discovery, make use of frameworks and techniques
If you’re introducing discovery and asking people to do something they haven’t done before, suggest some tools and focus the conversation on using those not the people.
Then when you introduce frameworks, tools, or techniques, make it practical and do it together as a team. Introduce the techniques in a way where the team is learning together so it doesn’t feel like a certification or a process. Because if you think about what we're doing, it's just a way of thinking.
Look for the right techniques that work for you and your organization and start there, and that reduces the chances you mess something up.
Share examples of where it’s worked before
If you have an example of a success, share that example in terms of here's somebody who tried this, and here's what worked, and here's what didn't.
Along with that it’s also helpful to share stories of where it didn’t work and why it didn’t work in that situation.
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent