While the behaviour of software engineers is changing in response to better tooling, there’s little evidence that imminent replacement is underway. What we have been seeing is something we do have evidence for, decades of it, which is that software improves through conversation.

It’s now or never

Pair programming put two developers at one workstation, thinking aloud together. Laurie Williams’ research demonstrated that pairs produced fewer defects and better designs, even when the practice looked wasteful by any measure of individual output. The secret wasn’t doubling the number of engineers solving a problem. It was the conversation: explaining an approach forces clarity, being challenged before an assumption hardens into architecture solves potential problems cheaply, before they manifest as expensive bugs or outages.

Pair programming was championed by XP, but even the organisations that moved toward XP or later agile practices, tended to file pair programming under “nice idea, too expensive.” Two salaries for one keyboard.

So pair programming remained a niche practice, or became refinement, or distillation. Conversations in advance of the work instead of conversations during it. The rest of the industry optimised for individual throughput and absorbed the rework as a cost of doing business.

Surrender

Then copilots arrived. GitHub Copilot, Cursor, Claude Code, Amazon Q. Organisations adopted them with an enthusiasm that would have been unrecognisable to anyone who ever tried to get pair programming funded.

The adoption wasn’t driven by a sudden conversion to the benefits of pair programming. The impetus was the AI arms race. Every competitor was doing it. Every conference was talking about it. Every engineer wanted to get their hands on the tools. The cost was trivial; a copilot subscription is less than a rounding error on an engineer’s salary. Even the more sophisticated tools carry a cost profile well below a second engineering salary.

What we’re seeing now is the beginning of a new iteration of pair programming. The most effective adopters of AI explain what they’re trying to build and interrogate the response. They prompt the copilot to challenge, suggest alternatives, and force them to improve their approach based on feedback.

Ask me

Now, we see organisations that lagged on pair programming rushing ahead into the next stage. Conversations have gone from “we won’t pay for two humans to do this” to “what if we don’t need the human at all?”

Both positions ignore the same evidence.

The conversation that makes software better requires someone who knows what problem is worth solving. Someone who brings taste, context, an understanding of the user that isn’t derived from a training set. The human in the pair isn’t there to type. She’s there because she has organisational context and can represent the views of users, customers, and the history of the codebase. The act of explaining that to a thinking partner, human or machine, is how that idea gets refined into something that works.

Remove the human, and you still have a system that can generate code. Rapidly, fluently, at scale. You also have a system with no one to tell it whether the code is worth generating. Speed is table stakes. Knowing what’s worth building is where competitive difference lives.

The risk isn’t that AI gets too capable. The risk is that the organisation optimises the human out of the conversation before it understands what she was contributing to it.

Suspicious minds

Pair programming was rejected because it was “too expensive.” AI pair programming is cheap by comparison. AI-alone programming would be cheaper still. The price of the conversation has always been driven by the cost of the second participant. The value of the conversation is driven by the person who knows what’s worth building. A little less conversation could end up costing your organisation a lot.

In 1986, Fred Brooks identified two kinds of software problem. Essential complexity is inherent to the thing you’re building; it can’t be simplified away without changing what the thing is. Accidental complexity is everything we pile on top: the tooling, the process, the ceremony we invented to manage the work. Brooks argued that most of the dramatic productivity gains in software had come from removing accidental complexity, and that the essential difficulties would resist any silver bullet.

Forty years on, the distinction holds.

When a director of engineering stares at a roadmap that stopped reflecting reality around week three, her instinct is to fix planning. When a product leader watches teams deliver on time while customer behaviour remains stubbornly unchanged, his instinct is to standardise the product process. When a CTO adopts OKRs and still can’t explain why everything feels stuck, her instinct is to demand more reporting.

These are all attacks on accidental complexity. A better framework here, a new cadence there, a colourful dashboard that shows red, yellow or green against arbitrary targets. Each responds to a question. None address the essential problem, which is that the systems being measured are driven by invisible norms, unclear interdependencies and human relationships.

Stacks all the way down

Software engineers already have a mental model for this kind of layered interdependence. The tech stack is one of the first things a developer learns: a set of layers, each serving a distinct purpose, each affecting the behaviour of the layers above and below it. You don’t debug a slow service by rewriting the frontend. You trace the issue through the layers until you find the causes.

The same structural logic appears elsewhere. The modern data stack breaks data infrastructure into modular layers: ingestion, storage, transformation, analytics. Each layer has a clear responsibility. When something breaks, you know where to look.

I had that same instinct when examining the organisation itself. There’s a lot of agreement about the things generally covered in Octoshark newsletters. If the way that organisations should work isn’t controversial, why don’t they work that way? Tracing the causes, I uncovered five organisational layers, stacked on top of each other, each one shaping the behaviour of the next. These are independent of the organisation chart. This is the structural logic of the organisation, laid out in a way that engineers already understand, and that explains why easy fixes tend to fail.

The five systems

Every software organisation runs on these five systems. They’re rarely documented, and mostly embedded in culture and habit rather than policy. But they’re there, and they determine how the organisation actually runs.

Decision Systems

Who decides, and how fast?

This is the foundation of the stack. Every other system sits on top of how decisions get made. In some organisations, a product manager can commit to a direction after a conversation with her team and a check against the strategic objectives. In others, the same decision requires three meetings, a slide deck, and sign-off from someone two levels up who will forget the context by Thursday.

Decision systems aren’t about whether decisions are good or bad. They’re about latency and clarity. How long does it take from “we think we should do this” to “we’re doing this”? Who has the authority? Is that authority real, or does it evaporate the moment a senior leader has a different opinion?

The decision system is often unclear to newcomers. People expect organisations to make rational decisions, but that’s rarely the case. The decision system often has its own language, and its own politics, which are only understood (if at all) by the initiated. Decision systems shape everything above them. If your decisions are slow, unclear, or concentrated in too few hands, every other system will be impacted by that, and those impacts will manifest as dysfunction at higher layers.

Planning Systems

What do we commit to, and how do we handle uncertainty?

Planning sits directly above decisions. The quality of your planning is constrained by the quality of the decision system underneath it. If decisions take weeks, plans calcify before anyone can act on them, or worse, endless effort goes into plans [while reality gets on with other ideas](https://www.octoshark.net/p/eternal-sunshine-of-the-spotless). As a result, plans become wish lists that nobody owns.

Most planning dysfunction comes from treating uncertainty as a problem to be eliminated rather than a condition to be managed. This manifests as quarterly or annual roadmaps with fixed scope, fixed dates, and no mechanism for learning. When reality diverges from the plan (and it always does), the response is either to ignore the divergence or to panic.

The PandA framework addresses this directly: structuring work across a cone of uncertainty, from the possible to the promised, with built-in appraisal of outcomes. But flexible planning frameworks can only function if the decision system authorises teams to make and own the choices the framework demands. A planning system is constrained by the decision system underneath it. This is why ‘fixing planning’ sounds seductively simple, but usually results in more process to little effect.

Octoshark: Product management and other mythical beasts

PandA

Product teams are expected to deliver on time and innovate, to stay aligned and be autonomous, to be accountable for outcomes while being rewarded for output…

Read more

10 months ago · 1 like · Andrew Keogh

Product Systems

How do we define and deliver value?

This is where leadership tends to think the problem lives. Product teams aren’t delivering the right things. The roadmap doesn’t connect to strategy. Teams are shipping but no needles are moving.

Product systems are about the practices, rituals, and habits that determine how a team discovers what to build, validates whether it’s worth building, and measures whether it worked. Outcomes over outputs is the aspiration; product systems are the machinery that either makes that aspiration real or ensures that outputs are rewarded.

A team can have the right instincts about product thinking and still fail if the planning system commits them to fixed deliverables before they’ve had time to discover what matters. Or if the decision system means every pivot requires re-approval from a steering committee that meets monthly.

Flow Systems

How does work move through the organisation?

Flow is about the mechanics of delivery: how work moves from idea to production, where it gets stuck, what creates friction. Value stream mapping, bottleneck analysis, dependency management, team topologies; all of these live here.

Octoshark: Product management and other mythical beasts

Value stream mapping: don't get stuck in the mud

When my children were younger, they loved a book called ‘Stuck in the Mud.’ A chick gets, well, stuck in the mud, and all the other farm animals try to rescue it, only to get stuck themselves. The key line…

Read more

8 months ago · Andrew Keogh

This is the layer that most agile transformations target. Teams adopt Scrum or Kanban, measure cycle time, hold retrospectives. And sometimes things get better. But when flow improvements hit a ceiling, it’s usually because the constraint is in a layer below. Teams are waiting for decisions. Dependencies exist because the planning system didn’t account for them. Handoffs proliferate because the organisation was designed for a world where specialists sat in functional silos and work was thrown over walls.

Improving flow without addressing the systems beneath it is like optimising a database query when the real bottleneck is network latency. You’ll see small gains. You won’t solve the problem.

Measurement Systems

How do we know if we’re improving?

Measurement sits at the top of the stack because it depends on everything below. What you measure is shaped by what your product system values. How you act on measurement is shaped by your decision system. Whether measurement leads to learning or to blame is shaped by the culture that runs through every layer.

DORA metrics, SPACE, DevEx, NPS, OKR achievement rates; there’s no shortage of things to measure. The question is whether the measurement feeds back into the system in a way that produces change. In healthy organisations, measurement creates a feedback loop: we thought X would happen, Y happened instead, here’s what we’re going to do differently. In unhealthy ones, measurement is a reporting exercise. Numbers go up to leadership. Nothing comes back down.

Octoshark: Product management and other mythical beasts

From Developer Productivity to Developer Experience

A short history of engineering metrics…

Read more

a year ago · Andrew Keogh

A measurement system that exists in isolation, disconnected from the planning system, the product system, and the flow of work, is performance theatre. It creates the appearance of rigour without producing any learning.

The stack in action

An engineering director is in a performance review. Her teams are delivering regularly. Cycle times are reasonable. But the business isn’t growing, and her VP is frustrated, and tells her so. Her instinct is to look at what teams are building (the product system) or how fast they’re building it (the flow system).

She starts there. She introduces outcome-based planning. Teams target outcomes based on customer behaviour. They measure results. As a proposal, it looks great.

Six months later, nothing has changed. Teams still can’t act on what they learn because the quarterly planning cycle has already committed them to the next set of deliverables. The planning system overrides the product system. And the planning system is rigid because the decision system above it requires executive sign-off on any scope change, which takes three weeks and a business case.

The symptom was in the product layer. The cause was in the decision layer. The stack makes that visible.

Or take a different organisation. This one has invested heavily in flow: mature Kanban practices, solid CI/CD, team topologies designed to minimise dependencies. Delivery is smooth. But the teams are delivering the wrong things. Measurement shows activity but not impact. Nobody is asking whether the work matters, only whether it shipped.

The flow system is working perfectly. The measurement system is tracking the wrong signals because the product system never defined what success looks like beyond delivery. And the product system is output-focused because the planning system rewards teams for clearing their backlog, not for achieving outcomes.

Every layer affects every other layer. You can’t fix one in isolation.

Reading your own stack

The value of the stack metaphor isn’t in the framework itself. It’s in what it lets you see. And seeing it is harder than it sounds.

Most organisations have a reasonable understanding of their individual systems in isolation. They know their planning process. They know their delivery cadence. They have metrics dashboards. But because they’re living inside the ecosystem, they can’t see how the layers interact, where one system’s design creates dysfunction in another, and where an intervention at the wrong layer will be absorbed by the system without producing change.

There are good reasons for that blindness. The person who owns the decision system is usually senior enough that questioning it feels like questioning them. The planning system was designed by people who have since moved on; it persists because nobody remembers why it works this way, only that it does. Flow systems are often the product of years of accumulated workarounds, each one a rational response to a constraint that may no longer exist. And measurement systems are political: what you choose to measure signals what you value, and changing that signal threatens whoever built their credibility on the old numbers.

Self-diagnosis requires looking at layers you benefit from not examining. That’s why it rarely happens from inside the system. It’s also why, when it does happen, the instinct is to start with the layer that’s easiest to change rather than the one that matters most.

Sometimes that instinct is the right one. Fixing accidental complexity first; a better standup cadence, a cleaner backlog, a dashboard that actually tracks outcomes; can build credibility and momentum, even when it’s not addressing the essential problem. The danger is in stopping there and mistaking the improvement for the solution.

The organisational stack gives you a diagnostic lens for going further. When something isn’t working, trace it through the layers. If teams can’t pivot when they learn something new, is that a product system problem or a planning system problem? If planning is rigid, is that because the decision system requires certainty? If measurement isn’t driving learning, is that because the metrics are wrong or because nobody acts on what the metrics reveal?

The answers will point you to the layer where the real work needs to happen. It’s rarely where you first thought.

Watch the tapes

Why don’t organisations work the way we want them to? Because they’re essentially complex ecosystems. Making the layers coherent with each other is hard. It’s not easy to structure the informal organisation so that decisions flow at a pace that planning can use, where planning leaves room for product thinking, product thinking shapes what gets measured, and measurement feeds back into decisions.

That coherence is rare. It’s rare because nobody looks at the whole stack. They look at the layer that’s causing pain today, attack the accidental complexity, and wonder why the essential problem remains.

Brooks was right. There is no silver bullet. But there is a diagnostic, and it starts with seeing the stack that was always there.

These biases don’t stay in the clothing aisle. They follow us into schools, into hiring panels, into the data we collect and the systems we build. AI is trained on human data, and human data is soaked in the assumptions of the societies that produced it. This isn’t a new observation. What is newer, and less examined, is what happens when that biased system becomes a participant, or even a driver, in how teams think.

The invisible colleague

Most product teams are using at least one AI tool. It may be generating code, summarising research, drafting copy, suggesting approaches, or a combination of all of these. In many teams, it’s become a de-facto team member; one that contributes more lines of code than some of the humans, and whose suggestions carry weight precisely because they arrive fast and fully formed. As agents take on more complex tasks, that influence is only going to grow.

Every person on a team brings a perspective shaped by where they grew up, what they studied, who they’ve worked with, what they’ve failed at. AI brings none of that. Its perspective is an aggregate; the statistical centre of gravity of everything it was trained on. And the internet is not a balanced dataset. It over-represents certain languages, cultures, and viewpoints, and under-represents others. When a PM asks AI to draft user stories, it draws on those patterns. When an engineer asks it to review an approach, it suggests what is statistically likely.

Alex ‘Sandy’ Pentland, writing in Harvard Business Review, argued that individual reasoning and talent contribute far less to team success than one might expect; that the best way to build a great team is to learn how they communicate and to shape the team so that it follows successful communication patterns. So, what happens when the loudest voice in the room has no pattern of its own, only an echo of someone else’s? The internet is not a representative sample of the world. It over-indexes on English-speaking, technically literate perspectives; the cultures that built these tools are baked into them. That’s the echo your team is working with.

Whose voice does the product hear?

When a PM drafts a product brief with AI, they don’t start from scratch any more. They start from the AI’s version of scratch. The tool has opinions about what a good brief looks like, and they’re easy to accept because they’re close enough to right. But the struggle with the blank page is lost.

Over time, the risk is that the PM’s instincts start to bend toward the tool’s defaults. Not dramatically. Not in ways that announce themselves. But the range of ideas she considers narrows, because the first draft is no longer hers.

We talk about AI as an amplifier, but what if the human’s bias and opinions aren’t being amplified? What if the bias and opinion of the AI gradually reshapes the human perspective?

Now multiply that across the team. If everyone is leaning on the same tool for ideation, research, and decision support, the rough edges get smoothed out. The unusual perspectives, the culturally specific insights that make products resonate with people in real contexts, are quietly filed down. Diversity of thought is hard to build and easy to lose.

Organisations adopt AI to be more productive, more innovative, more competitive. But if the tool is compressing the range of perspectives that inform the work, then the organisation is becoming more homogeneous in its responses to an increasingly diverse and atomised market.

It’s what you do with it that counts

Addressing this requires some consideration of how to integrate AI. There’s no question that it’s changing work, and will continue to do so. Successful teams won’t treat AI as an oracle whose first answer is good enough. They will establish ground rules and voice profiles, encoding their taste with explicit instructions about what to challenge and what to preserve. The best teams will invest AI with what good looks like for their team, their product, their users. The poor ones will accept the statistical average.

Consider a product team at a mid-sized SaaS company. Two PMs, both using AI to draft briefs and synthesise research. The first accepts the defaults. Her briefs are clean, well-structured, and indistinguishable from every other AI-assisted brief in the industry. The second has spent time teaching the tool what her team values: how they frame problems, what questions they ask before committing to a solution, where they’ve been burned before by assumptions that went untested. She’s written ground rules that tell the AI to challenge her first instinct rather than validate it, to flag when a brief lacks a clear hypothesis, to push back when a proposed solution doesn’t account for her team’s specific users. Her briefs are messier. They’re also better, because they carry the team’s accumulated judgment rather than the internet’s statistical average.

We know that the best teams are designed for diversity. How do we bake that diversity into our tools, as well as our humans? How do we shape AI so that it doesn’t shape us? The teams that thrive will be the ones that treated AI the way they treat any new hire: with clear expectations, honest feedback. Continuing to encode diversity of thought into the fabric of our teams is not a nice-to-have. It’s the difference between success and failure.

If you’ve interviewed for a product leadership role in the last decade, you’ve more than likely heard this question. If you’ve been hired into one, you’ve probably tried to answer it for real. The question comes from Michael D. Watkins’s The First 90 Days, which remains the standard text on leadership transitions.

One of its most useful ideas is the STARS model, which asks the incoming leader to diagnose the situation they’re inheriting:

• Startup: assembling a team and building a product from scratch, with no existing customers or revenue to anchor decisions.

• Turnaround: the product or business is in trouble and needs to be rescued before the runway disappears.

• Accelerated growth: things are working, but the organisation needs to scale rapidly without breaking what got it here.

• Realignment: the organisation has drifted from its strategy, or the strategy has drifted from the market, and the two need to be reconnected.

• Sustaining success: the business is healthy, and the challenge is to maintain momentum while finding the next source of growth.

The model’s value extends well beyond the interview process. Watkins makes a persuasive case that the first 90 days in a role determine whether a leader will succeed or fail. A strong transition buys forgiveness for mis-steps down the line. A botched one poisons everything that follows.

Product leadership transitions carry a specific kind of complexity that Watkins doesn’t address, largely because he’s writing for general management. In product, you’re rarely entering a clean startup situation. You may be walking into a realignment or a sustaining success situation that’s slowing down and is now seeking accelerated growth in an adjacent market. In a portfolio organisation, you may be dealing with multiple situations at once.

What would a product version of the first 90 days framework look like?

Three slices of 30

The 90 days break naturally into three phases of roughly 30 days each: analysis, experimentation, and execution. Each phase has a different purpose and a different energy. In analysis, you’re listening. In experimentation, you’re negotiating. In execution, you’re asking the organisation to change.

The temptation, particularly for product leaders, is to skip analysis and jump straight to execution. We’re hired to make things happen. The pressure to demonstrate impact is immediate. But a product leader who starts executing without understanding is optimising for speed without context, like jumping into a Formula 1 car without checking whether you’re at the race track or going to the grocery store.

Phase 1: Analysis

The first 30 days are about understanding and synthesis. You’re building a diagnosis of the company, its position in the market, and the system that produces (or fails to produce) value for its customers.

Watkins identifies four pillars for a leadership transition: business orientation, stakeholder connection, cultural adaptation, and expectations alignment. These work well, but I would split the business orientation into business orientation and product orientation.

Business orientation

This is where you understand the business and its competitive position, by asking questions and gathering stakeholder views on issues, such as:

• What kind of STARS situation are you in?

• What market does the company serve, and where is that market heading?

• Is the business profitable, and if so, what’s the shape of that profitability; e.g. is it concentrated in a single product line or diversified?

• Does the company have a DHM (a way of delighting customers in hard to copy, margin-enhancing ways)?

• What is the financial plan, and how does the product strategy connect to it?

• What’s the business’s appetite for risk and how does that affect its current position?

Product orientation

Alongside the business questions, you’ll want to understand how the product organisation itself operates:

• What are the product team(s) currently working on?

• How much of it is connected to a measurable outcome?

• How much is inherited commitments and maintenance?

• How do we embed hypotheses and measurement into the way the business operates?

As you ask these questions, you’ll start to see the gap between the company’s stated strategy and its revealed strategy; the one you can infer from where it actually spends its time and money. Understanding how to address that gap is where you can deliver the most value.

Stakeholder connection

You can use your need to answer your business and product questions to build relationships with the people who matter, inside and outside the building. You’ll need to find out:

• Who are the internal partners to product; who are the key voices in sales, marketing, engineering, and customer success?

• Who are the strategic customers?

You’ll want their help in understanding their perspective on the organisation and its products, as well as finding out the pain points the organisation has already solved, and which ones remain stubbornly unsolved.

This isn’t networking for the sake of it. You are aiming to understand the system of incentives, relationships, and information flows that determine how product decisions get made. Who really decides what gets built, and how? Where does customer feedback enter the system, and where does it get lost?

Consider building a user journey map that captures all the touchpoints between the organisation and its customers. Not as a deliverable for a presentation, but as a diagnostic tool. As you visualise the information you are gathering, it will help you to understand where the most promising experiments can be run in the next phase.

Cultural adaptation

It’s important to understand the way the system operates today, and to gather some insights into what works well and doesn’t. It may be that there are certain cultural shibboleths, which you don’t want to attack too early in your tenure as it will undermine everything else you are trying to achieve. Good questions to ask include:

• How are decisions made?

• How are meetings run?

• How does conflict get surfaced, managed, and resolved?

• What’s the organisation’s actual (not aspirational) relationship with experimentation?

• Is there a culture of learning from delivered work, or does the team ship and move on without looking back?

These questions matter because the most elegant product strategy in the world will fail if it requires a decision-making culture that doesn’t exist yet. You need to know what the system will accept before you try to change it.

Expectations alignment

Among the various stakeholders and the teams, is there a consistent view of where the organisation is heading? Gather information from as wide a range of people as possible on:

• What does success look like in 18 months? Two years?

• Does the organisation have a view of its planning horizons, from the immediate to the speculative?

• Is the current product and engineering organisation structured in a way that can deliver against those horizons, or is there a mismatch between ambition and capability?

These conversations will uncover (regardless of what you were told during recruitment) whether you were hired to execute a plan or to create one. These are very different mandates, and your transition strategy will need to reflect the one you have.

From analysis to strategy

Pulling these answers together in the first 30 days gives you the raw material for a strategy. Richard Rumelt, in Good Strategy Bad Strategy, describes the kernel of good strategy as having three parts: a diagnosis of the situation, guiding policies for dealing with the constraints of that diagnosis, and coherent actions that implement those policies.

The diagnosis has to be honest. If the organisation’s stated strategy is growth but its revealed strategy is maintenance, that needs to be in the diagnosis. If the team structure works against the product strategy, that needs to be laid out. The whole point of a diagnosis is to name the situation as it is, not as anyone wishes it were.

Phase 2: Experimentation

The next 30 days are about testing the hypotheses that emerged from your analysis. Not proving them right, trying to falsify them. The distinction matters. If you approach this phase looking for confirmation, you’ll find it, and you’ll miss the things that would have told you to change course.

Validating the guiding policies

Each of your guiding policies contains assumptions about how the organisation works and how customers respond. Experimentation enables you to challenge those assumptions. For each guiding policy, ask:

• What is the cheapest way to test whether this holds up?

• What would tell us this policy is wrong?

• Where will we see friction first if we try to implement it?

• Do we have the data and instrumentation to measure the result?

Say one of your guiding policies is “transition to a platform-first mentality.” Maybe the cheapest test is running a single cross-team initiative that requires API-first thinking, and observing where friction appears. If a policy is “data beats opinion,” does the organisation have the data capability to support hypothesis-driven decision making? If so, can you test its appetite for it with one team and see whether the culture absorbs or rejects it? If not, you can start thinking about how to build it in the execution phase.

Creating visible momentum

Experiments don’t only produce data. They establish or destroy trust. In the first 60 days, the organisation is forming its opinion of you. Small wins matter, not because they prove you’re a genius, but because they demonstrate that change is possible and that you’re paying attention to things that affect people’s daily lives.

A “Product Experience” initiative is one thing that can help. Think of it as the product equivalent of a Developer Experience programme. Find the frictions that prevent teams from doing their best work, and fix some of them, or, even better, empower the people doing the work to fix some of them. This could be as straightforward as protecting meeting-free time for deep work, or as involved as mapping the decision-making process and removing unnecessary approval gates. The point is to show that you’re serious.

If there are no quick wins available, start by surfacing the invisible frictions:

• Map the actual decision-making process (not the one on the org chart).

• Document the collaboration pain points that everyone knows about but nobody has written down.

• Work out who informally shapes how things get done, because they will have more influence on your success than many of your peers on the leadership team.

• Choose Product Experience champions; people respected by their peers, not only those with senior titles.

Building the roadmap

Using the analysis and early experiment results, start drawing the product roadmap. This isn’t a Gantt chart. It’s a statement of intent, informed by evidence, that connects the guiding policies to specific initiatives with measurable outcomes. Frameworks such as PandA can be helpful in guiding the creation of this roadmap and ensuring that the right people contribute to it, and they can see how it is different to a delivery plan.

The roadmap needs to serve two audiences: internal stakeholders who need confidence that the product organisation has a direction, and external partners or customers who need to understand what’s coming and why. These are different documents with different levels of detail, but they need to tell the same story. Consider what each audience needs to see:

• Internal stakeholders need the strategic rationale, the connection to guiding policies, and the hypotheses being tested.

• External partners and customers need to understand what’s coming, roughly when, and why it matters to them.

• Both need to see how their input shaped the direction.

Metrics that matter

Everything in the experimentation phase needs at least one clear metric attached to it. Every hypothesis needs to be testable, and the data that will prove or disprove it needs to be accessible and reliable. This sounds obvious, but in practice it’s where many transitions stall. Many organisations agree in principle that they want to be data-driven, but often the instrumentation doesn’t exist, or the data is unreliable, or nobody has agreed on what “success” actually means for a given initiative.

Establish the baselines now. Before you start changing things, measure what matters for your specific situation:

• How long does it take to onboard a new partner or customer?

• What are current conversion rates at each stage of the user journey?

• How does the team rate its own collaboration and effectiveness?

• What does partner or customer satisfaction look like today?

Without baselines, you can’t measure improvement, and without measurable improvement, your transition is a story that can be told by anyone in the organisation. The data will ensure it’s your story that prevails.

Phase 3: Execution

The next 30 days are about delivering value while building the habits that will outlast your transition period. This is where the 90 day plan stops being a plan and starts becoming the way the organisation works.

From coherent actions to business as usual

By now, your guiding policies have been tested. Some will have held up; others will need revising. The coherent actions that survived experimentation become the foundation of your ongoing product strategy. The ones that didn’t survive taught you something, and what they taught you informs the next set of actions.

This is the rhythm you’re trying to establish: act, measure, learn, adjust. It’s not a 90 day exercise. It’s a permanent operating model. To embed it, consider:

• Are teams reviewing the outcomes of delivered work, or shipping and moving on?

• Is there a regular cadence for updating coherent actions based on what’s been learned?

• Can every team member draw a line from their work to a hypothesis being tested?

• Are experiments being treated as experiments (with success criteria defined in advance), or are they pet projects with a different label?

The transition is successful when this rhythm continues without you having to personally drive every cycle of it.

The cultural shift

Execution in the third 30 days is as much about culture as it is about shipping. You’re now setting out on a cultural transformation dressed up as a product transformation, and it will meet resistance.

Farm for dissent. Actively seek out the people who disagree with the direction and discover why. Some of their concerns will be legitimate; the diagnosis was incomplete, or an assumption was wrong. Others will reflect the friction that any change creates. Both are useful data. The concerns that reflect genuine gaps in the diagnosis need to be addressed. The concerns that reflect discomfort with change need to be acknowledged and managed, not dismissed.

Transparency matters here. You’ll want to build habits that make the organisation’s learning visible and accountable, for example:

• Share the metrics, including the ones that show where experiments failed.

• Run honest retrospectives that examine what was learned, not who was at fault.

• Publish decision logs that explain the context, the problem, the decision, and the rationale. Treat these as requests for comment while pressing ahead.

• Update the roadmap to reflect what you’ve learned; the organisation needs to see that the plan is a living thing, not a monument.

What success looks like

At the end of 90 days, the goal is not a finished product strategy. It’s a validated direction, a set of practices that connect strategy to execution, and an organisation that knows how to learn from what it delivers. You’ll know you’re in a good place if:

• You have a roadmap informed by evidence, not assumptions.

• Cross-functional alignment comes from shared understanding, not imposed agreement.

• Teams can draw a line from their daily work to the outcomes the business is trying to achieve.

• The people around you describe the change as something that happened naturally, as though the organisation simply started working better.

That last one is the sign it worked. The transition succeeded not because you arrived with a brilliant plan, but because you built the conditions for the organisation to figure out what the right plan was.

The product-specific challenge

Watkins wrote The First 90 Days for leaders in general. The framework holds up, but product leadership adds layers of complexity that the book doesn’t address. Product leaders navigate the tension between sustaining what works and finding what’s next, building strategy while simultaneously delivering against existing commitments, earning the trust of engineering, sales, marketing, and the executive team, all of whom have different definitions of success.

The 90 day framework, adapted for product, is really about establishing an outcomes-oriented culture. Not outcomes as a buzzword in a planning document, but outcomes as the thing the organisation actually optimises for. The diagnosis tells you where you are. The guiding policies tell you what matters. The coherent actions tell you what to do about it. And the measurement tells you whether any of it worked.

“So, what’s your 90 day plan?”

Build the conditions to learn. Then learn. Then act on what you’ve learned. Ninety days isn’t long enough to transform an organisation. It’s long enough to set the direction and prove that the direction is worth following.

There’s possibly no limit to what we can get “the AI” to do. The promise of AI is extraordinary. We are in the foothills of a revolution that will drive changes in how everything works. The organisations that harness AI well will accelerate away from those who aren’t able to leverage it.

But there is a gap between the promise and the reality, and it is not a technology gap. It is a crack in the foundations that prevents us building an AI-driven future.

Unintended consequences

Over the past two decades, organisations moved fast and broke things. They prioritised delivery over documentation. Knowledge lived in people’s heads rather than being systematically available, particularly when things were fixed or a new feature was added to an existing application. Tribal knowledge replaced written understandability.

This wasn’t an intentional hoarding of information. The choice to prioritise the next-most-important-thing over documentation was always rational. Each of these decisions made sense at the time. None of them were malicious. There was pressure to get the next customer, build the next marketable moment. The people who understood the system were still in the building. There was no stress about documentation. Why write it down when you could walk over and ask? Why worry about documenting something you might pivot away from?

Nobody anticipated that one day, in order to keep up, you’d need to be able to feed documentation back to the machines.

LLMs require well-documented systems so they can generate reasonable insights. AI needs something to reason with. The cumulative effect of years of underinvestment in documentation, data quality, and engineering practice has created an environment where AI often has remarkably little to work with. This is particularly impactful in organisations that have been around for over a decade that don’t operate in highly-regulated industries. The organisations most desperate for AI to transform them are often the least able to make the leap. There’s nothing for the AI to leverage. Or worse, the documentation that does exist is outdated and contradictory. Garbage in, garbage out.

The amplifier

AI does not fix problems. It amplifies whatever it finds.

Give an LLM clean, well-structured data and coherent documentation and it will do remarkable things. It will surface patterns humans would miss. It will generate code that respects the architecture. It will accelerate onboarding, speed up incident response, make sense of complex systems. It will do what the pitch decks promise.

Give it a codebase nobody fully understands, documentation that was last updated three years ago, and knowledge that lives in four people’s heads, and it will confidently amplify the confusion. It will generate plausible nonsense. It will produce code that looks right but ignores dependencies that were never written down. It will automate the wrong things faster than you ever could manually.

If there’s not enough information for a human to understand, there’s not enough information for the machine to explain.

An amplifier is only as good as the signal it receives.

The gap

There’s lots of data being published about how AI is failing to make the leap, and that most AI initiatives fail. From a certain vantage point, this looks like a discernible pattern.

An organisation decides it needs an AI strategy. An executive steps up. A team is formed. Tools are procured. A pilot project is selected. And then, the pilot stalls. Not because the AI doesn’t work, but because the team discovers that the data is incomplete, required documentation is missing, the system boundaries are unclear, and nobody can explain how the thing they want to improve actually functions.

The AI holds up a mirror, and the organisation doesn’t like what it sees.

This is the moment where many organisations either retreat (”the technology isn’t ready yet”) or push through with brute force, throwing people at the problem of cleaning up decades of technical and knowledge debt in a matter of weeks. Neither approach works.

In order to succeed, we need to acknowledge that the foundations need work. The model that disregards documentation and written understanding has run its course. We’re moving into a new world of well-documented systems, and that this work has value far beyond generating better AI outcomes. In a particularly nice irony, it’s possible to use AI to generate this documentation.

Clean documentation helps humans too. Well-structured data supports better decisions with or without a model. Clear system boundaries make teams more effective regardless of whether an LLM is in the loop.

The opportunity

For years, the benefits of investing in documentation, data quality, and engineering practice have been undervalued. It’s always been the right thing to do. The value of risk reduction has always been well-understood, but it has struggled to compete with the next feature on the roadmap.

AI changes the calculus. The investment in good practice now has an urgent, concrete business case. The organisations that have clean data will be able to deploy AI effectively. This is why we’ve seen regulated industries report great efficiencies with AI. The organisations that have well-documented systems will be able to onboard AI tools that actually understand what they’re working with. The organisations that invested in the boring fundamentals are about to accelerate in a way unavailable to those that didn’t.

This is not a small advantage. It compounds. An organisation with good foundations deploys AI effectively, which generates better data, which improves the AI, which accelerates the organisation further. An organisation with poor foundations struggles to deploy AI at scale, falls further behind, and finds the gap widening with every quarter.

Good practices have always been the right investment. AI has made them an urgent one. The organisations that treated documentation as a luxury and tribal knowledge as acceptable are about to discover the cost of those decisions. Not because they were wrong at the time, but because the world changed around them.

If you want the AI to do it, you need to give it something to work with.

I watched a talk given by Andrej Karpathy at AI Startup School in June 2025. The talk is called “Software Is Changing (Again).”

Karpathy divides the history of software into three eras, which he calls Software 1.0, Software 2.0, and Software 3.0.

Software 1.0 is what most of us mean when we say software. A human being writes explicit instructions. The computer follows them. The instructions live in files. The files can be read, reasoned about, argued over, version-controlled. If something goes wrong, there is a line of code or data structure that caused it. You can trace failure through your logs. Success and failure operate in predictable, deterministic ways.

Software 2.0 arrived when using weights to program neural networks began replacing those explicit instructions. At Tesla, Karpathy watched neural networks eat the C++ codebase. Rule by rule. Function by function. The engineers who had written the rules did not immediately disappear. They just gradually became less central to the thing. The rules became training data. The training data became weights. The weights became something that could see, driving Tesla’s Autopilot.

Software 3.0 is where we are now. Using prompts we can instruct LLMs, marking a fundamental change as we move into programming in our native language. Karpathy claims that the same replacement will now happen between Software 3.0 and the other paradigms.

I want to be careful here, because “the programming language is English” sounds like a line from a pitch deck at a conference where the coffee is bad and the badges are laminated. It sounds like something someone says before showing you a slide with a very large number on it.

But Karpathy means it structurally. When you write a prompt, you are writing software. It is executed. It produces an output. The difference is that the compiler is a large language model, the syntax rules are loose enough to permit ambiguity and personality and occasional confident wrongness, and the results are probabilistic rather than deterministic.

This is not a metaphor. It is a description.

The uncomfortable implication is that everyone who uses an LLM is writing software. It is uncomfortable because many of the people writing this software would not think of themselves as writing software. They think they are having a conversation.

Meanwhile, the people who think of themselves as programming struggle to shift from a deterministic to a non-deterministic mental framework.

Consider the person writing a prompt right now. They type a sentence. The model completes the thought. The person reads what the model wrote and, finding it almost but not quite right, adjusts their prompt to steer toward what they actually meant. The model reads the adjustment and responds accordingly. With enough of these interactions, the act of creating crosses from the human to the machine and back again.

The black box

There is a black box at the centre of this.

Every revolution in software had one. In Software 1.0, the black box was the computer itself: you fed it instructions and trusted that the transistors did what they were supposed to do, without needing to understand semiconductor physics. In Software 2.0, the black box became the model: you fed it data and trusted the gradient descent, without needing to understand precisely how it learned what it learned.

In Software 3.0, the black box is the large language model. You feed it language. It produces language. Between input and output, something happens that no one, including the people who built it, can fully explain.

Karpathy describes the LLM as a new kind of computer. Not a new application. Not a new framework. A new substrate. He compares it to the early operating systems of the 1960s: expensive, centralised, accessed remotely by many users sharing the same machine, none of whom have full utilisation. We are all, right now, thin clients connected to a mainframe in the cloud.

The personal computing revolution has not happened yet in Software 3.0. We are just about past punch cards.

The persistence of memory

Engineering leaders talk of using LLMs as being like having an army of interns. But interns learn. That is, in some ways, the entire reason for interns to be in the business.

The LLM has a particular property that Karpathy names anterograde amnesia. It cannot form new long-term memories. Its knowledge is fixed at the point of training. After that, it can learn within a conversation, accumulate context within a session, follow a thread for as long as the thread is in front of it. But when the session ends, it ends entirely. The next conversation begins from nothing. The same questions asked again. The same ground covered again. No memory of having been here before.

What comes next are agents. Not the fully autonomous kind, the ones that have leaders talking excitedly of 10x productivity with a tenth of the people. A human remains in the loop. The AI generates. The human verifies. The loop runs. The speed is the thing: not that the human is removed, but that the cycle between attempt and correction accelerates until the combination is faster than either alone.

Karpathy calls the period we are entering the decade of agents. Not the year. The decade. A decade ago, we were told that driverless cars would be on every road by now. They are not. The technology moves at its own pace, indifferent to the urgency of the announcement.

This is, among other things, a warning about impatience.

I have been thinking about what it means to live inside a revolution that you are also trying to describe.

Every previous revolution was easier to see in retrospect. The industrial revolution was not called that by the people working in the mills. They were just working in the mills. The information age was not called that by the people writing COBOL in 1967. They were just writing COBOL.

We are in the unusual position of naming the revolution while it is happening.

There is one thing Karpathy says that I keep returning to. He says that a good software engineer right now should be fluent in all three paradigms. Not just the new one. Not just prompting. They should be able to write the explicit code, train the model, and write the prompt, and know which of the three is appropriate for the problem in front of them. The skill is not mastery of Software 3.0. The skill is knowing which era you are operating in.

This article was written in Software 3.0. Not entirely. Not even mostly. But the black box was present, generating and being corrected, in the way that Karpathy describes: the loop running, the human verifying, the attempt and the correction cycling faster than either alone could manage.

I did not set out to write about my own process. But the thing about living inside a revolution is that it keeps insisting on being noticed.

Software is changing....

I like your manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Who could argue with any of that?

Let’s put it to the test-o!

The Agile Manifesto, reproduced in full above, was written during a meeting in Snowbird, Utah in 2001. The people behind it met to discuss new ways of creating software. They were looking for a better methodology than traditional ‘waterfall.’ They were inspired by the rise of extreme programming (XP) and other approaches that prioritised flexibility and faster delivery over full requirements gathering and change control.

The Manifesto laid the foundations of the Lean Startup movement, and gave rise to a new approach to software development that blended XP with some of the tenets of lean manufacturing pioneered by companies like Toyota. There are few, if any, software development houses today that wouldn't lay claim to being agile.

Victory is ours? Not quite.

What should being agile mean? The manifesto is pretty clear. Looking at it now, I wonder if the authors missed a trick by not emphasising learning over delivery of new features, but overall, the message is clear.

What does being agile mean? In many organisations, it means “we do SCRUM.” We have daily stand ups. We have story points.

A surprising number of people haven’t even read the manifesto. At one organisation, it took me weeks to persuade one senior colleague to read it. I think he thought that it was going to have the length and readability of the Communist Manifesto.

We take foundational knowledge for granted at our peril. Many leaders and organisations are simply adopting practices and imposing them on teams with no understanding of the real issues those teams are wrestling with. Then they get surprised when nothing improves.

There’s nothing in the manifesto about how, and that’s ok. There are a million ways for teams to improve their practices and learn how to improve their ability to deliver software, which in turn should be measured in customer value. That’s the key message from Snowbird in 2001.

It’s alright to say things can only get better

So what went wrong?

A consulting industry spun up, selling practices and certifications. Delivering more things became the promise, an irresistible siren song for organisations looking to “do more with less.” Performative “ceremonies” took the place of doing the right things or removing frictions.

If we were to hold a retrospective on the success of the manifesto now, we’d see that the promised revolution has been suppressed.

Process

Ask many Product Managers to describe how they’re agile, and they’ll talk about Jira. They’ll tell you about their sprint cadence, their story points, their velocity charts. The practices have become the point. The values that may have led to their adoption have evaporated. Organisations wanted to move from waterfall to agile, but the reliance on process prevents learning.

So we get standardisation. Scaled agile. Diagnostic checklists. Cross-functional dependency mapping. There are compelling reasons why these might solve organisational problems, but without a deep understanding of why these things are being adopted and what success looks like, it becomes performative.

Let’s take the daily stand-up as an example. This was described to me by an Engineering Manager as the most important 15 minutes of his team’s day. It’s a brief moment of coordination and establishment of blockers, owned by the team, for the team. In many organisations, it’s a status report. Everyone nods while the other team members give meaningless updates. This opportunity for learning and reflection becomes a form of micro-management.

In many cases, the ringmaster in this circus is called a Scrum Master, an interesting juxtaposition to the idea of servant leadership that is supposed to underpin agile software development. And don’t get me started on the idea that there’s a product “owner.”

Sprints are not sustainable over long distances. Sustainable practices compete with the language. The language wins.

The best teams I’ve worked with evolve their practices. They’ve inspected and adapted so that their way of working fits their context rather than a framework. They’re not precious about their processes. They do what works and discard what doesn’t.

They understand what matters. Individuals and interactions over processes and tools.

Documentation

“Working software over comprehensive documentation” is probably the tenet of the manifesto that has done the most unintentional damage to good practice. I have worked with more than one startup that interpreted the manifesto as permission to stop documenting anything at all. The pain that’s caused by a lack of focus on documentation is incalculable. As many organisations look to step into the brave new world of AI, this lack of documentation is causing real headaches - if there’s nothing for a human to understand, there’s nothing the machine can explain.

Documentation didn’t completely disappear of course. The emphasis shifted away from an explanation of context and how the system delivered value into how to deliver the next shiny feature. Technical documentation devolved into Jira tickets. Confluence documents may get written, but rarely read, and even less often updated in line with the system.

Helpful documentation that could be used as a map generally disappeared. Dependencies became transient, forgotten as soon as the software was delivered. Architecture decision records wasted away. Onboarding guides died of unfashionability. The promise that the code was self-documenting or that change control would be sufficient has proved false. You can see how work was tracked and planned. But that doesn’t tell you why a decision was made or how the system actually works. Working software with working levels of documentation may have been a better aim.

Collaboration

The manifesto envisioned teams working closely with customers, learning from them, and adapting based on what they discovered. What many organisations built instead was an elaborate internal negotiation system.

Story points became a currency for negotiation between product “owners” and delivery teams. The sprint itself, originally conceived as a short cycle for learning and adaptation, became a set of commitments.

The product owner role was conceived to bring the customer’s voice into the team. In practice, it often created a buffer rather than a bridge between the team and the customer. Then stakeholders inserted themselves between the product owner and the customer. Stakeholder wants became more pressing than customer needs and the product role changed from understanding problems to administering a backlog. Collaboration gave way to command and control.

Planning

Planning is probably the area that shows how far we’ve failed to come. Organisations adopted agile’s ceremonies but kept waterfall’s expectations. The roadmap is a gantt chart paved with promised features. The annual planning cycle still dictates what gets built. The teams work in sprints, but all that’s really happened is that the waterfall has become a set of rapids.

The manifesto says “responding to change over following a plan.” Most organisations have built elaborate systems for responding to change by updating the plan. The plan is never questioned. It’s just revised, re-baselined, and all too often, is represented as success, regardless of what is delivered, and how the market receives it.

Where’s me jumper?

How did we get here? The manifesto was written by practitioners. It was written for the people doing the work. The consulting industry repackaged it, created certifications, and sold “transformations” to organisations, marketing faster delivery while disregarding the cultural changes needed to lead to it.

Something the manifesto doesn’t explicitly state but probably should have: the organisation that learns fastest wins. Not the one with the best plan. Not the one with the most rigorous process. The one that treats every cycle as an opportunity to discover something it didn’t know before.

Agile, at its best, is a learning system. Short cycles exist so you can learn what works. Retrospectives exist so you can learn how to improve. Customer collaboration exists so you can learn what’s valuable. Every element of the manifesto points toward an organisation that treats uncertainty not as a problem to be eliminated but as the environment in which it operates.

Every piece of software is, to some degree, an act of invention. It involves creating something that hasn’t existed before, or at least placing it in a new context. This is thrilling and uncertain. Pretending otherwise, pretending that with enough process and enough rigour we can keep the chimerical predictability of waterfall while painting in the colours of agile, makes it so that failure is almost guaranteed.

It’s not agile’s fault. It’s not agile.

Twelve principles

We follow these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done--is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Who could argue with any of that?

A reminder

This is part of a semi-serious series of words that should be removed from the agile lexicon. Follow the links below for earlier entries.

The only f-word I won’t say: Agile swear words part 1

Commitment-phobia: Agile swear words part 2

My vendetta against the v-word: Agile swear words part 3

Let’s leave grooming at the altar: Agile swear words part 4

Agile swear words part 5: Just

One law that’s often referred to but arguably causes more dysfunction than the rest put together is Conway’s Law.

Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.

In other words, software architecture tends to reflect the way in which work is organised in terms of team boundaries and communication pathways.

Ignore Brooks’ Law, and your late project will be even later. Ignore Goodhart’s Law and you end up with meaningless metrics. Ignore Hofstadter’s Law, and you’ll continue to fall foul of the planning fallacy.

Ignore Conway’s Law, and you can grind your organisation to a halt.

Around 70% of digital transformations fail. Forbes attributes this to organisations treating transformation as a technology project rather than a challenge of human adoption. This is Conway's Law writ large. You can’t change the system architecture without changing the communication architecture.

Inverse manoeuvres

The reverse is also true. Changing the organisation chart or reporting lines without also investing in addressing underlying technological patterns will lead to failure. Moving people around to address the next problems your organisation faces makes complete sense when you’re a startup. When you’re a scale-up, or an enterprise, doing this without accounting for the technical landscape you’ve already built is a recipe for disaster.

This is how most re-orgs also fail. Changes get made to team structures, new projects get divvied out. Little attention is paid to the ownership and technical debt the teams are currently contending with. A monolithic architecture persists while software teams are ‘agile,’ following the ceremonies of Scrum but receiving no benefit from it due to the anchor of the pre-existing software it has to support. This architectural dissonance is a blind spot that prevents organisations from reaching their potential.

Orchestral manoeuvres

If we’re going to overcome this dissonance by design, we’re going to have to organise both sides of the organisation simultaneously. We can’t let digital transformations happen without bearing in mind the organisation structures that birthed them. Equally, we shouldn’t be blithely assuming that moving team members around, or changing reporting lines, is going to result in a re-architecture of our software unless we’re intentional about it. Conway’s Law imposes taxes on re-orgs.

In Team Topologies, Matthew Skelton and Manuel Pais draw out how this dual approach should work. The book treats team design and software architecture as inseparable. They propose a methodology for structuring teams to match the desired software architecture, and then doing the work to evolve both together. It’s a must-read for any leader faced with the question “How do we best organise ourselves?”

All too often, the response falls into a predictable pattern. Teams get re-organised. Maybe the language of Team Topologies is used. A platform function gets created to support product teams, those teams that do boring work that nobody understands are referred to as complicated subsystem teams.

However, the hard work of mapping this new structure against the existing codebase and ensuring clear lines of ownership is rarely completed. Clean reporting structures often disguise dysfunctional approaches to system architecture. At best, there’s a Frankenstein’s monster quality to the organisation, as the mis-matches between the code architecture and the organisation structure make themselves felt. At worst, zombie code wanders the halls, searching for an owner, degrading the organisation’s security posture. Whenever an upgrade is needed or someone needs to change that code, everyone is scared to tread into the danger zone, for fear of what they find, and for fear of becoming responsible for it.

A re-organisation can be a sensible response to challenges the organisation faces as it tries to scale, or get better at launching new products, or any of a thousand decisions it faces. Without mapping desired organisation changes to code ownership, though, the re-org is condemned to, if not failure, then certainly underachievement. Every time the organisation reinvents itself where it doesn’t grapple with this issue, it makes it worse. It only takes a few of these shallow re-orgs to create a challenge that has grown by an order of magnitude.

Wrestling manoeuvres

If the code still couples teams together, then your teams are still tightly coupled, whatever the re-org might say.

Every re-org that ignores the codebase adds a layer of scar tissue. Every unowned service is a future incident. Every domain boundary that exists on a slide but not in the code is a tax on the teams that have to work across it. The compound interest on this debt can turn a scaling challenge into an organisational crisis.

Conway’s Law will assert itself whether you plan for it or not. The only question is whether you’d rather design your way through it or be surprised by it again in your next re-org.

For example

A customer reports that their data export is wrong.

Why?

Because new validation was added to the system last week, reformatting some reports.

Why?

Because a new column was added to the underlying table.

Why?

Because a partner integration required it.

Why?

Because the company is extending its services and the impact of changing the table wasn’t understood.

Why?

Because the team that built the integration were working from outdated documentation and didn’t know about the reporting dependency.

The surface problem was a broken export. The root cause was that nobody knew the systems were connected, and there was no documentation for this reporting dependency. Fixing the symptom will sort out the immediate issue. Identifying and fixing the cause will ensure no repetition of the problem.

What?

Toyota developed the five whys technique as part of its Toyota Production System. It requires no software, no certification, and no consultants. You’d think it would be everywhere.

It isn’t.

Why?

There’s a legitimate criticism that complex problems have more than one root cause; that’s certainly true. There are versions of the technique that acknowledge multiple causes through branching off a fishbone diagram. Some companies have embraced digging deeper than five whys, using seven whys.

However, I don’t think that simplification has been the barrier to adoption. I don’t see any evidence that more complex tools have replaced five whys anywhere. I think that many organisations lack the curiosity to even follow a single thread to the end to fix an issue.

Why?

Why don’t organisations show that curiosity?

Because someone is waiting for an answer. The support ticket needs to be closed, the stakeholder needs a date, the customer needs a response. The pressure to act is immediate. The pressure to investigate underlying causes dissipates once that response is given.

So, short-term fixes get rewarded. Workarounds get created. Sometimes they even get documented. The issue is parked until the next time something similar happens.

Why?

Why don’t we fix the underlying problem?

Tracing a problem to a root cause can be complex. It can take time and consideration. Many organisations don’t allocate time to the possibility of failure. Others don’t give sufficient value to the idea of improvements through retrospective analysis.

These two blind spots prevent the organisation from being able to see how to fix its problems. Without retrospectives, learning takes a back seat. Without scenario planning, the planning fallacy puts the team in conflict with reality, and reality always wins. In organisations that optimise for capacity, and not for flow, teams are always operating under pressure.

Why?

Why don’t organisations plan with slack so that we won’t necessarily have to pivot when the unexpected happens?

Often, it’s about trust. Leaders in low-trust organisations hear of planning to 80% capacity and they see waste. They think that teams will slack off if they’re given slack time.

So every gap is filled. The planning fallacy dictates that we assume perfect conditions, perfect information, and perfect execution. The leader who pretends certainty is rewarded. The leader who presents a plan with deliberate gaps is treated like the dog ate their homework.

Why?

Why does the organisation reward certainty over honesty?

Because certainty is easy to communicate. “We’ll deliver X by March” fits in a subject line and gives an executive something they can report upwards with confidence. “We believe X is achievable by March, assuming no significant unknowns emerge and the dependencies we’ve identified hold, but there’s meaningful uncertainty around the integration layer” doesn't fit easily in a C-suite update.

Over time, the communication becomes the culture. It’s like a fairground mirror version of Conway’s Law. If honest uncertainty never makes it into the room where decisions are made, the organisation is geared to reward certainty, to treat every forecast as a commitment.

As a result, unforeseen challenges are treated as failures of planning rather than features of complex work. The entire operating model assumes that with enough rigour, enough process, enough estimation, we can eliminate surprise. That if we just plan harder, reality will cooperate.

It won’t. Software development is complex work happening in a socio-technical system. Uncertainty isn’t a bug. It isn’t even a feature. It’s the system.

Using five whys to understand why organisations don't use five whys may feel meta. But the technique works. At least one of those roads leads to trust. This is where we leave the whys behind and move onto how. How do you build that trust in your organisation?

The team is drowning. The startup has grown to 25 people, up from 8 a quarter ago. Everyone reports to the founder/CEO, who’s pulled in a million directions. Nobody can get hold of her. Without her, nothing can get decided.

The best engineer at the company has been offered another role and is looking for career progression or a strong reason to stay. The CEO can’t see tomorrow clearly, let alone how to move forward without this engineer.

So she gives him what he asks for. She promotes him to manager, promises he’s on the CTO path as the company grows. But she doesn’t give him any guidance. She just puts him in charge and disappears back into the chaos. Her only instruction? The company can’t keep up with its customer commitments, so hire more people.

Three months later, everyone is miserable. There’s now 40 people at the company, and nobody knows what to do. The Product Manager hired by the newly-minted CTO is tearing her hair out because every customer meeting seems to result in a new pivot. As a result, nothing is getting delivered. The company lost a great engineer three months ago and gained a struggling technical leader. Nobody has been able to step into his shoes because the CTO doesn’t have time to train the next cohort of engineers.

The company’s ability to scale is blocked by its reactive hiring strategy.

You can’t hire for urgency

I’ve written before about the “urgency-industrial complex,” where responsiveness becomes the de-facto product strategy. Startup survival can hinge on being able to pivot based on customer discovery.

As the Agile Manifesto has it, “Responding to change over following a plan.”

That reactive posture can work for product decisions. But it’s catastrophic for hiring, particularly in scaling organisations.

Hiring permanent staff has lead times. Two to three months to interview and onboard. Another month at least to get up to speed on the organisation’s culture, goals, and working practices. If you’re looking to grow leaders, you may need another three months before someone has the credibility to lead.

Most startups are so busy growing, that there’s no time to forecast hiring needs, and growing payroll too quickly can burn up the funding runway. The problem is that, if you wait, by the time you realise you need leaders, it’s too late to create them. If you’re hiring for what you need right now, it’s usually two months too late by the time you get someone in the door, longer before you get them up to speed. You can’t compress these timelines with wishful thinking. You can prevent being blocked by hiring ahead.

Hiring ahead

At a scale-up I worked with, we took a counter-intuitive but more intentional approach. As we achieved product-market fit, we began to see the sales pipeline fill. As a B2B SaaS company, we could use the lead time on deals to review the sales pipeline and forecast when customers would onboard, and how quickly. We used customer feedback and sales intelligence to predict what we’d need to deliver. This allowed us to create hiring plans, where we were able to look at the company we’d be in six months, and hire for that now.

We knew we were taking a gamble that the customers would land, but the alternative was that we wouldn’t be able to meet our customer needs, in which case we wouldn’t survive anyway.

This went beyond just hiring ICs. As we reached 20 employees, we started to actively interview for people who would want to become people leaders. We were explicit about the opportunity in interviews, creating a cohort of people who would be ready to step up as team leaders as the organisation grew. When we needed them to step up, they had the context, relationships and credibility to lead effectively.

Building capability

Hiring ahead was just the first step. We started to embed the structures and practices we wanted the growing organisation to have so that there was support in place for our new leaders. Many ICs fail as people leaders because they’re not given the tools to succeed. The assumption that someone who is good at writing software will be good at leading people who write software is misguided. But even someone who has the talent and motivation to lead is likely to fail if they’re not supported as they step into the role.

We thought about our reporting structures and how we would create team alignment in advance. We asked ourselves how decisions would be made. What should be escalated? How would teams interact as we grew horizontally?

By thinking these decisions through, we were able to develop a structure where people could succeed, and we planned for that success, creating clarity for new leaders when they came into the role.

Clarity is a kindness

Being clear about the organisation’s growth plans makes all the difference.

Let’s say that you have 15 people today, and you forecast that you’ll grow by 50% every six months for the next two years. In six months, you’re going to be a 23-people strong organisation. In a year, you’ll have 35 people.

If you’re aiming for a structure where teams will have 6 - 9 engineers and a Product Manager associated per team, you’re growing from one such team, to two, to three very quickly. You won’t be able to keep directing them in detail. You need to ensure that you give your incoming leaders the tools they need. You need to identify or hire your future leaders now, and you need to create some guardrails for them when they get into position.

Guardrails

What kind of guardrails make sense?

The idea of guardrails is not to create process and bureaucracy. It’s to give clarity and autonomy to leaders so that you can make space for them to lead as the organisation grows. Examples of guardrails include:

• Decision boundaries (what can teams decide independently?)

• Communication rhythms (when do we sync? what’s async?)

• Quality gates (what’s non-negotiable?)

• Ownership clarity (who owns what?)

These guidelines mean that rigid processes, command-and-control, or decision paralysis are avoided. Everyone has clarity on what is within their scope of authority and a quick way to get to a decision.

Install these guardrails before you need them. As you grow beyond one team, institute basic decision-making authority, and establish guidelines around meeting practices. Once you’re beyond two teams, you should have ownership guidelines in place and a RFC process for cross-team decisions. Once you’re at 50+ people, you may need to institute more formal practices, or divide efforts into different departments, e.g. establishing platform or developer experience teams.

Warning signs

Signs that you’re behind where you need to be include:

• You’re involved in every decision, however small

• People are complaining about chaos

• Teams are stepping on each other

• You’re desperately adding process reactively

Beyond 30: When to specialise

Going from 15 to 35 people is about adding your first managers, and creating your first formal organisation structure. The next stage of scale is going from 30 to 100+, becoming a real organisation. For this, you’ll need to think about layers and specialisation. At 30 people, most startups have generalist engineers on product teams. Everyone does a bit of everything - infrastructure, quality, features, support. This works because coordination overhead is still manageable.

At scale, though, the generalist approach creates bottlenecks. If each team is responsible for its own infrastructure, different practices emerge and quality can suffer. Security and compliance starts to become uncoordinated. A solution may be specialist teams, or a developer experience function with platform engineers who build shared infrastructure, establish quality standards, and own compliance. You’ll be reaching the point where you need to build out a proper support function. Up until now, this was probably managed informally or with everyone being on-call.

At the scale-up, we took the difficult decision to split ourselves in two. One half of the business became the support and platform function and the other continued to be the customer-facing product organisation. This took us a few weeks to implement, and it was a big change, impacting everyone who worked for us, but it was also our salvation, making it possible for us to scale and grow.

The six-month rule still applies: if you think you’ll need a platform team at 50 people, start hiring at 40.

The exception

One scenario where reactive hiring can work is bringing in contractors for well-defined, short-term needs.

If you suddenly need five more engineers to hit a critical deadline, contractors can be effective. They come with experience, require minimal onboarding, and can contribute immediately. There’s nothing wrong with buying capacity for a specific timeframe.

Spending wisely

Hiring ahead can feel expensive. You’re paying senior salaries for people who won’t manage for 6-12 months. But reactive hiring is more expensive: lost momentum due to unclear decision frameworks, poor managers put in a position where they can’t succeed, low morale, and quality problems from lack of ownership.

Guardrails may sound like process. You’re adding structure while still small. But lack of structure can lead to chaos. No clear decision-making authority leads to paralysis. Every decision requires coordination, teams block each other constantly, your best people are spending time in low-quality meetings instead of building high-quality software.

Won’t AI fix all this?

You might be tempted to think AI will solve this problem for you. We’ve already seen AI coding assistants increase IC productivity dramatically. The role of software engineer and Product Manager is being reshaped by AI, potentially meaning that you can (to use the dreaded phrase) do more with less. For example, AI might push back the specialisation inflection point - if generalists can maintain infrastructure with AI support, the need for platform teams could be significantly pushed back.

AI can also assist with compressing the recruitment process. But the fundamentals don’t change. High-performing teams operate with trust, which is built through shared experience.

The six-month rule might become a five-month rule, or even a quarterly rule. But it doesn’t disappear.

Hiring ahead remains essential. It just might look slightly different.

The reactive trap

Some organisations operate reactively by design - responding to urgent customer demands, pivoting quickly to market changes. Reactive strategy can work for product decisions where you can pivot in short timescales. More than once in my career, I’ve found myself writing a new product roadmap overnight.

But hiring has real lead times, and deep costs for getting it wrong. Hiring ahead isn’t a luxury - it’s essential.

Related reading

Appendix A - a practical playbook

This appendix is a playbook for hiring ahead at each inflection point. If you’re scaling, bookmark this and check it regularly for how you’re growing.

From 15 to 30 people

The situation:

• One team, everyone knows everyone and can help on most things

• Founder/leader directly manages most people

• Informal decision-making relies on the CEO

• Customer pipeline shows 50% growth every 6 months

Customer capacity forecast:

Currently, 15 people are serving 20 customers, sales pipeline indicates 8-10 new customers per month in the next 6 months. Can you serve 70 customers with 15 people? No. You’ll need 23-25 people at least.

At 25 people, you need 3-4 team leads and some division of ownership between the teams you’ll create.

Actions to take now:

Hiring (Month 1-2):

• Hire 2-3 senior ICs with management potential

• Be explicit in interviews: “IC role now, management opportunity in 6-12 months.” See Appendix B for more details.

Guardrails to install (Month 1 -3):

• Weekly 1-1s between ICs and people leaders

• Basic scheme of delegated authority

• Team size limit (no team larger than 8-9 people)

Leadership development (Month 3-6):

• Give future leaders mentoring responsibilities

• Have them lead small initiatives

• Include them in hiring and onboarding

• Signal explicitly that they are on track for leadership role.

By Month 6 at ~25 people:

• Your 2-3 hires are in team lead roles

• They have context, relationships, credibility

• The CEO is now managing managers, and decisions are made accordingly.

Cost:

3 senior hires × 6 months before they manage = investment in smooth scaling

Alternative cost:

Reactive hiring + chaos + failed promotions + lost momentum = much higher

From 30 to 100 people

Your situation:

• 3-4 teams, each with a team lead

• Teams are generalist (everyone does everything)

• Starting to see coordination overhead

• Specialisation becoming necessary

Customer capacity forecast:

You have 30 people serving 60 customers, growth continuing at 40% every three months.

You’ll hit 50 people serving 100+ customers in the next six months.

At 50 people, you need 6-8 team leads, an additional layer of leadership (managers of managers) and are likely to turn to platform or developer experience teams to lighten the burden on your product teams.

Actions to take NOW at 30 people:

Hiring (Month 1-3):

• Hire 1-2 people who’ve managed managers before

• Hire for specialist roles if you see bottlenecks emerging

• Continue hiring senior ICs with management potential for additional team leads

Guardrails to upgrade (Month 1-3):

• Clear ownership (every service/product has exactly one team that owns it)

• RFC process for cross-team decisions (1-page, 72-hour comment period)

• Formal team splits when teams hit 9 people

• Monthly retrospectives and lightweight, continuous planning ceremonies.

Organisational structure (Month 3-6):

• Create manager of managers role (your team leads now report to them)

• Consider first specialist team to address bottlenecks

• Define career ladders (IC track vs management track)

Leadership development (Month 3-6):

• Train your team leads on managing (don’t assume they know how)

• Create peer support groups (team leads meet regularly)

• Start identifying next cohort who might become managers in another 6-12 months

By Month 6-12 at ~50-60 people:

• Clear organisational structure

• Specialist teams handling platform/developer experience

• Decision-making flows smoothly without everything escalating to CEO

• CEO is focused on strategy, not operations

Warning sign you’re behind:

If your CEO is still making all decisions at 50 people, you’re 6 months too late.

Key principles across all stages

Always forecast 6 months ahead:

• Sales pipeline + close rate = customer onboarding forecast

• Customer load = team capacity needed

• Team size + lead time = hire now

Always hire for potential, not just current need:

• Can they deliver as IC immediately? (first 3-6 months)

• Do they show leadership signals? (months 6-12)

• Do they want to manage? (explicit career interest)

Always install guardrails before your teams get overwhelmed:

• Establish decision rights before teams are blocked

• Create communication ceremonies before meeting overload

• Clarify ownership before territorial conflicts

• Limit team size before co-ordination becomes unwieldy

Always acknowledge uncertainty:

• The customers might not land (but you plan anyway)

• The hire might choose IC path (and that’s fine)

• The structure might need adjustment (build in flexibility)

• Perfect planning is impossible (but some planning beats none)

When NOT to use this playbook

Don’t hire ahead if:

• You don’t have 6+ months runway (solve cash flow first)

• You haven’t achieved product-market fit (focus on survival)

• Your sales pipeline is completely unpredictable (too much uncertainty)

• You’re genuinely in exploration mode (team structure will change radically)

In these cases:

Use contractors for immediate capacity needs, keep team small and generalist, wait until you have clearer visibility before building permanent structure.

But remember, the longer you wait, the longer your scaling will take when you finally need it. The lead times don’t compress because you’re in a hurry.

Appendix B - How do you identify future leaders?

If you're on this growth trajectory, you need someone who can contribute as an IC immediately and can grow to be a manager as you scale. How do you identify potential?

Interviews are imperfect, but, much like democracy, they remain the best system we have when you consider the alternatives. Scale-ups are likely to be placing people in their first leadership role, so they won’t have direct experience. You’ll need to ask candidates for engineering positions about behaviours they have exhibited that indicate leadership traits, for example:

• Tell me about a time you influenced without authority

  • Why: Can they demonstrate the ability to persuade peers and stakeholders?

  • Look for: collaboration, persuasion, building consensus

• Tell me about a time you got things wrong?

  • Why: Managers must be able to admit mistakes and change course without blame

  • Look for: intellectual humility, learning orientation, willingness to take responsibility.

• How do you like to receive/give feedback?

  • Why: The ability to give and receive constructive feedback is fundamental to good leadership.

  • Look for: thoughtfulness about approach, ability to listen and repeat back what is being said.

• Tell me about a project that failed and what you learned

  • Why: Managers must handle failure productively

  • Look for: ownership, learning, systems thinking

You still need strong IC skills. Management potential is necessary but not sufficient. The ideal candidate:

• Can deliver as IC immediately (needed for first 6 months)

• Shows leadership signals (potential for months 6-12)

• Actually wants to manage (explicit career interest)

In the interview, when candidates demonstrate that they might be a good leadership candidate, it’s a good idea to be open with them and see how they react. Telling them that an opportunity to become a people leader may arise within 6-12 months filters for interest and sets expectations clearly.

Three days after the quarter starts, the DM comes from leadership.

“We’ve got a new ask. The team needs to size this.”

The PM argues back the quarter is full. The team are now fully loaded and focused on delivery of the just-agreed work.

“I just need to have a meeting with some of the engineers so that they can give me an estimate. It should only be 30 minutes. Are you really telling me we can’t have some engineering attention for half an hour?”

And this is how the forgetting starts.

The executive asking for something new has forgotten that this 30 minute meeting will likely need an hour’s preparation, as people try to figure out what the new ask might involve, and what the impact on the plan might be - this is the purpose of the meeting after all.

The usual outcome of this meeting is a request for more information as unknowns surface during the discussion. From the exec’s perspective, that’s perfectly reasonable - they need more input to make a decision.

But they’ve forgotten that the decision to interrupt the team has already been made. Now it’s just a question of impact. These unknowns need a day’s investigation. Another meeting is scheduled, spawning more work. And the original plan sits there, unchanged, as if none of this is happening.

The requester’s logic is sound: “I’m not asking you to build it. I’m just asking you to tell me if you could.”

But sizing isn’t free. Understanding the question well enough to answer it honestly is work. And that work isn’t in the plan.

The illusion of zero cost

The exec genuinely believes the ask costs nothing. They get their answer, they make their decision. In the meantime, the team’s planned work falls behind as the ask takes precedence. From their perspective half a week has vanished but their ‘plan’ hasn’t changed. Something has to give. Longer hours, cut corners, or a missed commitment. Any slack the team may have had is gone.

The plan assumed full capacity. Every week was accounted for. Every person was allocated. The organisation could tell itself it was maximising its return on investment.

But plans built to 100% capacity have no flex. No room for questions. No buffer for the unexpected. The moment anything arrives that wasn’t anticipated, and something always does, there’s nothing to move around to account for it. Something has to give.

The failure only surfaces to the exec at the end of the quarter when the team misses its goals. By then, they’ve long forgotten about their ask. The ask and the failure are no longer connected in anyone’s memory.

The spotless plan

The plan continues to sit there, unchanging. If there are progress reviews, it’s never acknowledged that the team is effectively working on something else. Without a mechanism to reflect the interruption and its impact, the capacity taken leaves no mark.

By the time the consequences arrive, the cause has been erased. So the pattern repeats. The team keeps failing to deliver. Their reputation suffers. The asks keep coming, because they appear to cost nothing. Burnout and attrition may appear, but the dots are never joined. Like Joel waking up with no memory of Clementine in Eternal Sunshine of the Spotless Mind, we meet the same failure again and again, wondering why it feels so familiar.

What would need to change

The issue isn’t that questions shouldn’t be asked. Executives should consider alternatives, and often need more information to make the best trade-off. But raising questions while treating the plan as an unchanging and unchangeable artefact ensures failure and frustration.

Interruptions aren’t free. There is always a price to pay.

Here are a few suggestions to rescue yourself from the eternal sunshine of the spotless plan:

Plan for impact, not capacity

Too many plans focus on maximising the utilisation of every engineer. If the plan accounts for every engineer for all of the time, then the plan is a fiction. There’s always invisible work. Add the inevitable asks and distractions, and it’s clear that a plan built to 100% capacity can’t succeed. Organisations that focus on utilisation aren’t giving their full attention to what matters most - changing customer behaviours in ways that impact the bottom line. If your organisation spends more time considering utilisation than impact, the lens needs to shift.

Make the cost visible

You may not be able to change the dynamic around capacity planning, but you can name the cost. When a new ask arrives, call out what it displaces. “We can size this or do that, but it means X slips by a week.” Force the trade-off into the open. Make sure the cost is explicit. This will at least make the exec consider it. Otherwise, the pretence that it is free will persist.

Track the asks

Keep a record of what came in after the plan was agreed. When the quarter closes and performance to plan is reviewed, you’ll have the evidence to connect cause and effect. The pattern becomes visible. The memory is no longer erased.

Not right now

Ask if the request really is urgent and can’t wait. An ask that can’t wait a week probably can’t wait at all. These should be treated as a genuine emergency, not a quiet tax on the plan. Most asks can wait. Make it acceptable to say so. And make it clear that the ones that genuinely can't will blow up the plan.

Memory may fade, but plans remember what we choose to write down. The only way to escape the loop is to make the forgetting visible.

I’ve lost count of the number of articles I’ve read in the past year speculating on Rachel Reeves’s future as Chancellor. Not because of government u-turns or her performance, but because the latest Gross Domestic Product (GDP) figures are due. The same ritual, quarter after quarter: the ONS releases a number, the headlines claim disaster or progress, even on changes as low as 0.1%, as if this single metric is the sole arbiter of economic progress.

But there’s been fierce debate over whether GDP is even a valid metric for measuring economic health. GDP measures the value of goods and services produced in an economy over a quarter. It ignores quality of life, what happens in the home, investments in education, or environmental stability. On the plus side, it’s simple and easy to understand. On the other, even its inventor acknowledged that it wasn’t a useful measure of wellbeing.

But its simplicity is its draw. By boiling all economic activity down to a single figure, economists, politicians and journalists draw inferences on wider economic health. Widening inequality can be celebrated as long as GDP goes up. We’re burning through our planetary resources at an unsustainable rate but that’s ok as long as this measure of growth ticks up.

Widening the lens

There have been many attempts to broaden the focus of economic health measures. One that has garnered widespread attention has been the doughnut, created by Kate Raworth in 2012. The doughnut shows the sweet spot between social foundation, where the needs of all people are met, and the ecological ceiling, which is the capacity of our planet to support us.

The red areas in the ‘hole’ in the doughnut show where countries fail to provide their citizens’ basic needs. In the graph above, we can see that countries, both rich and poor are failing to provide sufficient levels of peace and justice. The poorest 60% are falling behind on energy needs while the richest 40% are overshooting dramatically on causing climate change.

The doughnut looks across 12 measures of social foundation, and nine measures for the ecological ceiling. It’s an elegant overview, but its complexity means it’s a novelty for nerds. We’re unlikely to ever see a headline saying the Chancellor should be applauded because the social foundation gap has narrowed in connectivity.

What you see is all there is

It’s not that stories about such progress go unreported, it’s that they’re not given the same importance as that single number. It’s as if GDP is the pulse of the economy, and heart rate is the only measure that matters, regardless of the overall condition of the patient.

The same fixation plays out in the corporate world, with the quarterly ritual of earnings calls. These follow the GDP playbook: a number is released, analysts react to movements of a few tenths of a percent, and CEOs are declared visionaries or failures based on whether the line went up and to the right. The market doesn’t ask whether the company is building something sustainable. It asks whether revenue or earnings per share meet or beat expectations.

Following a brief reset during the pandemic, growth is back on the agenda with a vengeance. Generative AI has added rocket fuel to the boosterism, as organisations eye dramatic productivity gains and look for opportunities to cut headcount.

The AI gold rush offers a perfect case study. Companies are laying off workers citing AI as the cause while the technology requires massive investment in data centres that consume staggering amounts of energy. Failure to reach the social foundation in one metric, overshooting the ecological ceiling in another. All in the service of chasing growth.

So, what would a corporate doughnut look like? The inner ring would be the social foundation, below which employees and stakeholders suffer. The outer ring would be the organisational ceiling, beyond which it would damage itself and its environment.

Social foundation

The inner ring would include sound business practices that support employee wellbeing and reward institutional health. Categories could include:

• Living wage

• Sustainable workload

• Psychological safety

• Job security

• Voice and agency

• Health and wellbeing

• Learning and development

• Purpose

Other than the living wage, these could be measured through regular employee surveys.

Organisational ceiling

Beyond the outer ring, the key measures would be around customer trust and supplier relationships, or policies that lead to the organisation damaging itself or its environment. Categories could include:

• Environmental footprint

• Poor supplier relationships

• Customer trust erosion

• Market monopolisation

• Community harms

• Extractive pricing

• Employer reputation

• Underinvestment

These don’t tend to get much airtime in an earnings call, but they’re strong predictors of whether your company will still be thriving in five years.

Doughnuts all round?

While we can imagine what a doughnut for corporate responsibility might look like, it’s hard to beat the simplicity of a single metric. Below the corporate growth headline, a lot of product organisations have “One Metric that Matters”, a guiding light for making decisions. That’s not necessarily a bad thing if other signals are also being taken into account, but if growth is the only thing that matters, well, growth is the only thing that gets measured.

Engaging with the doughnut demands attention and a cognitive load to understand the interrelationships that affect the sweet spot. It’s a great picture, but it doesn’t have the immediacy of a single figure. It remains a fantastic economic idea for nerds to noodle on, while the world continues to obsess over GDP.

It’s a fool’s errand to ask executives to put limits on their companies’ growth so they can stay in the doughnut’s sweet spot. They are subject to market and shareholder demands to deliver better financial results quarter on quarter. The doughnut is intellectually superior. The market pays the bills. The market wins.

Growth wins. It doesn’t win because it's right, but because it fits in a strapline. Simplicity beats complexity at the altitude of a country or a company. The doughnut advocates may be right, but the reasons they are right are also the reasons they won’t win.

When people come to me with problems, I often hear myself saying “You know, I was thinking about this...” At one point, some of the engineers I was working with started making fun of me for it.

It’s not that I’m a know-it-all (I hope!). It’s more that I keep the fragments of conversations and the things-we-should do next rattling around in my head. I don’t look to build beautiful long-term solutions without others. I’m not trying to invent the future on my own. I am constantly playing with Lego in my head, trying to understand what we could make with the blocks I see lying around.

I like to test and prototype ideas, looking for feedback on half-baked theories quickly. The availability of generative AI as a thought partner and collaborator should be amazing for people like me, and in many ways it is. When you sit bolt upright at 5 a.m. because a potential idea or solution has popped into your head, how cool is it to be able to not only jot it down, but quickly iterate on it, and have some conversation about the idea with a willing partner?

There’s huge excitement among leadership about the changing face and pace of collaboration. Rather than having engineers and product people work together, AI can now be used to rapidly prototype. Agentic AI is coming to take over entire workflows. The future belongs to one-person startups who can change the world with nothing more than an idea and a $20 per month Claude subscription. Or so the pitch goes.

There’s no question that prototyping is unrecognisable from a year ago. AI enables us to get to a higher fidelity faster than ever before. The technology is improving all the time and the promise is that implementing software all the way to production will eventually become frictionless.

There’s only one problem with this narrative. AI doesn’t tell you when your idea is terrible.

Rapid iteration only works if you’re building on a strong foundation. AI can help you build faster, but it won’t tell you if you’re building the wrong thing. Your 5 a.m. ideas will always be warmly received, however poorly-formed they might be in reality.

You could be on a fast-track to mediocrity, clarifying your thinking, but not getting any push back or challenges to your premise. AI is wonderful at helping you develop your idea, but it’s terrible at disagreeing with it.

Some LLMs are more sycophantic than others, but generally, responses are primed to be positive rather than adversarial. You can miss out on the leaps that come from debates and disagreement from people with different perspectives.

Without that early friction, ideas that should be forged on the anvil of debate instead get built to high fidelity before being exposed to any real challenge. By then, you’ve invested time, effort, and ego. The sunk cost makes pivoting harder. You’re at risk of creating something beautiful that won’t survive contact with the world.

Rather than embracing AI as a co-creator, it seems many people have given up thinking and outsourced the creative act, losing their voices in the process. The phrase AI slop has passed into common parlance to describe the generic AI-generated articles that have started to appear everywhere, from social media to entertainment sites.

Good ideas become great products and implementation through the push-pull of debate, and the friction of trade-offs. You can share a 5 a.m. moment of inspiration with AI, but you can’t expect it to generate one itself. An AI is never going to laugh at you for playing with Lego, and sometimes you need that.

The efficiency gains we will make with AI are already astonishing and will accelerate. There’s going to be unimaginable change as work gets automated and orchestrated by machines in ways we never thought possible. But I think the spark of innovation remains innately human. Share your Lego with people with different perspectives.

It has a market capitalisation of over $1.6 trillion, over 30% profit margin on revenues of just under $189.5 billion, and three billion monthly active users.

Asking where it all went wrong for Facebook Meta, feels like being the bellboy delivering champagne in the famous story about George Best.

Oh, George, where did it all go wrong?
A hotel bellboy, delivering champagne to Best’s room, finding him with Miss World and the bed covered with casino winnings.

But the analogy works. Best, as a footballer, brought joy to millions of football fans, and walked away from the game at 27, at what should have been his prime. When Facebook launched, it promised to connect the world. It was the brainchild of Harvard students, an independent rival to MySpace, which had been bought out by Rupert Murdoch’s News Corporation. Its “move fast and break things” philosophy allowed it to out-grow and out-perform its rivals, leaving them in the dust as it became a behemoth.

It’s difficult to argue that Facebook delivered on its early promise to connect the world. Over Christmas, I read Careless People by Sarah Wynn-Williams, and Enshittification by . They both offer valuable perspectives on where Facebook’s choices led us here, to a more divided online world, rather than a more connected one.

The enshittification of Facebook

Doctorow’s thesis is that enshittification (his very technical term for how things get worse) happens in three stages:

1. The platform is good to its users. In Facebook’s case, it offered connection, enhanced privacy (really!) and a superior user experience compared with other social media platforms. By allowing users to connect and opening up the platform to game developers, it quickly built up a large population of users who came to play, waste time, and catch up with friends and relatives.

2. The platform is good to its business customers at the expense of users. Despite promising in 2004 never to “use cookies to collect private information from any user,” ten years later, Facebook was selling its user data to advertisers and publishers, enabling targeted advertising and publishing unasked-for content onto users’ newsfeeds. Users had no choice but to accept commercial surveillance as the price of continued connection to friends and loved ones on the platform.

3. Being bad for its business customers. Some time later, Facebook ads stopped being served reliably to target audiences, publishers were forced to deliver longer posts to get to users, eventually having to publish their entire articles, reaching fewer eyeballs. “Advertisers paid much more for ads that were less likely to be seen.”

This chimes with many of the criticisms that Wynn-Williams has about her years at Facebook. She described several times when growth came into tension with political concerns. Growth always won.

This wasn’t inevitable

When Facebook launched, it was only possible to join if you had an .edu email address from an American university. Eventually, this crossed the Atlantic to the UK and university students there could join. This exclusivity created a massive buzz. Then users were allowed to invite non-university friends, and I pestered my partner of the time to invite me. Eventually, a friend of hers took pity on me and invited me. It was amazing. It was such a cool experience. You only saw news from people who you were connected with, you could easily find like-minded Facebook friends, and it felt like a global community was springing up.

As it grew, Facebook continued to assure us all it took our privacy seriously. In 2014, the company changed course, and went all-in on user surveillance to supercharge advertising revenues. Now that it was the last remaining social media company in the market, user concerns about privacy stood in the way of growth. They never stood a chance. Facebook updated its terms and privacy policy, and switching costs meant people stayed on the platform.

If this is how VC-backed firms work - they use capital to grow, funding losses to acquire market share, it didn’t have to be this way for Facebook, which was wildly profitable before it became a surveillance capitalist. It earned $229 million on $777 million in revenues in 2009 and $606 million on $1.974 billion, with profit margins of 29 - 30% in both years. The growth trajectory was already there.

Surveillance capitalism wasn’t required for super-sized profits and growth. But it gave more and more back to investors, never mind the users and businesses who relied on the software. Wynn-Williams described the ‘grow at all costs’ mentality prevalent in Facebook pre and post its IPO in 2012.

Abandoning user privacy killed the promise of social media as a connecting force. A news feed once full of updates and messages from friends and relatives is now buried beneath countless ads. Separately, there’s been a rise in political polarisation, where there’s less engagement between different perspectives. Several studies have shown that people consume content aligned with the views they already have, and more extreme views are associated with higher levels of engagement. If this is the long-term trend, where people only have limited access to alternative perspectives, then we are a long way from where we started.

So, what now?

In Enshittification, Doctorow argues that we can get back to a better world by creating platforms that follow the end-to-end principle (you get to see the data you want to see, not what the platform profits most by showing you), and through interoperability, so you can leave a network you dislike, without necessarily cutting off your connections. I’d like to believe in that world, but I don’t think that our current titans of social media will deliver it for us. What would it take for three billion users to exit Facebook? A new challenger model has to come. What would it look like?

• The chances are it will have to be a niche service to begin with. Facebook started with college students, and some common group is likely to be the feedstock for a replacement movement.

• It would require a certain kind of investor - if it’s not to repeat the enshittification cycle of Facebook (and others), growth at all costs would not be the way. It would have to operate with guarantees of user protection baked in.

• You’d also need the kind of corporate structure that would enable you to prevent a buyout from a social media giant should you gain traction in the market.

• The biggest challenge I see is how such a business makes money. If you’re going to sell ads, you can’t beat Facebook. There’s nothing in it for a user or community to join you, given the network effects and reach of Meta’s applications. The illusion of social media being free creates substantial barriers to entry.

• But the core of the product is there. People yearn for connection. A product that brought the kind of joy and delight to people the way that Facebook originally did is possible. It just needs someone to build it.

But what if the needle doesn’t move on any of your customer metrics? Revenue stays static. Customer satisfaction trends down and retention falls. You’re building faster than ever, but you’re not delivering for your customer. You’re delivering more features faster than ever before, but you’re shedding customers anyway.

Every successful startup survives because it finds product-market fit before it runs out of cash. Most learn through experimentation and failure before they find their niche.

As organisations grow, the need to experiment is often forgotten. As the cost of scale manifests itself in more process and co-ordination requirements, time-to-market becomes one of the key concerns of leadership. This manifests in phrases like ‘we need to go faster’ or ‘behave more like a startup.’ But startups don’t behave in the way they describe. Startups understand the race they’re in before they floor the accelerator.

Instead of measuring time-to-market, it’s better to look at time-to-qualification (TTQ). We shouldn’t assume that every idea is going to be a success. We should be listening to and be respectful of user and customer feedback. Looking exclusively at TTM can mean the organisation focuses on internal goals (what matters to it) rather than user value (what matters to its customers). A once-thriving experimental organisation becomes a feature factory. Product bloat and enshittification follows.

WTF is TTQ?

Time-to-qualification is the time it takes to qualify an idea. You don’t need to build the complete solution. You only need to build something big enough to learn if there’s an appetite for the solution. If there is, that’s when you invest in a scalable, reliable solution for the broader market.

Examples of qualification strategies include:

• A/B testing: testing two versions of a solution and seeing which gathers more positive feedback.

• Fake front door: gathering signatures or emails that express interest in a solution you haven’t launched yet.

• Wizard of Oz: building a manual process that looks to the user like it is fully automated

Each of these require little up-front technical investment, and should be focused on a narrow question, based on your product strategy. For example:

• Will a customer pay (more) for this product capability?

• Does this open opportunities in a new market segment?

• Does this drive traffic to a value-creating part of my site?

These are the kinds of activities that take place in the Potential phase of the PandA framework. It’s important to recognise that not all ideas are winners. A focus on time-to-qualification makes sure that the losers fail fast.

Let’s explore a fictional example of how this works in practice.

A worked example

With the market seemingly demanding AI features everywhere, the team at P&A Utilities consider building an AI-powered energy forecasting dashboard that predicts customer usage patterns 90 days out. Their hypothesis is that customers will pay for this service and it will incentivise more detailed forecasting. Sales forecast a €2 million increase in subscriptions over the following 12 months.

The team didn’t have much machine learning experience, and were concerned that they could get derailed by the volume of work and learning they would have to do to support this new capability. Instead of diving straight into six months of work, they decided to qualify the opportunity, facing down pressure from Sales and senior stakeholders to get on with delivering as soon as possible.

The team ran a Wizard of Oz experiment. They manually created 90-day forecasts for five clients using existing data and a spreadsheet, packaging it as a ‘beta preview’ of an upcoming premium feature.

After four weeks, usage data showed clients looked at the forecasts once, then ignored them. Customer interviews revealed that clients found 90-day forecasts interesting but not actionable. What they actually needed were 14-day forecasts with specific recommendations on when to shift high-demand operations to off-peak hours, or when the weather was likely to drive market prices higher within-day, so they could shift to onsite generation.

The team killed their original plan and pivoted to building short-term actionable recommendations instead. Instead of wasting six months building the wrong thing, the team qualified the idea in a month, then built the right solution in another eight weeks. The company got to market faster with a valuable feature and saved money and time in engineering costs.

Learning at speed

Time-to-market devalues learning. It assumes that whatever the organisation has decided to build will deliver value. There’s no need for product research or for experimentation if all you care about is getting to market quickly.

This emphasis on rapid delivery can result in taking shortcuts on quality. In a world of date-driven development, important investments in scalability and testing are postponed, becoming technical debt. Servicing this debt erodes the team’s ability to deliver quickly. It’s ironic that a focus on rapid development can turn into the very thing that prevents quick delivery over time.

Time-to-qualification flips this on its head. You can still look to optimise processes and reduce waste. But instead of emphasising faster delivery, you’re optimising for solving the right problems for your customers and users. Not pursuing unpromising capabilities is rewarded, both through a lack of technical debt, and in a keen focus on user value.

So why don’t more companies adopt this approach? There’s an automatic reaction that anything other than a focus on TTM will slow them down.

Scream if you wanna go faster

I was once talking about this need for experimentation and learning with a VP of Engineering, and he said “I can’t go to the C-suite and say to them that we have to slow down to speed up. I’ll be laughed out of the room.’

This is a fundamental misreading of what emphasising TTQ does. You’re not slowing down to speed up. You’re optimising for learning. You are truly behaving like a startup, delivering only the capabilities your customers care about.

This is analogous to what good Product Managers do all the time. You don’t build what the customer asks for. You build the thing that will solve their problem.

Time to market should be a follow-on from time to qualification. If an experiment shows promising results, then being able to capitalise on that quickly is a key determinant of company success.

You need to be fast. You need to outrun the competition. But that only works if you’re in the right race. The most efficient product is the one that doesn’t have unnecessary capabilities clogging up its feature set, obscuring its core value. If you join a race without qualifying first, how do you know if you’re in Formula One or the Demolition Derby?

After writing about how some organisations are reactive by design, a reader challenged me on whether I was forgiving dysfunction.

I won’t lie. I flinched a little. I wondered if I’d missed the point I was trying to make, that intentional reactivity is not a bad thing. A reactive organisation that adopts a flexible planning model can create a dynamic environment where teams can not only pivot and respond to change, they can actively welcome it.

However, when an organisation pours large amounts of energy and efforts into planning, then disrupts it without pause as soon as an urgent request comes in, its reactivity is a blind spot.

Imagine that you work in an organisation like this. You’ve just tied the bow on your latest quarterly planning. You’ve got epics written, sized and sequenced. Day one of the quarter comes and, while you’re still tidying up a few hangovers from the previous quarter, you’re confident that you’ll get to your plan and make good progress against it.

On Day 3, an urgent customer request gets relayed through from a senior leader. The dev team scramble to react. Your beautiful plan is in tatters. This is the fifth quarter in a row this has happened. Everyone on the team is as frustrated as you are.

The good news? This organisational blind spot presents an opportunity.

If an organisation refuses to accept that it is reactive, then it is saying that it values its plan. If teams are constantly dealing with interruptions, then it doesn’t have the processes in place to protect this plan. It doesn’t understand how to respond, so any new request goes straight to the product team, with little, if any, intervention.

This hits the product team like an asteroid. Once the request breaches the organisation’s atmosphere, it’s going to slam into an unsuspecting team. The result is chaos, with plans interrupted as people react to this latest demand, assuming that it is now the most important thing in the world.

You need a heat shield.

The issue isn’t that the organisation doesn’t value its plan. It’s that it doesn’t have the wherewithal to prevent interruptions making their way to the team. For Engineering Managers and others caught in the middle of this, it can feel impossible to make progress. They have a new urgent priority to deal with, their stakeholders are still expecting delivery on their plan, and they have no idea what the scope of the new request is. Everyone is reacting, Nobody is responding.

Responding, fast and slow

In Thinking, Fast and Slow, Daniel Kahneman describes how we all have two ways of dealing with changes to our environment.

System 1 is our automatic response to things that happen around us. It’s intuitive, emotional, and relies on shortcuts and associations built from experience. This system handles everyday tasks like reading facial expressions, driving on an empty road, or detecting hostility in a voice. It’s efficient but prone to biases and errors because it jumps to conclusions based on limited information.

System 2 kicks in when we intentionally allocate attention to a topic. It is invoked when we are faced with tasks that require difficult calculations, careful analysis, and deliberate choices. This system is slower, more logical, and capable of following rules and making comparisons. You use System 2 when solving a difficult maths problem, parking in a tight space, or checking the validity of a complex argument.

Our brains try to deal with changes using System 1 as much as possible. When System 1 encounters difficulty, it calls on System 2 for more detailed processing. However, System 2 is lazy, and we often accept System 1’s suggestions without sufficient scrutiny, leading to predictable errors in judgement.

This happens in the organisation when new urgent requests arrive. Change request = instant interruption is System 1 thinking. Everybody defaults to a panicked reaction, running around trying to make everything work. Nobody stops to think ‘what should we do here?' There’s an instant assumption the plan will be interrupted, but, often, this assumption isn’t tested.

Calling the organisation’s System 2

Instead of presuming that the customer or leader’s demand is an immovable interruption, any request that will derail a plan should be brought into a review process. This forces the organisation to make a conscious decision about it. This review involves Engineering Managers and Product Managers, and takes place before any engineers are interrupted.

This review will cover:

• what is the request?

• how much of an interruption is it?

• what are the trade offs?

• how does the request fit with the longer-term product roadmap?

This will lead to a recommendation or decision as to whether to accept or reject the interruption. The product team will only be disturbed from their work if the interruption is accepted, thus protecting them from unnecessary distraction.

How does this review work?

The requestor should write down as much as they know about the request, and then a meeting is held with the Engineering Manager and Product Manager to review it. The resulting review and recommendation is recorded in writing.

Creating this written record is essential. Documenting the number and source of potential interruptions may lead to decisions from the organisation about dealing with them before they come to the product team. It also ensures that there’s a record of requests from customers that the team has chosen to push out. These requests may inform the upcoming product roadmap.

Let’s break down the key parts that the review must cover.

1. The request

Calling the organisation’s System 2 requires a proper consideration of the request. Instead of just reacting and asking the team to jump all over a vague request, the person representing the request has to definitively say what the ask is. This requires proper consideration of the scope of the request, its urgency, and the customer requesting it. This should be written down in as much detail as possible.

2. The impact

The request should be sufficiently well-defined that the size of the ask is obvious. Does this require a couple of engineers for a couple of weeks? A full development team for three sprints? Is it effectively a roadmap pivot? Understanding the impact will give the decision-makers context on how much of an interruption they will be imposing on the team.

3. The trade-offs

It’s critical that the request comes with a statement of the benefits of doing it. Does it represent a killer commercial opportunity? Is your biggest customer going to go to a competitor if you can’t achieve feature parity? Given your understanding of the impact, what are the costs this will impose? What isn’t going to get done if this interruption is accepted?

4. The fit

It’s possible that the request, while it’s not currently prioritised, is aligned with the overall product roadmap. This makes it easier to accommodate than a full pivot to new, as-yet unconsidered, functionality. It may also lead to telling the customer that while the request won’t be accommodated now, it is on the roadmap, and similar functionality that will allow the customer to achieve their goals will be available in a few months’ time.

5. The recommendation

Once all of the above information is considered, the reviewers make a recommendation. This can be to reject the interruption, in which case the team will not be interrupted.

For example, a Sales Director returns from negotiations with a prospect that would be a great addition to the client portfolio. They’re not necessarily going to be a massive client, but it is a marquee name. The Sales Director issues a demand for a new product capability, claiming that if it isn’t built immediately, then the client won’t sign. Reviewing the request reveals that it would be a three-month pivot for a prospect that hadn’t signed. The team would have to abandon work that’s committed for some of the organisation’s highest-value clients in the coming quarter. The prospect’s ask is turned into a planned piece of work for the upcoming quarter instead, and communicated as such to the prospect.

If the interruption is accepted, then the work is brought to the team with the supporting context, so that they completely understand what is driving this decision, and the benefits of changing tack.

For example, an Account Manager flags that they need SSO integration for a $400k contract renewal in six weeks. The request is documented by the Account Manager in partnership with the Product Manager. The review reveals it to be approximately three weeks’ work that would put a planned performance optimisation at risk. With the commercial risk clear and the trade-off understood, the interruption is accepted. When it comes to the team, it comes with full context about the customer, the revenue at stake, and what is being deprioritised. No panic, just a calm pivot. The performance work can be planned for the next quarter, not lost in the chaos.

Why does this work?

The immediate benefit is obvious: your team isn’t interrupted until there’s a conscious decision that the work is necessary. But the compound effects run deeper.

First, you’re breaking the reaction cycle. When every ‘urgent’ request triggers immediate action, teams start to believe that planning is theatre. They stop investing mentally in the roadmap because experience has taught them it’s fiction. The review process signals that plans have value worth protecting, which also makes teams more willing to pivot when it’s genuinely needed.

By creating space for System 2 thinking, any request that comes to the team arrives with full context and explicit trade-offs. Teams can absorb the change calmly rather than reactively. There’s no need for an emotional reaction. The process builds trust, which aggregates over time.

Second, you are building a written record of requests, both accepted and rejected, that becomes valuable data for addressing how the organisational system works. How many interruption requests happen per month? Where do they originate? How often are they accepted? Six months in, you might discover that a high number of ‘urgent’ requests come from one account management team that aren’t triaging customer requests appropriately. You can then work with that team to understand how to deal with these requests rather than pass them on to the team.

The heat shield doesn’t just protect against individual asteroids. It’s an effective planetary defence mechanism.

What happens if everyone keeps reacting?

It’s going to take a while for the wider organisation to appreciate what you’re doing. If you can get an executive sponsor for the new process, it will help to get other parts of the organisation aligned.

Some rejections will result in escalations to senior leadership, and the record of the review will help ensure shared understanding of the decision. It may get reversed, but at least the logic will be clear.

The very act of slowing down, and playing back the request and its trade-offs will force people to slow down and really consider the value of the request. You’ll be surprised how often simply articulating the trade-offs transforms ‘must-have immediately’ into ‘let’s schedule this properly.’

Start responding

If you work in the kind of environment where plans get raised, and then get razed, introduce this process. You won’t immediately stop the interruption requests. They’re the organisation’s default System 1 reaction.

But you can protect your team by invoking a System 2 response. The asteroids will keep coming. Be the heat shield.

Estimates shouldn’t be treated as commitments.

The planning fallacy means all estimates are fundamentally flawed.

But teams still need to estimate, and estimates still have value in enabling organisations to understand cost-benefits and trade-offs.

Trying to get ‘better’ at estimation or investing heavily in planning overhead are seductive traps that don’t actually improve forecasting. They don’t help to surface the risks and blind spots that estimators commonly overlook. One thing that can do this is a pre-mortem.

What’s a pre-mortem?

Looking back is well-established as a way for teams to learn and improve. Retrospectives (or post-mortems) are a key tool for teams to inspect and adapt their practices, learning from when things have gone wrong.

Pre-mortems use a similar approach, by asking teams to imagine all the things that could cause them to fail before they start the work. This isn’t just playing around with timelines. It’s a powerful way of leveraging the very biases that make estimations flawed.

Estimates are by necessity best guesses about the future. People tend to forecast optimistically, underestimating difficulties and discounting obstacles. Even having experience of similar issues, and having encountered substantial difficulties in the past, isn’t enough to prevent people using the happy path to estimate effort. Having the team forecast failure instead of success offers better protection.

A pre-mortem is a structured exercise, best suited to complex or novel work where a team has little expertise. It’s a forced perspective shift that helps surface risks that estimation usually misses.

The process is straightforward. After creating an initial estimate, the team imagines a future where they’ve failed completely. “It’s [x] months from now. We started this work and it’s been a disaster. We have failed utterly in our objective. What went wrong?”

The team lists everything that could have gone wrong, maps these into risks, discusses mitigation strategies, and then, crucially, revises the estimate in light of what they’ve surfaced.

Why are they important?

Pre-mortems work because they exploit how the ‘inside view’ functions. In normal estimation, the inside view is optimistic - the engineer imagines the specific steps they’ll take to complete the work, and underplay the risks that they’ll get distracted or that something will go wrong. Historical or statistical evidence (the ‘outside view’) feels abstract and irrelevant, so any deviations from the inside view tend to be ignored.

Pre-mortems don’t waste time trying to get the team to take history or statistics more seriously. Instead, they hijack the inside view and point it at failure. “Imagine having failed” is every bit as vivid and concrete as imagining success. It surfaces completely different information. The team still gets to think in specifics, but now those specifics are risks rather than happy paths.

There’s also a social dynamic at play. In normal estimation, people can feel pressure to sound confident and capable. Voicing concerns can feel like admitting weakness or cynicism. People can worry that it appears that they’re not supporting the team.

But when the facilitator asks “what went wrong in our failed project?”, pessimism becomes collaborative rather than individual. Everyone’s imagining the same disaster, so naming specific risks feels safe.

There are no guarantees that this will completely remove the planning fallacy, but it empowers the team to consciously consider the risks they may not have thought through when initially estimating the work.

What does it look like in practice?

Let’s imagine that a team estimates the effort to migrate a legacy authentication system at six weeks. In the pre-mortem, they imagine it’s six weeks later and the project has failed. They are nowhere near achieving their goal. What happened?

One developer immediately says ‘The documentation for the old system was out of date. We made bad assumptions that didn’t match current functionality.” Another adds “We were blindsided by downstream impacts in the monolith - we just didn’t foresee all of the dependencies we had.” A third engineer states “The company changed its policy about using the third-party identity provider we had identified as our solution mid-project, meaning we had to start again with a different provider.” The QA engineer points out “We didn’t have a test environment that properly mimicked production, so we didn’t capture all of the regression bugs before we deployed.”

None of these concerns informed the original estimate. These are no longer abstract risks. They’re specific, concrete failures the team now realises that they have to account for. The team revises their estimate to 10 weeks and adds three mitigation strategies: audit the existing system before starting, create a proper test environment, and add buffer for third-party dependencies.

What can go wrong?

Let’s pre-mortem the pre-mortem! Pre-mortems can fail in predictable ways, including framing, operating at the right level of detail, and inaction. Let’s take these in turn.

Framing

Asking “what could go wrong?” won’t shift the team’s mental model. Make sure to frame the pre-mortem with “We have failed. What happened?” This gives everyone permission to think of scenarios and risks, and to be pessimistic. Asking “what could go wrong?” doesn’t go far enough in pushing the team out of the optimistic inside view. They need the vision of their own failure to help them see how much trouble they can get into.

Too little detail

Another cause for concern is if the team only offers superficial risks when challenged about how they failed. If the team isn’t willing to get into concrete examples of where things can go wrong, then the optimistic psychology of the original estimate won’t be challenged.

The facilitator of the pre-mortem needs to drive the team toward specific scenarios. “The requirements might change” is an acknowledged risk of every initiative everywhere, and won’t challenge the team’s initial thought process. “We overload the API and can’t deliver acceptable performance without upgrading our infrastructure (which we know is outdated)” is the kind of situation that an engineer can absolutely see themselves in.

No action

If the team is willing to engage in considering scenarios that surface major risks, but then aren’t given the opportunity to alter their estimate in a blame-free way, not only have they wasted their time, they’ve had their psychological safety undermined. Estimates are always wrong. It must be safe to revise them.

When shouldn’t you use them?

Pre-mortems are most valuable for complex, novel, or uncertain work. For routine tasks or well-understood problems, they’re overkill. If the team has done something similar five times before and it always takes two weeks, a pre-mortem won’t add much value. If the team still insists on estimating at three or four days, use the real data you have.

Save pre-mortems for the work that worries you.

Reality always wins

Pre-mortems don’t eliminate the planning fallacy. Even after a pre-mortem, teams will still underestimate. What pre-mortems do is surface specific risks that would otherwise remain invisible until they bite you. In the best case scenario, you’ll get an estimate that hews closer to reality. In the worst case, you’ll have a list of things to actively monitor and mitigate.

Think of pre-mortems as harm reduction, not a cure. You’re still going to be wrong. You’re just going to be slightly less wrong with mitigation strategies in place.

The register of his departure was signed, his corner office cleared, his legacy secured in the form of a dozen protégés who had learned at his knee.

Scrooge had been his star pupil. There is no doubt whatever about that, either.

Marley had taught Scrooge the great lessons: “You can be right and get nowhere,” Marley had told him once, “or you can keep your stakeholders happy and get everywhere.”

And Scrooge had applied these lessons wisely indeed! His dashboards were always green. His velocity was consistent. His delivery as reliable as the turning of the earth itself. Stakeholders praised him. Senior leadership promoted him. He was now Director of Product, and everyone agreed he was excellent at his job.

It was December, the twenty-fourth of December, to be precise, when this remarkable transformation began. Scrooge sat in his office reviewing the quarterly metrics with satisfaction. Everything was on track. Another flawless delivery awaited in the new year. Bob Cratchit, his most reliable Product Manager, had given his latest update that afternoon - the final update before the Christmas Day stakeholder reports were due. Yes, even Christmas Day. Stakeholders expected their reports, and Scrooge never disappointed stakeholders.

“A remarkable quarter,” Scrooge said to himself. “The reports will be ready by morning.”

He did not know that old Marley’s ghost would visit him that very night.

Marley’s ghost

Scrooge was awakened by the sound of chains. Heavy chains, dragging across the floor, and when he opened his eyes there stood Marley - or what had been Marley - wrapped round with chains forged from roadmaps and commitments, from promises made and corners cut, from all the accumulated weight of success achieved at costs never properly counted.

“Marley!” cried Scrooge. “But you’re—”

“Dead to the profession? Yes. Retired at sixty with a single-figure handicap? Yes. Bound in chains I forged in life? Also yes.” Marley’s face was drawn with something that looked like regret. “I taught you well, didn’t I, Scrooge?”

“You taught me how to succeed!”

“I taught you how to get ahead.” Marley shook his chains. “I showed you that pushing back meant risk, that stakeholder satisfaction meant rewards. And I was right - we both rose through the ranks.”

“Then why—” Scrooge gestured at the chains.

“Because we didn’t succeed, Scrooge. We appeared to succeed. I made CPO. I had the title, the salary, the respect. But what did I actually build? What difference did it make?”

Scrooge stared at the chains, unsettled by questions he could not answer.

“You will be visited,” said Marley, “by three spirits. Listen to them. See what they show you. Learn what I learned too late.”

And with that, Marley began to fade, his chains rattling one final time.

“Remember, Scrooge,” came his voice, already distant, “I showed you how to rise. But I never asked if the climb was worth it.”

Then he was gone, and Scrooge was alone in the darkness, waiting for the first spirit to arrive.

The first of the three spirits

The first spirit came as the clock struck one.

Scrooge awoke to find his room filled with a strange, soft light, and in that light stood a figure of peculiar aspect: it wore the appearance of a much younger person, yet carried about it an air of great age and wisdom.

“I am the Ghost of Product Management Past,” said the Spirit. “Rise, and walk with me.”

They passed through walls and time itself, until they stood in an office Scrooge recognised - his own office, but years ago, when he was but a lowly Product Manager himself.

There sat his younger self, and opposite him sat Belle. Bold, brilliant Belle, who read signals in customer behaviour that others missed.

“I know this,” said Scrooge. “This was the quarter we delivered the Customer Insights platform.”

“Watch,” said the Ghost.

Belle spread papers across the desk - research findings, user interviews, early usage data. “The data is telling us that building what we promised won’t solve the customer problem. We need to pivot. Early tests are telling us the user experience is too complex and the insights we’re returning don’t make sense to them. We need to solve these problems before we launch. It’ll take another six weeks.”

“Six weeks?” The younger Scrooge’s voice was hard. “Belle, we promised stakeholders delivery in three weeks. The roadmap is set.”

“But if we deliver something that doesn’t work—”

“It works perfectly well. This is what happens when we let perfect be the enemy of the good. We ship what we planned. We honour our commitments.”

The older Scrooge watched as his younger self brought in additional oversight - daily check-ins, tighter controls, detailed progress reports. Watched as the platform shipped on time, celebrated by stakeholders who did not yet know that users would abandon it within months. Watched as Belle became more silent and passive as the project was delivered. Watched as, three weeks after that launch, she handed in her resignation.

“She lacked resilience,” the younger Scrooge told senior leadership. “She couldn’t handle the pressure.”

“What else could I have done?” said Scrooge to the Spirit. “The commitment was made. Belle wanted to change everything at the last moment - that’s not how things work. Stakeholders were counting on us.”

The Spirit said nothing, but moved forward through time to a different office, larger and brighter. There was Belle - older now, more assured - presenting to a room of executives. The metrics behind her told a story of competing trade-offs as she talked them through the product strategy.

“This is Belle’s company now,” said the Spirit. “She found a place that valued courage over compliance. That rewarded her for changing course when evidence demanded it.”

“She learned to manage her stakeholders,” muttered Scrooge, but he could not meet the Spirit’s gaze.

“You learned what Marley taught you,” said the Spirit. “ But you never questioned what you were learning to do.”

The light began to fade, and Scrooge found himself back in his room, alone and unsettled in ways he could not name.

The second of the three spirits

The second spirit came as the clock struck two.

This spirit was large and jovial, dressed in robes that seemed woven from status updates and sprint reports. “I am the Ghost of Product Management Present,” it boomed. “Come!”

They stood in a conference room - Scrooge’s own conference room. Bob Cratchit was leading a retrospective. Around the table sat his team, including young Timothy, an associate product manager barely six months into his role, taking assiduous notes of all that passed.

“Right,” said Bob, and his voice carried a weariness that made Scrooge lean forward. “Let’s be honest with each other. The deadline for the Recommendation Platform is in four weeks. We’ve been off track for the last month, and we haven’t been able to pull it back in. What can we do?”

The team exchanged glances. Sarah, the tech lead, spoke carefully: “We could use a simpler model than what we scoped. It’ll work, but not well. It won’t scale. We’ll spend the next quarter being killed by performance issues.”

“And if we tell Scrooge we need another month to do it properly?”

The silence that followed made Scrooge’s chest tighten.

Bob sighed, and something in that sigh pierced Scrooge more deeply than he expected. “So we ship a simpler model in four weeks. We document the technical debt. We’ll fix it later.”

“Will we?” asked a developer, and his skepticism hung in the air like smoke.

“We’ll try to find some capacity,” said Bob, and everyone at that table knew what those words meant.

Tiny Tim closed his notebook, and Bob caught his eye as he left the room. Something passed between them - not words, but understanding. Scrooge saw it clearly: the lesson being learned, the pattern being set. How to protect the team and manage upward. How to make sure the stakeholders got what they wanted, and finding ways to limit the cost to the team.

Scrooge felt something cold settle onto his chest as he followed the Ghost and Bob into his own office, watching himself smile as Bob showed him a plan and a series of status updates. All green. He watched Bob sigh as he left the room, his eyes hollow.

“Spirit,” said Scrooge, his voice catching. “Tell me these people will be well. Tell me that Tim can grow, that Bob - “

“Perhaps they lack resilience,” said the Ghost, and Scrooge flinched at hearing his own words. “Perhaps they cannot handle the pressure.”

Scrooge hung his head, overcome with shame at hearing his own words.

“I never told them to lie,” he said weakly.

“You told them that pushing back was unacceptable,” said the Ghost. “You told them, as you told Belle, that commitments must be honoured above all else. They heard you clearly, Scrooge. They heard you very clearly indeed.”

“The boy,” said Scrooge, and his voice trembled. “What becomes of Tim?”

But the Spirit was already fading, and Scrooge was left alone with the image of Tiny Tim writing in his notebook, learning all the wrong lessons from watching all the wrong examples.

The last of the spirits

The third spirit came as the clock struck three.

This spirit spoke not at all, and Scrooge feared it most of all. It was shrouded in darkness, pointing ever forward with a hand that seemed to promise only dread.

“Spirit,” said Scrooge, “I fear you more than any spectre I have seen. But I know your purpose is to do me good. Lead on!”

They stood in a bright, modern office. Through the glass wall, Scrooge could see Belle’s name on the door of the corner office. This was her company.

And in a smaller room, Tim was speaking to a younger product manager. Papers spread between them, but Tim was shaking his head.

“I know we’re behind,” Tim was saying. “But we need to think about how we present this. Belle’s expecting to hear we’re on track. Let’s focus the update on what’s going well.”

“But the customer feedback -”

“Add their comments to the backlog. We’ll address them later. Right now, we tell her what she needs to hear.”

And Scrooge watched as the younger PM nodded, learning. As Tim forged another link in the chain Marley had first made.

“No,” whispered Scrooge. “No, he can’t have—”

But the Ghost showed him more. Tim in a different meeting, driving out a talented PM who dared to suggest they needed to replan. Tim presenting dashboards to Belle that showed progress while his teams quietly despaired. Belle sharing the data with her stakeholders.

“And Bob?” whispered Scrooge. “Where is Bob in this future?”

The Ghost gestured to a figure Scrooge had not noticed: older, greyer, sitting alone in a café at three in the afternoon on a Tuesday. Not working. Not anywhere. Just sitting, staring at nothing, burned out and gone.

“Spirit!” cried Scrooge, clutching at the phantom’s robes. “Are these the shadows of things that will be, or are they shadows of things that may be only? Men’s courses will foreshadow certain ends, to which, if persevered in, they must lead. But if the courses be departed from, the ends will change. Say it is thus with what you show me!”

The Spirit’s hand trembled.

“Good Spirit,” Scrooge pursued, “tell me that I may yet change these shadows! Tell me I can undo what I have done!”

The Spirit pointed directly at Scrooge himself - not at the future, but at the man standing before it now. The message was clear as any words: the choice was his. Had always been his. Would always be his.

The end of it

When Scrooge awoke, it was Christmas morning, and he was in his own bed, in his own room. The relief that flooded through him was as powerful as any joy he had ever known.

“I am myself again!” he cried. “The spirits have given me a chance, and I shall not lose it!”

He looked at his computer, where the Christmas Day stakeholder reports sat ready to send - all those carefully curated updates, all that theatre of success. He had promised stakeholders their reports, even on Christmas Day. He had never disappointed stakeholders.

But he had disappointed his people. He had disappointed Belle, and Bob, and Tim. He had disappointed himself.

Scrooge opened a new message. His hands shook as he began to type.

He would begin today. This very morning. He would tell his stakeholders that the project was off track. That he had set the deadline without proper foundation. That he had prioritised their satisfaction over his team’s ability to do good work. That he was sorry, and that he was asking them to trust him to make it right.

It was the most terrifying message he had ever written.

He sent it before he could lose his nerve.

Then he went to find Bob.

It would not be easy. The lessons of years could not be unlearned in a day. But Scrooge had seen enough - had been shown enough - to know that change must come.

And Tim? Tim would have a different teacher now. One who could teach him that listening to signals and changing course when evidence demanded it was courage, not weakness. That strength meant admitting error. That the greatest waste was not missed deadlines, but wasted potential.

Scrooge kept Christmas well, if any man alive possessed the knowledge of how to keep it. And it was always said of him afterwards that he knew how to build trust, how to honour evidence over ego. Some laughed to see the alteration in him, but he let them laugh, and thought the better of it. For his own heart laughed with them, and that was quite enough for him.

May that be truly said of us, and all of us!

Estimates are useful ways to communicate the challenges around different pieces of work. By helping a team to understand the problem space, they can consider how they might approach it and give an indication of effort. This can help with prioritisation and trade-offs.

It’s a useful way of doing an early cost-benefit analysis. An estimate of effort for a new experiment or product capability (the cost) can be compared with the benefit (which should form the basis of the Product Manager’s hypothesis). It’s an early sense check on the viability of pursuing the solution.

Estimates also enable the organisation to make decisions about trade-offs. There are only ever a finite number of people available, and there are multiple ways the organisation can choose to deploy them. Understanding the level of effort, the likely cost-benefit, and time to market helps stakeholders and leaders to decide which initiatives they want to back.

An estimate gives the team the opportunity to examine the shape of a solution and to get aligned around it. If the Product Manager believes they’re asking for something straightforward and the team estimates it at 6 - 8 months of work for 3 - 4 teams, this surfaces a difference in expectations early and cheaply. It’s possible that the Product Manager is underestimating the complexity of the problem. It’s equally possible that the team has misunderstood or misinterpreted the ask. Either way, there’s an early signal to ensure that the assumptions all sides have made are captured and corrected as appropriate.

It’s a snapshot

Recording these assumptions is paramount. An estimate is a snapshot. It’s a statement of current understanding. By recording assumptions and open questions, the team can indicate what it knows and what it doesn’t. An estimate can always be revised in the light of further information. I’ve seen estimates revised down from weeks to days of work as discussions surfaced different solutions and gave clearer definition of the problem being solved. Equally, we have to be prepared for estimates to grow as more information becomes available. For example, a team working on a novel solution may encounter unforeseen problems or have blind spots that mean they will have to re-estimate as they encounter these.

All estimates are wrong.

The most important thing that anyone can know about any estimate is that it is wrong.

Estimates are best guesses about the future. Like all guesses, they are subject to biases. Daniel Kahneman and Amos Tversky coined the term ‘planning fallacy’ to account for the fact that people tend to focus on the happy path, and ignore the likely obstacles and distractions they will encounter along the way. This fallacy occurs even when people have knowledge and/or prior experience of the complexity of the space.

How does this manifest itself? It goes to the very heart of the way we estimate as humans.

Let’s say an engineer looks at a problem, considers the steps they would take to solve it, and they come to what Kahneman and Tversky call an ‘inside view’ that it will take 2 - 3 days.

Even when shown data (the ‘outside view’) that a similar problem took them 3 - 4 weeks to resolve, the developer is likely to continue to under-estimate the complexity of the task, sticking close to their original estimate. People ignore or undervalue objective evidence like this again and again. It’s a deeply ingrained behaviour. The reason that quests for ‘better estimates’ fail isn’t because people don’t understand data. The case-specific information they’ve generated about this task feels more relevant and concrete than any historic or statistical data, and they cling to this rather than taking a data-driven approach.

Attempts to combat this error by adding a slippage factor are rarely adequate, since the adjusted value tends to remain too close to the initial value that acts as an anchor. - Daniel Kahneman and Amos Tversky, Intuitive Prediction: Biases and Corrective Procedures, 1979

Let’s imagine that our fictional engineer is estimating the effort to update an authentication flow. They consider that they need to build some new forms with input validations, and a method for recording the user details in the back end. “2 - 3 days, considering some of the other work I’ll have to do.”

As they actually do the work, reality dawns. There are gaps in the original requirements, including rules around password difficulty, and a handle forgot password flow. They get interrupted by production issues. There are some underlying libraries that need upgrading, along with some security updates. The original design didn’t have complete accessibility and responsiveness requirements. Some edge cases get raised when testing the new form, and there’s a downstream integration that starts failing because of the new flow. They have to write supporting documentation. A month goes by before the change finally makes it to production.

Do we think they’ll ‘improve’ their estimate next time? The evidence suggests that they won’t.

Along with the happy path planning fallacy, people tend to forget the other commitments they have competing for their time. A developer might estimate “four days” of coding while forgetting that they have six hours of meetings that week, a training course to attend, will need to wait for code review, and historically spend 30% of their time on unplanned work. That’s before we add in the need for design work and testing.

The longer that a task may take, the less likely an estimate is to survive contact with reality. As we look out across the cone of uncertainty, the further into the future we project, the less likely we are to have considered the probability of distractions and obstacles.

Some are useful.

Being aware of the inaccuracy of estimates doesn’t mean they’re useless. It means we need to use them with caution. They have a role in rough cost-benefit, or for guiding conversations about alignment or choices. What they shouldn’t be used for is planning.

Given that we know that teams will fail to account for complexity and unforeseen events, using a t-shirt size or an estimate of effort as a commitment is a mistake organisations make time and again. Years of effort are wasted on ‘improving’ estimates. Setting aside the language for a moment (‘improving’ is usually code for ‘shortening’), it’s a fight against reality.

Organisations often introduce more planning sessions, or introduce scaled agile frameworks to improve predictability. But these frameworks are no match for the cognitive biases hard-wired into human thinking. Calibrating story points, or arguing over how to reduce a XL t-shirt size to a L doesn’t deliver any value to the organisation. It just creates the illusion of certainty and reduces psychological safety. The team spends time trying to fit the work into an acceptable plan, instead of thinking about the most valuable work and finding ways to test their assumptions early and reduce uncertainty.

Reality always wins. The biases that lead to inaccurate forecasting occur time and again, even when we’re aware of them. We can only escape this trap if we use forecasts for what they are genuinely useful for - decisions around relative complexity or priority. Then we need to design the work so that we can falsify any hypotheses we have as cheaply and as easily as possible.

• Awareness - getting people to know you exist

• Acquisition - getting them to visit your site

• Activation - converting them into users

• Retention - ensuring they come back in sufficient numbers

• Revenue - monetising their activities

• Referral - having them act as ambassadors and references for the product

The team was seeing growth across the funnel, but they felt their retention numbers could be better. In-product surveys also gave them feedback about the need for more advanced analytics within the product. They dug into their retention numbers to verify if this was driving the retention drop-off and found that their abandonment was highest among users who wouldn’t have progressed far enough through the funnel to see any of the analytics in the product. What was going on?

They interviewed the users looking for investment in analytics and researched the concerns of the cohort of early abandoners. They found that there were two distinct issues in the funnel:

• some users loved the product but couldn’t do the kind of analysis they wanted on the data they were finding. There was no export functionality allowing them to easily push data to an external tool, so they effectively felt stuck.

• there was a large cohort of people who signed up for the product, got confused about the value proposition, and abandoned it before getting any value.

The team had limited resources, so couldn’t tackle both issues simultaneously. One was going to have to take priority. There were compelling arguments for both, and they debated long and hard. They repeatedly reached a stalemate when discussing which was the better bet. They couldn’t agree how to choose. This is where many teams get stuck, or worse, try to do it all.

Reframing the question

One day, trying to break the logjam, I asked “How do you maximise the value of work not done?”

In other words, which of these issues could they afford to put on hold while solving the other? Taking this perspective, it became obvious that while they ran the risk of losing some users by not upgrading their analytics, they would struggle to survive, let alone grow the product if they didn’t fix their activation flow to make the value proposition easier to understand.

It was clear that they needed to resolve the confusing messages in their activation flow. I made the point that it didn’t make any difference how beautiful their cooking was if they couldn’t get their dinner guests through the front door.

They realised that they could quickly build an export function that would enable users to export data. At the same time, they would rebuild the activation part of the funnel, and delay any further investment in analytics within the application.

This wasn’t without risk. It meant a fundamental change to the pattern of change the team usually delivered. Instead of releasing small increments quickly, they would be ‘going dark’ on product features for a reasonable amount of time, and then relaunching the product.

Measuring the power of ‘no’

The attrition rates of users who had invested time in the product wasn’t the biggest problem they faced; it was actually quite low. The abandon rate of new, expensively-acquired users was a significant drag. They hypothesised that they could double the amount of users who would complete the activation flow. This would have the happy result that advanced analytics would serve the needs of ever-higher numbers of users. Eventually, they could have the best of both worlds.

Their strategic ‘no’ was in fact building toward a larger strategic ‘yes.’ They were maximising the value of work not done. The challenge for them was to demonstrate that they had made the right decision.

So, how should these choices be measured? What’s the best way to measure the value created by a strategic ‘no’?

There are four dimensions that should be considered:

• Learning efficiency

• Customer outcomes

• System health

• Team effectiveness

These give a complete picture of the impact of the decisions you make. Learning efficiency enables you to validate quickly whether you’re on the right path. Customer outcomes demonstrate whether you chose the right problem, and it’s having the right impact. System health demonstrates you built it sustainably. Team effectiveness confirms that you have the correct environment for continued success.

Learning efficiency

Learning efficiency is about your time to qualify. How quickly can you tell whether you’ve made the right call? What are the early indicators you can use to suggest that you’re on the right path?

In the SaaS business, the team had user research and historic retention rates to guide their choice. They instrumented the activation flow so that they could see exactly where confusion arose. Interviews with abandoners underlined the problems that required attention. They tested different flows before building anything, so that the most promising solutions would guide their development.

Customer outcomes

Customer satisfaction rates give good insight into the quality of your choices. Strong customer satisfaction or Net Promoter Scores indicate that you’re solving problems your customers and users care about.

Removing frictions from the AARRR funnel is key. Many customers won’t bother filling in customer satisfaction surveys if they’re annoyed. They’ll simply stop using your service. A combination of pirate metrics (or similar) and customer satisfaction will give you a strong sense of how customers view your choices.

It’s important to measure the impact against your original hypothesis. Were your forecasts accurate? Can you demonstrate or appraise the impact of your changes on your company’s bottom line?

In the SaaS business, the team had forecast that their retention rates would double. In fact, they tripled while customer satisfaction scores stayed stable. These metrics gave the team confidence they had made the right choice.

System health

Saying no to ideas that don’t drive you forward reduces technical debt and the cognitive load of the team in managing the application. Focusing on what matters will lead to an increase in quality.

In the SaaS business, ‘going dark’ on new product features gave the team the ability to focus on their most important problem, delivering an enhanced technical solution as well as solving the customer-facing issue. This should be an aspect of every choice you have to make - how can we reduce the technical burden of the system?

Team effectiveness

Narrowing the focus of teams through strategic choices ensures they can operate more effectively by ensuring that there are fewer context switches. By keeping the team focused on a single goal, you build confidence and there should be less noise coming from outside the team, and therefore fewer wasted features, built without evidence or a driving hypothesis.

By ruthlessly prioritising, you can ensure that the team ignores any other feature requests. Like the team in the example, you can continue to work on prioritised and promised capabilities, researching and preparing for the next big initiative, while keeping the engineers focused on the promised work. The team did this by ensuring there was absolute clarity about completing the activation work before any further engineering effort would go into analytics.

The broader lesson

Organisations need to accept the value of strategic rejection. If “you can’t prove a negative,” it robs you of the ability to say no. No customer requests will ever be refused. No stakeholder ideas will ever be challenged, however much evidence there is that they’re not meeting customer needs. Worse, there is no room for any failure. Every launch, every new feature, must succeed. Psychological safety withers. Experimentation never happens. Research is ignored. The rise of the feature factory is inevitable.

This manifests itself in insidious ways in larger organisations. The disciplined Product Manager that says ‘no’ to ideas that haven’t been even half-baked gets passed over for promotion in favour of the one who lets their product bloat with barely-used features. PMs who look for data and evidence to power their hypotheses are criticised for being slow, while other teams build a Frankenstein’s monster quickly, just piling releases one after another, with no coherent strategy.

What can we do to fight back when everything becomes urgent, and everything must succeed? How do we demonstrate the value of disciplined prioritisation? As the B2B SaaS team did, you need to demonstrate the positive contribution that your choice made to the organisation. Using the above metrics makes it clear whether your bets paid off.

In the SaaS business, the team had to deal with concerns from customers as they waited for their in-app analytics to improve. By giving them a data export function and continuing conversations, they were able to iterate quickly on different solutions for different market segments. The wait was worthwhile because they built something better. They made sure they had guests moving through the front door, then served them a feast. Strategic rejection didn’t slow them down. It gave them time to cook something worth serving.