I recently gave a talk about Pivot Triggers, the approach that helps digital product organisations be way more effective at discovery while also continuing to deliver.
Getting to this approach took me decades. Decades of struggling with outcomes vs outputs. Decades of watching zombie initiatives shamble on, seemingly powerless to kill them. Decades of trying to persuade colleagues and executives to experiment and learn ... before I finally realised what I was getting wrong.
I was excited about getting the opportunity to share that whole story in this talk.
My favourite part was being put on the spot by all the excellent questions afterwards. I've included the questions and short versions of my answers below. But first, here’s the video (it’s about half an hour of slides and half an hour of Q&A) :
At the end of the talk I promise to share a cheat sheet. I started one that I’ve been using to run Pivot Triggers workshops over the past month. But I also realised it’s gotten a bit out of hand – it’s become more of a book. I have separate plans for that, which I’ll talk about soon.
I will also share a proper cheat sheet here later this week.
Now for the Q&A:
For conciseness and clarity, I’ve paraphrased my answers below, but I’ve included the time stamp for each question so you can find it in the video if you’re a completist and want to hear the rambling too.
Q. How early do you set triggers? (30:56)
A. As early as possible. Ideally, you start the moment you collectively “land” on an idea and start to plan it with a team. While you're still figuring out what you're going to do and how you're going to do it, that's the time to zip through the workshops and set your first set of Pivot Triggers. The longer you wait, the more sunk cost bias will set in, and the harder it will be to kill or change an initiative.
There’s another reason too: setting Pivot Triggers helps you to build shared understanding with the team and to create a project plan.
Q. Any tricks for getting buy-in for using this method? (32:31)
A. As clichéed as it may be, this is an ask forgiveness, not permission situation. Simply run all the workshops with the whole team who are going to work on the initiative. You don’t even need to tell them you’re doing Pivot Triggers – at first you’re “just” doing a pre-mortem, later you’re just thinking about behaviours, etc ...
And after you’ve worked through the steps, you should find that the process helped your team figure things out, and your draft Pivot Triggers help start more meaningful conversations with stakeholders. Your Pivot Triggers are a few short statements that say, “we think you want us to do this stuff, and we think that you want us to pause and think again if things aren’t working out in these specific ways. Is that right?”
Q. Do you try to set targets for the lengths of iterations? (35:43)
A. Most teams wait far too long to start experimenting and learning, so the closest I get to trying to set a target is that I ask: “how might we get answers in 1-3 hours instead of 1-3 weeks?” (Referencing John Cutler’s 1s and 3s.)
In general, you want to learn and change as rapidly as possible at the beginning of an initiative, when uncertainty is highest. The more iterations you can pack in to any given time period, the faster you get to learn. You have to balance that against the emotional energy and cognitive load that each iteration takes, so as not to burn out. (The fastest team so far managed 1-week iterations.)
When in doubt, it’s usually practical to fit in with whatever your team’s cycle time is. For many teams, that means 2-week sprints.
Later down the line, you should notice the rate of change from one iteration to the next has slowed down. At this point, you’ve mitigated a lot of your risk, and you can shift more of your energy into efficiency, scale and polish. (The same team who managed 1-week sprints for the first 3 months of an initiative chose to move to 2-week sprints when the rate of change slowed.)
Q. What kind of maturity should an organisation have to try this? It seems quite complex, even though the acronym and presentation is quite simple. I imagine many businesses don't have the maturity to handle this, when many organisations are not even thinking about dual-track Agile yet. (38:25)
A. I understand that they can seem complex conceptually, but having taken lots of teams through the workshops step-by-step, I've been surprised by how quickly people have “got it” and bought in.
That said, I haven't yet tried this in a company with really low maturity, but I'm keen to do so ... and I can't see how it would hurt. All you’re doing is starting a conversation about how things don’t always work out how you want. Most people know this in their guts – everyone has had plans that failed.
I suspect one universal challenge is that it’s hard to imagine doing things any differently from the way they’re already being done. That’s why something I’ve aimed for with Pivot Triggers is that you don’t have to change the way you’re working to start using them.
Q. How do you choose a signal independent of the level of fidelity of your prototype? (41:10)
A. I asked for more details on this – what's the underlying concern? If this was your question, please get in touch.
Q. If focused solely on results, how do we prevent accessibility from falling by the wayside? (41:50)
A. There's nothing to stop accessibility being one of your Pivot Triggers. What behaviours will we see if our thing isn't accessible enough? How can we measure those? What signals will make us stop and think?
Most teams, most of the time, haven't had a conversation about what “better” actually means for each person. So we all bring along different secret assumptions about where we’re trying to get to. One person cares about accessibility, another about code quality, another about using a new framework, another about feature-completeness. Then we all fight about what to do, because we’re all trying to get somewhere different ...
Q. Have you tried combining Pivot Triggers with the Lean UX Canvas (link to Josh Seiden and Jeff Gothelf)? (48:53)
A. I realised that Pivot Triggers kind of fleshes out 3 of the steps of the Lean Canvas approach into 8 steps!
It’s also a bridge to desiging experiments. It’s easy to agree that we should experiment, but in practice, experiments are hard to design and can stress out stakeholders if they don’t have clear timelines. With Pivot Triggers, we lay out a clear, justifiable sequence of timeboxed plans. We also smuggle in some experimental discipline – as we have to set up success / failure boundaries before we design our experiments.
Q. How can a culture of pivoting too often or too soon be mitigated? (44:25)
A. The key point is that when I say Pivot, I mostly mean a “micro-pivot”.
We’re not automatically killing every project before it’s had a chance to find its feet. We’re just introducing a little human buffer into the initiative instead of burying our heads in the sand. Perhaps a pivot means we adjust the language in the email we use to reach out to customers. Perhaps a pivot means we adjust part of our technical approach. And then occasionally, perhaps we do realise that we’ve misunderstood something fundamental and we need to put the whole idea down – at least for now.
All that said, I actually haven’t experienced anyone pivoting too often or too soon. What I have experienced is a related frustration from the people who have to do the work: when they feel that plans change too frequently, which leads to context thrashing and unfinished work piling high. (Sometimes called “executive whim-driven development”). That culture tends to come hand-in-hand with unspoken assumptions that “no but this new shiny thing will definitely work.”
Pivot Triggers aren’t about dropping an initiative suddenly because another, shinier idea has come along. They’re about sticking with an idea for as long as it takes, while remaining open to serendipity and new knowledge as we work – rather than keeping our heads down and building for months or years before we learn anything.