Product Discovery Should Speed Up Delivery, NOT Slow it Down
Hey I’m Ant and welcome to my newsletter where you will find practical lessons on building Products, Businesses and being a better Leader
You might have missed these recent posts:
- Context NOT Control
- Data-Informed NOT Data -riven
- Prioritization & Urgency: Key lessons from John Cutler’s Prioritization Course
My day job is helping companies shift to a Product Operating Model.
My evening job is helping people master product management at Product Pathways.
Product Discovery should seed up delivery, not slow it down.
Ok, I admit the above picture is an oversimplification, but let’s break down what’s happening.
Handoffs: where information is lost
You’ve probably seen places where they split discovery and delivery.
There is a discovery team and a delivery team.
The discovery team spends weeks doing discovery and their outputs are detailed designs and specs/requirements.
Of course, this sounds and looks a lot like a waterfall, and I’ve talked about the perils of viewing the output of discovery as detailed designs several times now.
However, a core problem is that this creates a handoff.
And the problem with handoffs is that information and knowledge are lost.
Inevitably, the development team will have questions.
And there’s a bunch of back and forth that happens between the delivery team and the discovery team.
Handoffs lead to a lot of back-and-forth as context is missed and questions come up.
Now, this gets even worse when the discovery team only consists of designers and product managers and there’s no technical representation.
Not only will knowledge be missed in the handover, but so will key decisions, considerations, and trade-offs be overlooked.
This creates more questions and potentially the need to pause delivery altogether to make fundamental design decisions.
Of course, running into the unknown is part of product development. We can’t have all the answers upfront.
But a key difference here is how we approach tackling those unknowns.
Do we do it together collaboratively or as one team's problem vs. another - “I’m just here to build what you tell me to.”
Of course, this is why so many advocate for product trios and for engineering to be involved in discovery (as well as for practices like continuous discovery and delivery).
“Product discovery, as with almost every activity in product, works best when the team is engaged and collaborating. Handoffs in product management are a huge productivity killer.” – @prodlabio
The end result of not having engineering involved in discovery is slow delivery.
Constantly stopping to ask clarifying questions
Losing momentum to pause and make decisions
Running into known-unknowns, which we could have explored sooner
By no means am I suggesting that you will have everything figured out before delivery – that’s impossible – but instead, we can minimize the waste of having to go back and forth by empowering those delivering the work with the context to make informed decisions.
One team, two different ‘tracks’ of work
Now imagine a team that is responsible for both discovery and delivery.
They have learned the hard way how critical it is to have those developing the product involved in discovery.
This is easy for them to do too because they’re part of the same team!
This immediately does two things:
Kills off handoffs.
Empowers those delivering the work with key context
This significantly reduces the time the team has to stop during delivery to clarify things.
It also reduces the chances of miscommunicating things and potentially going off in the wrong direction.
When the spec said ‘customers want to get to the other side’ but you were missing the context (pic credit: Henrik Kniberg)
The second thing is empowering those delivering the work with the context to make decisions.
In a product-tech world this is typically the engineers - but I would also include product designers (namely graphic, UI, interactive design, etc disciplines)
And I also deliberately remain agnostic here because I do work with organizations that aren’t tech companies. For example, insurance and medical devices might have clinicians, actuaries, or underwriters as competencies required for delivering.
Doing this increases decision velocity and, subsequently, delivery speed.
Let me put it this way.
Rather than stopping to convene a committee every time you need to make a decision in delivery, we can empower engineers (those delivering) with the context to make an informed decision.
This helps maintain momentum.
And I know what both scenarios are like. I was an engineer once, 13 years ago, and I appreciate the value of flow and momentum and how disruptive it can be to need to stop all the time.
Far from perfect
Of course, this doesn’t mean that there will be no back-and-forth.
As Drew Barontini put it:
“Any work before you do the work is guesswork. But I believe clarity is driven through context. The more context you have about the problem (discovery), the better decisions engineers can make during building. Unknowns and trade-offs are part of delivering on time.”
It’s impossible to have all the answers upfront.
That’s why I like to frame discovery as a confidence-building exercise. It’s about having confidence that you’re directionally correct.
There will always be a need to ask clarifying questions and pause to make decisions.
However, we can reduce how often this occurs by bringing discovery and delivery closer together.
And I really believe this is a high-leverage approach.
It’s not a big ask, we’re not saying that engineers should spend 50% of their time in discovery.
Whilst I don’t have hard stats on it (and I think it would be near impossible to get) I believe any time spent in discovery would be at least 1/3rd of the time lost in additional back-and-forth.
And even if I’m totally wrong…
Ok, let’s imagine I’m wrong. And let’s say that getting engineers more involved in discovery actually slows everything down and costs more.
But would that matter if we’re more effective?
Remember that it’s really ‘time to outcome’ that matters, not ‘time to output.’
Or, as Marty Cagan says, “time to money, not time to market.”
“Time to money, not time to market.” - Marty Cagan
But the truth is we’ll never truly know because you can’t split-test a team. But my hypothesis (based on my own lived experience) is that you will get both.
There will be less waste in delivery, and you’ll achieve your outcomes faster. And I think that’s worth it regardless of whether it speeds up delivery or not.
Hope that helps!
If you want to chat or need help bringing discovery and delivery closer together, this is what I do daily as a Product Coach. I'd be happy to chat. No strings attached!
And if you're interested in some strategies I've used to get engineers more involved in discovery, watch this talk I did at PUSH UX Conference in 2022.
Top Posts
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…