Can you stop the pendulum swinging?

Constraints, processes and sailing through the middle.

Originally published via Substack, Feb 16 2025.

↓

One person says, “you must ship to learn!”

Another says: “you much research first!”

But who’s right?

Both!

And neither.

I’ll tell you why in a moment, but first:

• Grab one of a few spots left in my Intro to Multiverse Mapping session this Tuesday. Alongside a few other dazzlingly smart and magnetic people, you’ll feel exactly how making a Multiverse Map helps you connect the work with the goals by way of the conditions for success – even when the goals and success are ambiguous.
• I’ve done several of these sessions now, iterating on the structure and content. Every session is clearer and punchier than the last. Massive thanks to Kyle, Al, Peter, Andy, Shay, Christoph and countless others for your feedback and support. If you have a strong concept you’d like to hone, I recommend this repeated-live-workshops approach.
• I can also bring this workshop (and others) in-house. I’m already booked to deliver it for an institute and an online conference over the next few months. Message me and we’ll figure it out.

OK so back to our shipping vs research debate …

I’m confident that your product organisation at one time or another has:

1. shipped quick wins … except they turned out not to be all that quick ... or wins.
2. invested in research … and it took ages and then didn’t deliver the clear actionable insights that everyone was hoping for.

You’re not alone in this.

Most product organisations I’ve seen tend to swing between these extremes like a pendulum. There’s a slow, lingering turnaround at one extreme, then it swooshes quickly past the middle ground and heads to the other extreme.

At one extreme, there’s too much action and not enough thinking. Build build build! And shh! just keep building ... even when everyone secretly knows it’s doomed. At this extreme, we don’t get results because we’re shipping the wrong things, while usually also spinning up even more things that we need to ship. 🐉

At the other extreme, there’s too much thinking and not enough action. It’s all research, debates, false starts, and constant pivots. At this extreme, we don’t get results because we’re not shipping anything at all. 🌀

Occasionally, one of those extremes is exactly where an initiative needs to be.

There are times when you do need to get your head down and just ship something that’s clearly needed.

And there are times when you absolutely need to pause and do deep research.

But a typical initiative floats in between the two extremes. Some parts will need research first. Some parts will just need building. And some parts need other ways of working. It’s a mixture of different parts. A mixture that’s dynamic over time.

It would be ideal to simply know the appropriate approach for each part and do just that.

That “simply know” is not so simple – it’s often not obvious which parts are which.

But there’s a bigger challenge: organisations tend towards one process for all the work. Every initiative has to go through the same phases, the same rituals, the same narrative, the same decision gates. Whether it’s MVPs, Shaping, Agile, Lean, Discovery-Alpha-Beta, or something unique to you, any process works well for some parts of initiatives and poorly for others.

This tendency is a kind of constraint that seems to crop up in many organisations, especially strongly when they’re trying to “get a handle on productivity”.

You’ll occasionally see this constraint acting globally across a whole company (e.g. “we all do OKRs”). But it’s often contained within divisions (“sales can do what they like; this is our master process for product!”).

And this tendency towards one process makes a lot of sense:

1. It feels fair to put all initiatives on a level playing field so the best can win out.
2. It feels efficient to limit process overhead by reducing variation in ways of working.
3. It feels rational to be able to assess all initiatives (and teams) using one set of criteria.

So the tendency towards one process is not a bad constraint in itself – especially if the only apparent alternative is “people doing stuff at random”. But it does come with tradeoffs, where some of the work you need to do will be a poor fit for the process. This gets really painful when the nature of your work shifts. When your process becomes inappropriate for a lot of your work, that can send the pendulum swinging to the other extreme.

I remember one organisation where a team wasted hundreds of hours of research on an already-solved problem. And another where a team repeatedly shipped smart-sounding “quick wins” that also repeatedly crashed and burned. Wait no, … that was different teams at different times in the same organisation.

So what can you do about it?

Acceptance is one option. You can learn to enjoy watching the pendulum swoosh from one extreme to the other (“ah there you go again, my old friend!”) and adjust how you work to fit whatever process is currently trending.

I suspect it’s impossible to overcome a constraint like this simply by trying harder or explaining it better. (says he, as he attempts to explain it better …)

But I think there is hope if you can playfully shift or reimagine the constraint itself.

You can lean into enabling one process but use that process to create a stable zone between the extremes – somewhere the pendulum can chill out rather than racing to the extremes.

This new one process needs to be a viable alternative that meets the needs:

1. It must create a level playing field (even across work that’s not equal).
2. It must feel efficient, without creating more meeting or admin overhead.
3. It must present as a rational way to assess and monitor initiatives.

The “one process to rule them all” I’ve found works is this:

Make a testable model of your theory of success for the initiative. Then test the weakest parts.

The model you make should enable you to:

• connect the work in the initiative to the high-level goals (even inexplicit ones)
• zero in on the handful of critical conditions that are necessary for success
• break down into parts the work that will address those conditions
• identify the appropriate method for each part
• prioritise the parts so that you focus your efforts in the right places first
• give you Speed-to-Signal, enabling you and others to gauge progress, and — critically — to adapt and update your model rapidly.

I’m backing Multiverse Mapping for this. Other methods are also available ;)

For an organisation, Multiverse Mapping fits into our larger Speed-to-Signal System, which tackle other organisational constraints and enable the whole organisation to use appropriate methods, act and adapt.

Going back to the meme above (and mixing metaphors) Speed-to-Signal System puts you on that little boat in the middle, navigating the choppy waters between the extremes, crying, ayy lmao.

For a taster of our latest thinking, the 5 constraints are shaping up as:

1. Visual Modelling
2. Antifragile Prioritisation
3. Categorisation of The Work
4. Cadence for Signals
5. Influence through Stories and Options

Speed-to-Signal System tames that wildly swinging pendulum and supports you to research what needs research, ship what needs shipping, and deliver results.

So if you’re also tired of the pendulum swing, let’s talk. At Crown & Reach, we offer free advisory sessions. Or we’d love to see you at an Intro to Multiverse Mapping session.

Tom & Corissa x