How to do Discovery and Delivery at the same time … with Pivot Triggers
Introducing a simple intervention that helps you dodge sunk cost bias as you escape from zombie initiatives
UPDATE November '21
The methodology has evolved quite a bit since this was published, although the core concepts outlined in the article below remain the same.
For the latest updates and access to courses and resources, head to pivot-triggers.com
A teeny aside before we dive in: I’ve presented Pivot Triggers in the context of digital product teams. But you can apply the idea to any project you’re doing, with others or by yourself.
If you give this a try, or you already do anything similar, hit reply and tell me – I’d love to hear about your experiences as I keep developing this.
Imagine. You have to break some news to your team. Picture their little faces all stacked up in the video call software as you say:
“Thanks for all your hard work over the past 8 months. I’m afraid this initiative didn’t work out how we hoped and we’re cancelling it. All your hard work ... it’s going in the bin.”
What? Nobody would really say this, would they? Not outright. Not like that.
And yet this kind of situation – ideas killed too late, time and effort wasted – it happens all the time.
Before we get into how to avoid it, let’s first rewind to the beginning of the 8 months and see how and why this fate came to be …
The beginning of most initiatives is all energy and positivity:
“This is a clear winner! This is The Thing that’ll give us the breakthrough we need!”
And off you all march.
But as time goes on, you start to sense cracks, problems and obstacles. Momentum dwindles. The Thing is taking longer to finish than anyone hoped, and it’s turning into a bit of a grind. And you start to feel a creeping uncertainty. Maybe … just maybe … this initiative isn’t as valuable as we thought.
This creeping uncertainty is a signal that the initiative is becoming a zombie initiative.
But by the time that signal is alarming enough to prod you into reconsidering, it’s too late. You’re trapped by sunk cost bias. The business has put money and clout behind the initiative and everyone’s worked freakin’ hard. It’s too painful to admit that it might not be The Thing that’ll give us the breakthrough after all.
And so the zombie initiative shambles on. Nobody can bring themselves to be the one who delivers the headshot. It’s only months or even years later — perhaps after the original team have all moved on to other things — that someone wonders why we’re still supporting that part of the system.
Now, let’s explore a second scenario we could choose instead …
Imagine. You have to break some news to your team. Picture their little faces all stacked up in the video call software as you say:
“Check it out – this initiative isn’t quite meeting the minimum signals we set for two weeks in, so we’re going to change course.”
And then imagine the whole team on the video call saying:
“That’s cool.”
… and then jumping to figure out what’s next: quickly repurpose some parts, throw away others, and pivot the initiative.
Imagine if the team had treated the whole initiative as an experiment for rapid learning, instead of as a precious artefact to polish and protect.
Hard to imagine in most places, right?
After years of trying (and failing) to push companies and teams into outcomes-first thinking, I decided to try a slightly different approach with my team. And when that second scenario played out in front of my eyes, it was so exciting that I wanted to share that approach.
From what I’ve seen in a few contexts now, this lightweight intervention (I’m calling it Pivot Triggers) seems to do a bit of a magic trick by making our delivery work also discovery work. It’s helped kill a few initiatives before they turned zombie. And it even seems to go some way towards the product Holy Grail: aligning the needs of business leadership, product teams, and customers.
Below, I’ll share:
3 principles of Pivot Triggers – why they seem to work
8 quick steps to using Pivot Triggers – the best approach I’ve found so far
More detail about every step, including a worked example
Feel free to adapt this and make it work for you and your teams. There’s no such thing as a one-size-fits-all method.
3 principles of Pivot Triggers
Principle 1 : Start where people want to start
Secret sauce: don’t fight the flow.
Most people, most of the time, seem to start with an idea. So that’s where Pivot Triggers start too.
Instead of trying to force people to ignore the things they want to do and instead think about outcomes, Pivot Triggers let us begin by talking about the output and guide us gently to talking about the outcomes. So if you’re already sold on outcomes over outputs but sometimes struggle to put it into practice, Pivot Triggers are a helpful bridge. (Great for setting OKRs, for example.)
Most businesses, most of the time, also want a plan. And so Pivot Triggers help us create and share a clear plan that gives predictability, but can also change when it needs to. They fit really well if you’re using roadmaps and sprints.
Principle 2 : Think “investing” instead of “estimating”
Secret sauce: do the work in the order that reduces risk as fast as we can
Most teams start most initiatives without clarifying the boundary between success and failure for that initiative.
Your engineers are probably familiar with the debate around estimation. That’s where you think about what you want to build, and then estimate how long it’ll take to get it all done. The unspoken assumptions are often something like “our customers will want this, because it’s obvious to us that they ought to” and “this thing will work in the end, if we keep going long enough.” Once you’re busy working to the plan, the only signal telling you that the plan isn’t working is that vague sense of creeping uncertainty we came across before.
Instead of estimation, think investing. That’s where you ask yourself: what’s going to be better for people in the world after we’ve done this, and how much time and energy is it worth us spending to get to “better”?
You’re more interested in how to know when you’ve done enough. Your focus stays on figuring out how to actually get to “better” from where you are today, not on completing the plan you had a few months ago.
Principle 3 : Without total shared understanding, it’s hard to kill ideas
Secret sauce: collectively know in your bones that nothing’s a sure thing, and that we want to fail well.
Lots of people talk about wanting to fail fast and kill bad ideas. They want to “celebrate failure” as much as success, and use this to learn.
This is all pretty easy in theory, but incredibly emotionally difficult in practice. Once you’ve poured time and love into a project, you’re subject to a bunch of biases that make it hard to see it clearly any more.
Think of the zombie movie trope where the hero’s mum turns into one of the undead horde, but our hero won’t let the group finish her off, even though none of the person they loved is left in there. That’s the deal with zombie initiatives.
So setting and committing to your Pivot Triggers has to be a team thing. The team doing the work needs to:
agree that they’ve all had enough of working on zombie initiatives and want to kill those bad ideas earlier, even though it’ll be painful
set their own Pivot Triggers as a team and sign up to be held to them
get explicit sponsorship on this approach from their main stakeholders.
8 quick steps to using Pivot Triggers
I’ll break these down in more detail afterwards, and work through an example. But first, a high level overview:
[Initiative] Describe the idea. What’s the plan, and what will be better for us and our customers in the future if your initiative is a roaring success?
[Failure] Do a premortem. This is where you time-travel to a future where the Initiative failed and you wish you’d abandoned the plan. What went wrong?
[Behaviours] Describe in detail what you’d be able to see people doing differently in each future above. Customers, colleagues, prospects, etc – what’s changed for them in the world where the Initiative has worked vs the world of Failure?
[Sequence] Order the Behaviours from leading to lagging. Which behaviours could you expect to see 1-3 days from now, vs 1-3 weeks, vs 1-3 months? How might you run simple experiments to provoke some behaviours faster?
[Signals] Brainstorm how you might detect different Behaviours. There are some Behaviours you want to see, and some you don’t. What Signals can you look for, when will you look for them, and how might you measure them?
[Triggers] Set your “enough” point for each Signal. This is the minimum level you need to see for each Signal. Below this level, you’d want to be reminded to pivot the Initiative — or perhaps even kill it — because it’s not worth any more investment of time and energy as it stands.
[Open up] Share your Triggers with your team and stakeholders. Check that everyone’s on board and understands. You might need to explain the approach. And you might need to make a couple of tweaks to your Triggers. Emphasise that the plan will probably change, and that this is a good thing.
[Persist] Revisit your Triggers at least weekly. Ideally more often. Use them in pitches, retros, stakeholder review sessions, sprint planning ... This isn’t easy, but you need to hold yourself to the emotional challenge of spotting zombies early. The escape is worth it.
These 8 steps compress to a handy mnemonic: IF BS STOP.
In case you need more, let’s break the steps down in more detail…
More detail about every step, including a worked example
1. [Initiative] Describe the idea.
Set Pivot Triggers before you start a chunky thing
You can think more clearly before you’re stuck in the weeds, and before sunk cost bias kicks in. But if you’re in the middle of something and feeling the creeping uncertainty, go ahead anyway – I suspect they can still help.
Start where you naturally start:
Outline your plan
What are you going to do and why?
And if you nail this thing, what’s going to be better in the world afterwards?
Example: we’re going to build <New Feature> into our product. If we nail it, our customers will be delighted and we'll make loads of sales.Note: Pivot Triggers work best for a decent-sized chunk of work: something that’ll take longer than a couple of weeks but shorter than a couple of years.
2. [Failure] Do a premortem.
What if it doesn’t work out? What if we finish this initiative and later find ourselves thinking, “uh, wish we hadn’t done that after all”?
The premortem is a brilliant exercise created by Dr Gary Klein. I first came across it in the book Decisive by Chip & Dan Heath.
We’re all familiar with the idea of a postmortem, where we investigate why a person (or a project) died. The idea of a premortem is to use our skills at diagnosis, but use them before we start, not wait till we’re staring at a project’s corpse. For Agile folks, it’s a lot like a retro … but in the future.
If you’re already familiar with the idea of the premortem, I’d just add these notes:
Get the whole team to do the exercise together. We can only build the shared understanding we need if we collaborate on this.
Make a big deal of the time-travelling. It’s surprisingly important for setting good Pivot Triggers that we’re looking backwards at a failure and diagnosing it, not looking forwards at risk and estimating it.
Use a really big board (online or offline) with plenty of space for Post-it notes that you can spread around and shuffle. Miro’s worked well so far, but other tools are available.
Example: It's next year, and <new Feature> failed because …
* customers didn’t need it enough
* customers didn't realise it was there
* it was too hard for our customers to use it
* customers used it once but it didn't work for them
* we couldn't make <tricky technical bit> work well enough
* our customers' needs changed while we were building it
* we "gold-plated" the code too early
* team members got pulled
* there was an alien invasion3. [Behaviours] Describe in detail what you’d be able to see people doing differently in the two futures above.
Make the output from the premortem actionable
Many teams already use techniques like the premortem. But often, they do the exercise and then neither refer back to what they learned nor watch out for things going wrong.
You’re going to fix that.
Take the most important failure modes from the premortem and compare them against the successes you outlined when you described the initiative. You probably want to move them all to a fresh space on your whiteboard.
Consider each failure and success mode. What will you be able to see people doing differently in each of those cases? Include customers, prospects, colleagues, partners, etc. and focus on their behaviours.
Add these as Post-its.
Note: there are always a mixture of failure and success modes: some we can influence (e.g. customers didn’t want it) and some we can’t (e.g. alien invasion). It’s helpful to focus on the things we can influence.
Example: For the failure/success mode that customers didn't/did need <New Feature>, we might see:
Total failure:
* no customers use <New Feature> after it's launched
* even after we send emails introducing it ... nobody clicks
* customers who do use it are so annoyed that they churn
* sales folk never mention it when they're selling
Wild success:
* customers are snatching <New Feature> out of our hands
* they email to tell us how much better it's made their lives
* sales increase and it's linked to that feature
* our marketing team include <New Feature> in all the materials
* no customer ever churns4. [Sequence] Order the Behaviours from leading to lagging.
Then tackle the work in an order that catalyses behaviours earlier – which decreases risk faster.
Many of the behaviours you’ve described in step 3 are going happen after launch. That’s way too late for Pivot Triggers! Those are called lagging indicators. We want to note them down, but we’re much more interested in finding leading indicators.
So now you sequence the behaviours into time-buckets based on when you’ll see them:
1-3 days
1-3 weeks
1-3 months
1-3 quarters
You can simply rearrange the behaviour Post-its on your whiteboard.
Often, you’ll find you haven’t got much in the 1-3 days and 1-3 weeks boxes. You need to fix that: there are always behaviours that you can start looking for much earlier than you originally planned.
You might need to change the order in which you tackle the work. And there are always simple experiments you can run right away.
For instance: one behaviour we almost always look for early is whether anyone’s interested to talk with us about our initiative. When recruiting for research sessions, can we find anyone who wants to share their experience with the problem we think they have? And then: are any of those people prepared to spend time with us regularly, to help us iterate on the work?
If we can’t find people to research with, how exactly will we find them to sell to?
There’s lots more on how to design this sort of “pretotyping” experiment in The Right It by Alberto Savoia.
Example: For the failure mode that customers didn't need <New Feature>:
There are some behaviours we'd only see after 1-3 quarters:
* no customers use <New Feature> after it's launched
* customers who do use it are so annoyed that they churn
But also behaviours that we could experiment on in 1-3 days:
* even after we send emails introducing it ... nobody clicks
Why couldn't we send some of those emails TODAY? We can reframe the offer so the customer can pre-order, or request early access. We can spot this behaviour before we've written a single line of code, instead of after months of work.
* sales folk decide never to mention it when they're selling
Same. Why couldn't we chat with the sales folk today? We can get their perspective. Maybe they can even slip it into some pitches over the next few weeks and let us know how it lands?5. [Signals] Brainstorm how you might detect different Behaviours.
You’ve now got a list of behaviours you want to look for.
For each behaviour, add Post-its for the signals the behaviour will generate. How can you measure those signals? You can list a few for each behaviour, but there might be one obvious choice.
Note: I’ve seen so many people get tangled up in knots when thinking about metrics and KPIs, but I’ve noticed that this step is quick and easy when you’re clear about which behaviours you want to see (or not see).
Now pick the 4-6 clearest signals that you’ll use for that 1-3 week time period. If you’re feeling punchy, you can also pick another 4-6 for 1-3 months. They can be the same or different. Move them to a clear space on your board.
Example:
Fail behaviour: After we send emails offering early access to <New Feature> nobody clicks, and nobody signs up.
Success behaviour: After we send emails teasing New Feature, lots of customers leave their details to request early access.
Some signals we can measure:
* Number of emails we sent
* How many emails were opened?
* How many people clicked on the link?
* Number of early access requests we got
(This is a classic email funnel. On top of this, we're going to read email replies and ask our account managers if any customers have mentioned it to them.)6. [Triggers] Set your “enough” point for each Signal.
At what boundaries will you want to stop and consider a pivot?
For each of your 4-6 signals, set the boundary between failure and success. Precisely what level of that signal should trigger you to stop and rethink the initiative?
Think of them like the set point on a thermostat: when the temperature is above the set point, we leave things as they are. When the temperature drops below the set point, the boiler is triggered.
As you’re not literally a thermostat, you’ll need to set dates to check in. You’ll usually start with a set of Triggers to check in 1-3 weeks, and another in 1-3 months.
It can help to use the time-travel trick from the premortem. Pick your Triggers based on what’s going to make you feel “this wasn’t worth doing” by that point in the initiative. You’ll probably set fairly modest Triggers in the short term, but need much more encouraging signals as you invest more time and energy.
Perhaps you feel it’s worth doing as long as one person uses the thing, or you make one sale? Or perhaps you need 100 sales to make it worthwhile – or 100,000? What results do you need to see to make it worth having invested the time and energy?
Note: don’t overthink this. You’re not tying yourself to kill everything whenever you hit a Pivot Trigger. You’re just setting a reminder: pay attention and dig deeper, because the signals aren’t looking as good as you planned when you made this investment.
Now, congratulations! You have 4-6 Pivot Triggers ready to go.
Example: for the email experiment, our Pivot Trigger might be:
We'll pivot if we see fewer than 20 early access requests from about 160 click throughs, based on sending about 500 emails. We'll check in on our Pivot Trigger next Wednesday.
We'll send the emails in daily batches of 100 so we don't risk overloading demand. We might try different pitches if the first doesn't land.
We'll track all the signals as we go. 7. [Open up] Share your Triggers with your team and stakeholders.
All the steps above can be done in under 2 hours, once you’re up and running. That can sound like a lot of time to gobble up from a busy team with sprint goals … but it can literally save months wasted building wrong things.
But only if you follow through with this most important step.
Copy your 4-6 Pivot Triggers from the whiteboard. Tidy them up, make them readable, make them understandable, and then share them with your stakeholders and colleagues.
How you do this will depend on your context.
If you use OKRs, it’s easy to reframe your Pivot Triggers as OKRs. Or you might use roadmaps, pitch documents, Amazon-style press releases, or another format for aligning around what work you’re doing and why.
You might find that people question or challenge your Pivot Triggers. That’s good: it means you get to have conversations about what level of impact will make it worth the effort you’re putting in.
Note: each conversation you have only helps to make it clear that success isn’t a given, and that the plan is very likely to change.
Once you’ve got alignment, you’re ready to start work.
Example: One team coined a memorable acronym for one set of Pivot Triggers: VOMP.
Another used a slide deck to set out the experiment they were running with the actions they'd take for different results. 8. [Persist] Revisit your Triggers at least weekly.
When you’re explicit about Pivot Triggers, everyone gets used to the idea that everything might change, and that’s OK.
This helps the team who are doing the work. The designers and engineers can avoid the trap of gold-plating or over-designing it too early.
This helps the stakeholders who invest in your team. They can see early if the plans don’t look like they’ll work out as hoped. They usually have visibility of a broader context, and might have ideas for repurposing the work, get you access to people or resources you need, or otherwise help make things happen.
This helps everyone. We know that if things change, it’s not down to executive whim, it’s based on Pivot Triggers we’ve all agreed.
So put your Pivot Triggers on the wall, add them to update emails, talk about the progress in your sprint planning, share them in email updates, make them a gif in Slack, talk about them in company all-hands, ...
Example: A team believes their initiative could be a new, independent product the company could sell. They set Pivot Triggers to test market demand and build a lightweight MVP to release.
Their senior stakeholder sees the signals coming back and decide that it doesn't have legs as a standalone. But they have an idea to pivot the initiative and repurpose it to add value in another area of the business.
And the team says, "cool," and dives in to set a new set of Pivot Triggers.As I mentioned at the start, if you give this a try, please hit reply and tell me about it. This is a work in progress, developing all the time.
And if you know anyone who might be interested in this approach, I’d love for you to share it. I want to see more teams and companies get out of “Thoughtland” faster, and want to find out whether Pivot Triggers can help.
Tom x
Thanks for help with developing and testing Pivot Triggers in the wild go to my colleagues at Qubit, especially Jason, Serdar and the “Lens” team (who gamely ran with the developing idea), Toby (who realised this was less of a kill switch and more of a ‘pivot’ switch), Simon and Chris (who made space for the team to run with this), and Tone, Dani and the “Pimms” team.
Thanks for help with writing and editing go to Corissa Nunn, Jamie Mill, Jorunn Newth, Anthony Hobday, James Russell, Dan Turner, Christian Crumlish, and Edo van Royen.
References:
Jamie Mill pointed out that this is similar to fail conditions
The premortem was developed by Dr Gary Klein
Alberto Savoia’s idea of Pretotyping informed the early experiment idea
Pivot Triggers work well alongside Teresa Torres’ Opportunity Solution Tree
Investment instead of estimate was inspired by Basecamp’s Shape Up
The 1–3 timescales are borrowed from John Cutler