The Mythbusters model of Product Development
We’ve all been there: your stakeholder leans in, nods their head just a fraction, and says the magic words. “Yeah, but we already know what’s needed. Can’t you just give it to me?”
(A quick aside: JUST is the most dangerous word in tech. We’ll touch on that another day.)
Or maybe it’s someone you’re at a party with. They look slightly quizzically at you and ask, “Yeah, but what does a Product Manager actually do?”
(Another aside: this applies mostly to boring parties. But we’ve all been to those, unfortunately.)
I’ve struggled with answering these questions well for years. I’ve had accurate answers, pity answers, long explanations and short ones. None really worked, until my son got hooked on Mythbusters - and then I saw the light.
On the off chance that you’ve never binged a season (or six…), Mythbusters is the perfect timewaster for a curious geek: entertaining, informative, and explosive. Each episode follows a fairly standard formula: the team picks a couple of urban myths that sound like fun, and they try to prove or disprove if it’s indeed plausible. They do this by following a few very standard steps, which will sound familiar:
Problem identification
Hypothesis
Discovery
Delivery
Launch & Feedback
Fun
If you really want to simplify this: the first three can be classified as Fuck Around, and the latter half as Find Out. Full credit to Steve Messer for this approach:
thank you for coming to my ted talk pic.twitter.com/2jpJ3ciJEj
— steve.rss (@stevenjmesser) June 10, 2021
Let’s go through the stages individually:
1. Problem Identification
Someone - one of the team members, or a fan of the show - brings them a myth to try to bust. They’re able to articulate specifically what the challenge is, and a clear metric that will clarify if they’ve been successful.
So far, this sounds pretty familiar - when we’re doing the job right, having everyone agreed on these two basic facts goes a long way towards setting us up for success.
The antipattern: Teams will start working on a feature, requested by a stakeholder or a customer, without fully understanding what the problem really is, or how to measure success. The only goal is to get it into production.
2 & 3. Hypothesis & Discovery
They then propose a method to solve this specific problem. Actually, they propose multiple ways - and then go off to compete amongst themselves to build a scale model that tests which has the highest likelihood of success. The key thing here is that this is a timeboxed competition, sometimes testing just the one element that they’re unsure about.
There are obvious overlaps with modern product development:
They’re analysing and conducting a riskiest assumptions test
They’re not building V1 of their solution - just something that proves that it’s worth the time and effort to build the real thing. Call it an MVP, or the outcome of a Design Sprint, or any of the many approaches that you can find in Testing Business Ideas. Or call it what it actually is: an experiment.
So far, this overlaps directly with the Double Diamond design process - figure out what problem to solve, then figure out how to solve it. (I love this approach so much that you might notice it’s the inspiration for the Out of Owls logo.)
If nothing works well enough, it’s back to the workshop to rejigger and get something that validates moving forward. Through the magic of TV editing, the Mythbusters crew always seem to sail through this stage in amusing and educational ways.
The antipattern: Committing people’s time & energy to building out a full-fat solution without any validation of the approach. Don’t despair, though - there are some great practices to overcome this. Try using a Pre-Mortem to identify what might the team thinks the biggest challenges are, and a Riskiest Assumption Test as a first step before committing any other time or resource down a treacherous path.
4. Delivery
It’s only at this stage that you commit to the actual build. Invariably, things will differ as you scale up, and there will be challenges to get it done on time and on budget. Again - strangely - the magic of TV makes this amusing. Your mileage may vary.
The key takeaway here is that this aspect is planned out rigorously, it’s budgeted and timeboxed. And if it doesn’t go as intended, then they stop. They don’t try and do it in the next sprint - they call it a day.
They also don’t concern themselves with other work during this time. The entire team is assembled, dedicated, and focused on achieving this one thing.
The antipattern: How many times have you heard a team say that they’re just one sprint away from launching? Launching something is often better than waiting for perfection. (This may not apply to products in regulated industries.)
The other antipattern: Teams that work on multiple things at once often don’t make any significant progress on any of them. They confuse being busy with being productive.
5 & 6. Launch & Feedback
Delivery is completed by making sure the thing does what it was actually designed to do: it must run successfully (if at all possible) and the results measured. This is compared with the original hypothesis - did the team prove that the myth is plausible? Or did they prove that there was no reasonable way to make it work?
Here’s why this is such a valuable model for modern product development: either answer is acceptable and celebrated. At the end of every episode, the team has learned something definitively. Sometimes, they learn that an alternative method or alteration to their hypothesis has a better chance of success - but those are considered out of scope and almost never attempted.
That’s not exactly true, actually: once in a while, they’ll revisit a myth with the new information, but - and this is the crucial bit - not as part of the original experiment. The new approach goes through the same process in a later episode.
This is the part we get wrong so much of the time: we treat development as an inevitable march forwards, with defined timelines and budgets that result in a defined and predictable business result. As someone recently said so well: we’re trying to fit an agile development process onto a waterfall business model… and the world just does not work that way.
The laughable thing is that the predictability that strategic planning so desperately strives for almost never happens. It’s business fiction, as believable as any fantasy epic. Your management team knows this - but the weight of process and accepted methodologies conspire to bring it back again and again. You need to keep reminding everyone to watch an episode of Mythbusters to ground them in how this actually works.
The antipattern: Teams that find themselves in feature factories are concerned with getting things into production - but not about what value the work has enabled. If you’re not measuring business value, then there’s a huge chance you’re just trying to keep busy for appearance’s sake.
7. Fun
There is one difference between what the Mythbusters get up to and what we do: at the end of most episodes, they try to go for the most spectacular failure that they can by supersizing one of the variables. Often, that’s explosives: nothing makes the team happier than blowing something up.
There might be value in pushing your experiments out, taking a shot after they’ve been validated to see if you can get an even better result - but please, don’t do anything that’ll result in property damage.