"But unfortunately, we don't spend enough time understanding the problem because it’s easier to build solutions that move our KPIs."
I agree with that, sometimes we forget the problems and the users just to move KPIs. When this happens I always try to take a step back to understand the situation
Definitely, Erick. I've been in the same position many times -- where you're aiming to hit a KPI goal and neglect thinking about the broader problems. I like you approach of taking a step back.
Great article Will, in principle I agree with your points. However, personally being at a pre-seed startup I've felt the focus on delivery to be overwhelming in comparison to discovery. We're at a stage where the technology is so well defined by the founders that there's so scope for discovery to change "what" we're building.
Curious if you've had similar experiences working at early-stage companies.
This is totally reasonable. I was at a 20 person startup and discovery was not top of mind. But I found a good mix was to speak to existing users/customers to understand their problems and build those into the roadmap. This is lightweight discovery that has a fast turnaround time into moving KPIs.
"Remember that the goal of a discovery project is to create actionable product insights. This prevents the projects from becoming too academic or fluffy."
Hi Will, can you provide an example of non-actionable, "academic", or "fluffy" product insights that teams want to avoid while conducting discovery?
Academic or fluffy research projects don't create actionable product insights, they create more questions to explore. Examples outcomes from a project like this would be "Understand user sentiment on feature X more" or "Explore different cultural differences".
Hey, Will! Thanks for sharing that :)
A sentence caught my attention
"But unfortunately, we don't spend enough time understanding the problem because it’s easier to build solutions that move our KPIs."
I agree with that, sometimes we forget the problems and the users just to move KPIs. When this happens I always try to take a step back to understand the situation
Definitely, Erick. I've been in the same position many times -- where you're aiming to hit a KPI goal and neglect thinking about the broader problems. I like you approach of taking a step back.
This resonates so much with my product journey wrapping up the 90 Days. Thanks for sharing, Will!
So happy its useful, Karen :)
This is a great article Will. Unfortunately not seeing many B2B orgs in favour of in-depth research!
This is a great article Will. Unfortunately not seeing many B2B orgs in favour of in-depth research!
Great article Will, in principle I agree with your points. However, personally being at a pre-seed startup I've felt the focus on delivery to be overwhelming in comparison to discovery. We're at a stage where the technology is so well defined by the founders that there's so scope for discovery to change "what" we're building.
Curious if you've had similar experiences working at early-stage companies.
This is totally reasonable. I was at a 20 person startup and discovery was not top of mind. But I found a good mix was to speak to existing users/customers to understand their problems and build those into the roadmap. This is lightweight discovery that has a fast turnaround time into moving KPIs.
"Remember that the goal of a discovery project is to create actionable product insights. This prevents the projects from becoming too academic or fluffy."
Hi Will, can you provide an example of non-actionable, "academic", or "fluffy" product insights that teams want to avoid while conducting discovery?
Academic or fluffy research projects don't create actionable product insights, they create more questions to explore. Examples outcomes from a project like this would be "Understand user sentiment on feature X more" or "Explore different cultural differences".