Product Confidential x Hyperact: Aligning discovery with delivery

Product Confidential hosted a podcast discussion with Hyperact co-founder Dave Baines to explore the discovery-delivery disconnect. They discussed why teams often neglect discovery, signs of imbalance, and practical strategies to improve the integration of discovery into product development.

The discussion highlights that while teams naturally lean towards delivery, small improvements in how you approach discovery can unlock real impact.

Below are the key insights from the discussion. You can listen to the full discussion here.

The speakers:

Dave Baines: Product lead and co-founder of Hyperact, with over 20 years of experience across the BBC, NHS Digital, Cinch, and GOV.UK.

Michael Palmer: Host of Product Confidential Podcast and Senior Product Manager at the BBC.

Questions

1. Aligning discovery with delivery, what does it mean to you?
2. Why do you think this area is misunderstood?
3. Why do you think discovery or delivery goes on the backseat?
4. When has the balance felt right? What did that look like?
5. The Product Operating Model + managing resistance from those who don't want to practice discovery.
6. Out of the 10 Discovery Traps you wrote, which are the most important to highlight?
7. What other tactics do you suggest to someone indexing too much towards delivery?
8. When "Discovery tells us to stop this work".

Aligning discovery with delivery, what does it mean to you?

It's something I've always been passionate about. When I think about the main problems I've experienced in and around product teams, it's been this. I gave a talk on the topic and wrote an article around it a couple of years back, which has been nice to revisit. Also, it's timely for me; I'm in my fourth week with a new team as a product manager. It's great to revisit and have a think about whether there is anything in here that I can use with the team right now.

Why do you think this area is misunderstood?

There's quite a bit to unpack around why it's misunderstood. Discovery is often treated as a second-class citizen, and there are quite a few reasons why.

It's almost natural for us to focus more on delivery than discovery. If you have to pick between the two, you always lean into delivery more, which is a good place to start. But it's easy to slip into that habit, and then discovery doesn't get the time it needs.

Also, it's rare to see discovery done well. A lot of people don't know it's a thing, so there's an awareness issue. It also has a bit of an identity crisis going on. A lot of people hear the word discovery, and see it as a bit of a barrier. There's work to make it more accessible and see it as a positive step.

The challenge is that product development is pressured, so it's hard to find chunks of time to take leaps forward. The iterative approach to how we build products should apply at a team level as well.

Why do you think discovery or delivery goes on the backseat?

It's more prevalent that I see discovery being the afterthought. But you can definitely go the other way. It's always a balance that you're trying to keep an eye on and course-correct.

In terms of not doing enough discovery or not applying enough rigour, there are a few things. You can kind of feel it with a) the time dedicated, and b) the sessions you have around discovery versus delivery.

Most of the places I've worked at have a standard cadence of meetings, like a planning or kickoff session. They tend to always be very well attended and have a bit of shape around them. They are always thought of as a moment to discuss the things we're focusing on next. You don't see that with discovery.

It's a telltale sign for me if there aren't regular sessions, or a regular cadence for discovery. Regular cycles of user research, regular sessions to assess usage data, or to think more in the problem space.

There's also something in the weighting of those sessions. Even if they are there, look at the attendance and time spent. If people struggle to attend or the findings coming out of discovery don't carry the weight they should, then that can be a telltale sign.

To flip it the other way, time spent in the problem space is a good indicator. There's no hard and fast rule, and it depends on the size of the thing you're looking at. If you're spending more than a month, or a few weeks in the problem space, then that's a sign that you're spending too much time in discovery. Or you're trying to bite off too big a problem. You could break that down further into smaller iterations.

When has the balance felt right? What did that look like, what did it feel like, and how can teams get to that place?

I'd say I've had a real mix between the public and private sectors. But the thing that popped into my head was the work I've done around GOV.UK and government services. The Government Digital Service (GDS) framework has you go through stages of alpha and beta. Some argue that's more than you need to do, but it at least keeps you honest and ensures you do some discovery. That's something I've taken away and kept as a mindset, whether I'm in the public or private sector.

The other is Cinch. What helped there was when leadership flew the flag and showed by doing. That both delivery and discovery are as important as each other. Trying not to treat discovery as a second-class citizen, but also injecting urgency.

It's asking the question: do they need to be different? Delivery is a great avenue for discovery. Why can't we get this in front of users or customers earlier to use as a feedback mechanism? That experimentation culture we saw at Cinch is a good example.

How have you seen teams transition into a product operating model? And how do you challenge resistance from specialists who don't want to practice discovery?

As my career has progressed, I'm more passionate about that model and I have a clearer picture of what good looks like. But I've also become more pragmatic and aware of the constraints.

I know that you can almost kill yourself trying to change teams and organisations. Sometimes you can't, and sometimes you don't need to. I've definitely felt that, and I've probably become more philosophical about it.

I will always strive to improve and work with teams to do that as much as they can. Sometimes you have to acknowledge constraints and realise it's okay not to push too hard.

I can think of an example of a B2B scale-up I was at a couple of years back, constrained on how often they could release. I could have poured a lot of energy into trying to improve that, but there were other areas where you could see how to move towards the model and get more insights at the product strategy level. That was a better place to try and move things along.

What I find is a useful exercise when joining a new team is trying to sound things out. Spend a few weeks understanding the environment. I quite like the way John Cutler expresses it with mandate levels. Understand where the headroom is. What is the expectation on you? What can you actually do to try and move things along, and what can you make peace with and not try to drive forward?

Out of the 10 Discovery Traps you wrote about in your article, which are the most important to highlight?

👉🏻 10 common product discovery traps

The front-runner in there is delivery taking the spotlight. It's the main one I've seen throughout my career. There's always an element of me that will try and inject a bit more discovery when I see that I can.

This is where product people can deliver most, in the discovery space, helping to tee up delivery to add the biggest impact. So I couldn't move away from that one.

Another one that I've experienced is that the number of people involved can be a challenge. Having too many people makes it hard to have effective sessions and get focused insight. The sessions where it's hard to get focused, you have too many opinions, and it's hard to get a strong signal. There's quite a bit you can do.

It can be a bit hard and awkward, but be intentional about who you involve in discovery and accept that it's okay if not everybody is there.

Working a bit more asynchronously and being smarter in terms of focusing research and discovery sessions around specific artefacts helps. Being disciplined so that you come out of shorter, snappy sessions with a clearer view is something I'm a big believer in.

What other tactics do you suggest to someone indexing too much towards delivery?

I'd say being mindful is a good starting point. I find stopping and taking stock of where I've spent my time helps. I like the way Ed Biden frames it: (there are red phases and blue phases for product people)[https://blog.mentoring-club.com/p/red-phases-and-blue-phases-in-product]. You will deviate between them. Sometimes you are in more delivery and project management elements, and that's okay. Sometimes you will be more in the discovery space. It'll never be a strict 60/40 split; it'll always be squiggly, and that's cool.

If you are trying to inject a bit more discovery, jumping straight into regular ceremonies can be too much of a starting point and hard to get going.

I find that sharing things asynchronously can be good. Block out a bit of time to think about where you might get more user or customer insights, and share that. Whether it's sharing a Miro board you've put together, or doing the heavy lifting to boil down insights from user research. Sharing that in a Slack channel can be a good way to do it.

You can also piggyback on delivery ceremonies. If you are doing show-and-tells or similar meetings, don't just talk about the thing you're working on and delivering. Talk about discovery. The insight behind it. What led you to that conclusion. What your hypothesis is. What success looks like. How you're going to measure it. You can start sprinkling that in. It becomes a routine, and you can start to see that cross-pollinate across teams. I've seen that in a few organisations, so that's where I'd start with that one.

When "Discovery tells us to stop this work".

I guess I've touched on the image problem that discovery can have. It can be seen as a barrier. And it kind of is, in a good way. But delivering that message can be one of the hardest parts of a product role, and it's about how you navigate that with grace.

What's worked for me in the past is doing stuff iteratively and overcommunicating. Being clear that you're operating on short feedback loops and making people aware of the signals you're getting over time is key. Building up an audit trail, showing that actually, we were building up a bank of evidence. This might not be the right path to take. This can be a good way to do it.

Delivering iteratively helps you there as well, because once something is out there and you have strong signals, you can save the effort of delivering the rest of the project if you nip it in the bud earlier. That continuous delivery mentality can help.

Leaning into the way you frame and word things is important. It's not that discovery is telling us to stop. It's more like, our efforts are better spent over here, on this better bet. The evidence is showing us that this might be the place to go, to impact the outcome we're aiming for. You can frame it in a more positive light rather than saying the answer is no, and we have to stop and put this down.

It's tricky if you're the only voice advocating for that. Where it helps for me is having strong leaders who are backing it, and having other allies in the team. That product trio is key. Having a tech lead and a designer who are on the same page so the message comes from multiple people can help to build that culture, but it takes time.

As I've progressed in my career, I've grown more comfortable doing it, and I think it is incredibly important. It should be something practitioners across the board take responsibility for. But particularly as product people, I've never seen it end well when you think, "I'll sit on this one for the next few sprints and see how it plays out". I'd always try and nip things in the bud and be open about it.

Thank you to Product Confidential for hosting us. You can follow their podcast here on Spotify, or on LinkedIn.