"What is Discovery and Delivery at the same time?"
The dynamics that bog down teams, and how pivot triggers can de-bog them
Hey, nice to see you. You look good today.
First, some quick news:
If the idea of discovery and delivery at the same time sounds intriguing, my Set Your First Pivot Trigger instructional video pre-order is currently £35. After I ship it, the price will go up to £49. (Aiming for Monday.) If you’ve been considering picking it up, now’s the time. But if you’re still wondering whether your context is right for Pivot Triggers … well hooray, my next article will touch on that.
I’ve been working on part 4 of my OKRs series. In this one, I’ll share a way to look at your context and figure out where and when to use different methods, including OKRs. This turned out to be a beast to wrangle, but I’m excited about how it’s shaping up.
I’ll be speaking and running workshops alongside an amazing group of people at this year’s UX London on 18 – 20 June. More to follow, but tickets are on sale now. Hit reply and ask me for a discount code to get 20% off your ticket.
Boom. OK let’s get into today’s piece. I’m going to answer a question I got on Linkedin from someone who’s a very experienced service designer, strategist and discovery researcher. It’s a question you might have been wondering about too:
“The first bullet [in the Pivot Triggers post] mentions doing discovery and delivery at the same time, Tom. Will you explain that?”
Discovery and delivery is seen as a dichotomy
Here’s a common pattern that I’ve seen on lots of teams. It’s a rough sequence of steps that lead to getting increasingly stuck.
Most teams “don’t have time” for research. Sometimes this is an excuse, sometimes it’s a genuine constraint. But what’s almost always the case is that teams are under the cosh to deliver stuff and that isn’t something they can change.
Most teams sense they’re delivering lots of stuff that’s unwanted or unusable but don’t have a way to tackle that. They’d love to stop doing that, they might raise concerns, but they just don’t have the agency to challenge the roadmap. Going back to point 1, they “don’t have time” to do the research that might show them what would be better to deliver. The concerns get labeled as unhelpful grumbling.
As more and more of the stuff delivered doesn’t seem to be working very well, levels of uncertainty, ambiguity and stress increase. When this happens, most teams try to regain a sense of comfort by hyper-focusing on small details that they can control, ignoring the bigger picture that’s too ambiguous. It’s uncomfortable to face the lack of evidence-based knowledge about the users.
When most teams get access to some research or experimentation, they tend to point them at those small details, and still miss that ambiguous bigger picture that could transform things. When I looked around, I saw research and experimentation at the periphery, but not central to how decisions were made in businesses. In my experience, to get to the point where research and experimentation are central, you have to make a bit of a mess before you can start getting the full value, because it’s such a big reframe in how you work.
And even though I’d been all-in on user research and experimentation for nearly 2 decades, and could demonstrably deliver the goods, I still found that persuading execs and managers to be more evidence-based was a losing game. I put a lot of time and effort into teaching and evangelising in companies and I had some small wins. But I found there was a hard limit to how far evidence could permeate in companies, especially when it challenged dominant narratives. I came up against too much resistance. I couldn’t stop bad features from being worked on for months. And I heard from increasing numbers of others that I wasn’t alone in this.
Overall, there seems to be a massive fear of discovery. I know from experience that discovery often speeds things up, but it doesn’t feel that way in the short term. It feels like slowing down. And so it gets resisted and sidelined, even by smart people who agree that we absolutely should be doing research and experimentation. We’ll do it next time!
I think a lot about this diagram explaining the formation of oxbow lakes, that I got from
.When you play into the narrative that we must do discovery before we can do delivery, you create a meander that feels like it slows down the flow of activity in the company. Then, in crunch times, a few projects start getting rushed through without discovery, bypassing the meander. Over time, the route of avoiding discovery gets easier and easier to take until it’s the default flow. The researchers and experimenters end up in a quiet backwater, cut off from the rest of the organisation.
(As an aside, I’ve seen this pattern happen to lots of different teams when they try to insert themselves upstream and control the torrent.)
How can you go faster now and include discovery?
I stumbled across some things that started to shift the nasty dynamic.
Don’t try to stop people from doing delivery
I found that we couldn’t sustainably halt delivery. What we could do was change the order teams delivered the work in. The trick was to make the early delivery “accidentally” either experiment by putting the thing out there and/or get the team fast exposure to how customers will actually interact with the thing in the end.
This even means we’re delivering even faster. Getting results this week, instead of in months. Putting off debates about details until we’re more informed about which details actually matter.
And I know this might not be “proper” research. But let’s face it: these teams weren’t going to persuade their organisation to do proper research. Even if they did, the organisation wouldn’t know what to do with it: using that kind of evidence isn’t in their DNA. This approach has repeatedly been effective as a first foot in the door, and it’s been a gateway to proper research for several teams.
Make the scary, ambiguous parts concrete first
I found ways to get teams to face the scary parts first, and created ways to make those “real” much faster, usually without needing to build a load of stuff. Having a concrete way to work on those parts loosened their grip on the tiny details. Now they delayed parading about with beautiful UI mockups, delayed debating technical details of the architecture that would only be relevant in 2 years. Instead, they dug into the behaviours that would need to happen right away for the thing to succeed at all.
In short, the right people needed to find it, choose it, use it and get value from it. These are the ambiguous and scary parts that get kicked down the road on most projects, and now they could be tackled first.
This was nearly enough. The final piece of the puzzle:
Have the conversation about what would make you change your mind
It wasn’t enough for the team to come to execs with the news that something wasn’t working, because sunk cost bias had already set in. We needed to tackle that up front, before starting each cycle of delivery and discovery at the same time.
This is where Pivot Triggers come in: “we’re going to do X part of the project this week. If we don’t see [signals that give us confidence] then we’ll stop and think. Do you disagree?”
I saw this simple phrase start to shift the conversation between teams and execs, opening the door for evidence to guide actions. It created conditions where mediocre ideas could be adapted to work, and bad ideas could be killed quickly. (The record for the fastest killed idea is under an hour!)
That’s what I mean by discovery and delivery at the same time
The team are still doing work today to make progress, but they start with the hardest, most uncertain parts, co-opting those to become the discovery they most need to do. This way, when the plan isn’t working out as everyone expected (and when does it ever?), there’s still plenty of time to adapt, or even to switch to a better idea
This breaks the false dichotomy, and can stop research and experimentation being experienced as that slow meander.
If this sounds good, maybe you’d like to Set Your First Pivot Trigger.
Tom x