The Product Development Triathlon
The debut of 3X: Explore/Expand/Extract
Republished from the copy published 25 March 2016. Republished from the original published on 19 July 2016.
Because I keep careful notes these days I can identify the precise moment when I asked the question I should have asked twenty years ago: what if those waterfall folks aren’t wrong, what if they are solving a different problem than I’m solving? What problem is that?
The past four months have been fecund beyond belief for me. I have changed how I approach software development but also life in general. Different risk profiles call for different approaches, but I can sometimes choose which risk profile I use in a situation.
Trying to communicate my insight has been frustrating. I feel like a puppy on a hike. I’ve run ahead, found an awesome stick, brought it back, dropped it at my masters’ feet, and now I’m barking madly without anyone paying to attention to just how awesome the stick really is.
I awoke in the middle of the night with a new approach, a new metaphor to go with the new vocabulary I’m using. Here goes.
Explore/Expand/Extract
Product development proceeds in three phases:
Explore–the risky search for a viable return on a viable investment. Successful exploration is unpredictable, so the highest expected value strategy is to reduce the cost of experimentation and put a little investment into many, uncorrelated experiments. If you’re lucky, one of these experiments turns out to be unexpectedly successful, which leads to:
Expand–now things are going nuts (think Pokemon Go or Facebook Live Video). Unanticipated bottlenecks appear. All you have time for is to eliminate the next bottleneck just before it derails you. Once growth becomes routine, it’s time to:
Extract–now the shape of the problem and solution spaces are clear. One euro in equals three euros out. Playbooks emerge: here’s how you roll out the service in a new city. Economies of scale matter: delivering the service at lower cost is more profitable.
There’s hours and hours of cool stuff implied by this model, but that’s the basics.
Lessons from the Triathlon
Each phases requires different equipment, different technique, different training. Software product development requires different tools, techniques, and value systems in the three phases. (The answer to the ??? in my notebook is “Efficient Extraction”.)
You can’t mix the phases. Just because biking is the fastest phase in kilometers per hour doesn’t mean you can go faster by taking your bike into the water. (I was dealing with a project prematurely moving from explore to expand just yesterday.)
The transitions are awkward, but they count. If a project goes from one phase to another and the team doesn’t notice, it’s like trying to swim on a bike. Not so good.
Only organizations that can execute all three phases can complete a race. If you just don’t feel like running, then it’s not a triathlon.
Unlike a triathlon, the same people don’t have to complete the phases. I specialize in exploration. As soon as expansion starts, I’m ready to start exploring again. As long as there is someone I can hand off to, this works fine.
The relative progress of the three phases roughly maps. Exploration (swimming) seems slow. Experiment after experiment fails. False hopes are dashed. Repeatedly. Then comes the “overnight success” of expansion (biking). Progress that would have taken months now happens in days or hours, just like a mile on a bike is way shorter than a mile swimming. Extraction (running) is more of a slog than expansion.
??? [hoping for suggestions from actual triathletes or poets]
Application
A few highlights:
Choose exploration. If you’re extracting and starting to feel hopeless or burned out, deliberately switch to exploration.
Accelerate experimentation. If you’re following all the rules and your experiments aren’t getting anywhere, break the rules to experiment faster. If experiments aren’t likely to last, quick and easy won’t cost you in the long run.
Transition. If things aren’t going smoothly, see if you’ve changed phases without noticing. If so, change the rules to match the phase you’re in.
I’m only four months in, so I’m sure there’ll be lots more to come. I hope I’ve convinced you that this really is an awesome awesome stick.
Very interesting. Some thoughts from a triathlete:
- The toughest part during open water swimming (aka exploration) is to know you are swimming in the right direction. Usually, you need to reach a specific landmark, and there are waves, wind, and chaos around you. Humans cannot swim straight to that point, so it's full of zigzags. You swim a bit to the right, then raise your head, look at the mark, and correct. You usually overcorrect/undercorrect, so when you raise your head again you need to change course again.
The big dillema is each look-ahead takes a couple of seconds. If all you do is look, you don't make progress. On the other side, if you don't stop enough, you'll swim very far in the wrong direction.
My coach told me it's common for people to swim 2.5k instead of 1.5k, and in some very windy races people even quit because they can't keep the right course.
- The race starts a few hours before the first phase. You need to have the basics right: good sleep, toilet, equipment ready in the changing place. My try to apply it: before you start exploring with code, you better have some conversations with customers :)
- The human body doesn't have enough energy to complete all the phases without any supplements (at least it's not suggested), you have to get some calories during the race. I would say a founding team can rarely start intact during all 3 phases, without an external senior hire/replacement.
- re-transitions - An Olympic triathlon is much easier mentally than a marathon. When you transition, it's almost like starting from scratch (especially the first transition). Different muscles, different pace, different views. As you said, it might require different people - but it can also give the same people a chance to 'restart'.
Not sure all of those work, but it was fun to try :)
I'm definitely not a triathlete.
The metaphor seems useful as a way of describing the phase changes (in the physics/chemistry sense) of software development.
Moving from solid to liquid to gaseous has a similar graph. Exploring is the solid state; trying different things, putting energy in, until finding the feature, marketing plan, whatever, that makes the shift happen and things become fluid and move, likely in ways we didn't plan for. ...
Maybe my metaphor doesn't work. Yours is better.