Is doing Product Discovery easy, or a BIG ask for product teams?
My new take on "we have no time for research or experimentation"
Timo here. I write about the slower Product Discovery topics. The essentials, not the latest thing; the internet already has plenty of those.
Figuring things out as I go, 100% written by a human (me), with a new post every now and then.
1. My Struggle:
Me: *sits with product team*
Team: “check out this feature we need to get done”
Feature: *not tied to an opportunity, unclear how it will make us money, no supporting evidence, needs to get done ASAP. Overall just being in a risky mood*
Me: “maybe we should figure out how this will make us money, or, at the very least, wrap it in an A/B test so we know it doesn’t hurt us”
Team: “No. Discovery or experimentation takes too long. If we ship faster, we learn faster”
Me: *nervous laughter*
So I could start rambling how this is a folly. That they confuse time to task is done with time to results, and that this, in fact, is not the right kind of faster.
But I’m tired boss.
Maybe, when a team sees no problem with shipping like this, I should take that as a signal that they’re not going to be receptive to arguments about value.
2. (What if) they’re right and I’m wrong.
What if I’d stop arguing the value, and accept the premise that doing discovery or experimentation is indeed slower than just shipping (it is, obviously, on time to task is done).
This got me thinking: from the perspective of the product team, me (or a separate team or department for that matter) helping them with discovery or experimentation is basically a service.
Some services are frictionless: ordering take out from a food delivery service. One app, a few swipes, delivered to your door within the hour.
Some services are shit: trying to get IT to fix your laptop. No ticket = no service, having to deal with ticketing systems, waiting times, more systems, losing your laptop for a few hours (or days).
Now if there’s no incentive to use the service from a value perspective (which is the situation we’re in), it had better be super easy to do.
And it’s not!
It varies per org and depends on the maturity of the teams and how discovery / experimentation is organised, but it loosely looks something like this:
The need for insights is captured / noticed / prompted
The ask or situation goes to the person or team
They do the necessary checks. If GO:
Create a plan / design the study / write the hypotheses
Recruit the people / build the A/B test
Conduct the test / gather the data
Make sense of the stuff they found
Report back with the decision to make
I’ve worked with teams where this whole cycle takes a couple of weeks. I’ve also worked with teams where this whole cycle can take up to two months.
If there’s no intrinsic motivation or incentive to experiment (or other means of gathering insights) and teams are incentivised to just ship as much as possible by the end of the quarter, asking a team to wait weeks or months to do an A/B test first is a BIG ask.
It’s a hassle, it takes too long AND there’s a BIG chance the outcome of the test is going to create even more hassle because only 1 in 10 online experiments are successful.
Statistically I’m asking them to wait to be proven wrong. Which means it’s back to the drawing board, which nobody wants because everybody just wants to get the work done ASAP.
3. There’s actually theory for this stuff, btw
Turns out, my struggle to get teams to do more discovery and experimentation can actually be explained through theory:
Source: https://www.behaviormodel.org
This framework was sitting in my notes for years. The simplest explanation, straight from the source:
“Behavior happens when Motivation, Ability, and a Prompt come together at the same time. When a behavior does not occur, at least one of those three elements is missing.”
Simple enough.
I have no idea how scientifically sound this framework is, but some common scenarios seem to fit well:
Doing my taxes each year: I get prompted by mail each year. Not easy to do (low ability), but motivation is maxed out because NOT doing them would make me a criminal.
Going to the gym: I’ve accepted that I’ll never enjoy going (motivation low), but the gym is on my morning commute to work. I get prompted every time I cycle past it. It’s right there plus they make my workout plan. I just have to walk in and do what the app tells me to do, which is easy (high ability).
Cleaning out the shed: I despise it (low motivation), it’ll take up my weekend plus it means I probably have to take a few trips to the recycling centre on a busy Saturday morning (low ability). I’ve also learned to ignore it (no prompts), so yeah, it’s not happening.
Looking at my situation with some product teams, this is what seems to be happening when I want them to do more discovery and experimentation:
Their motivation is WAY below the Action line. If I want them to get into action, I need to seriously pump motivation (to be clear: this isn’t about wanting. Most teams I work with want to. It’s about what the system rewards).
Talking about the benefits of doing product discovery and experimentation (or the risks if you don’t) is essentially that: trying to increase motivation.
It’s also very naïve of me to think that me giving that talk will actually do that. Motivation comes from incentives, leadership, and how the org defines success. I, as an individual, can’t influence that. That requires bigger, more complex, organisational changes that are worth entire books on their own.
4. Focus on what’s possible: making things easier
However, what I, as an individual, CAN do is try to make things easier to do.
If it’s harder for a product team to do an A/B test or User interview than it is to get a laptop fixed by IT, then it probably IS the ability lever that needs work, not motivation.
If I accept motivation is a fixed constant, then that naturally makes ability the only lever I can pull to get teams above the Action line.
That’s my new focus: make discovery and experimentation as easy for product teams as ordering takeout (or at least easier than getting their laptops fixed).
It’s fun how frameworks can sit unused in my notes for years but suddenly click once I’ve stubbed my toe a couple dozen times.
The HOW to make discovery and experimentation easier is a whole new world on its own and probably a post for the future.
Some thoughts and rough notes for future me if I ever decide to write that post:
The prompt part of the model is really interesting. Depending on whether the experimentation or discovery people are organised centralised or decentralised, the prompt needs to be captured before the whole thing can be set in motion. Someone needs to be there if the product teams aren’t proficient enough yet in translating a latent need for insight into a prompt for discovery.
An interesting metric to track here is time to insight. Once a product team decides it needs insights (in whatever form), how long until useful insights are collected that help make a better informed decision? Now that might be weeks or months, but what if it’s 2 days or even 2 hours? What if it’s faster than ordering take out?
AI is an obvious candidate for some steps in the entire process, though the biggest chunks of time and effort will always be the actual sitting down and conducting the user interview or the waiting for sample size. That explains the hype for synthetic users I guess.
Related and worth checking out:
A keynote from Denise Visser at Conversion Hotel about making experimentation easy at bol.com
This post from Melanie Kyrklund. She gave an excellent talk at Emerce Conversion ‘26 about this exact topic.