There are three questions every coach should be able to answer about any team they’re working with.

1. Is the practice improving?

2. Who is the practice dependent on?

3. What would happen if you weren’t there next Friday?

Most of us answer those from gut feel. We’ve been in the room enough times. We sense the momentum, or the absence of it. We know when something’s starting to stick and when it’s still being held together by the fact that we keep showing up.

That instinct is real. It’s also invisible, non-transferable, and impossible to hand to a client as evidence of anything.

I’ve been experimenting with a workflow that changes that. Not by replacing the coaching eye, but by making it legible.

What trajectory actually looks like

I wrote this week on Medium about a standup I ran with a team I’ve been coaching for 8 weeks (the link is in the footer if you want the full story).

The short version: I took the screen on a quiet Friday morning, half the team absent, and ran the flow check-in myself, deliberately, as a modelling exercise. A developer asked a question I wasn’t expecting: “If there’s no code being written, but people are still chasing third parties, what state is that ticket, technically?”

That question is what eight weeks of coaching looks like when it starts to land. A team member trying to reconcile what the board says with what’s actually happening. Not reporting status. Thinking about the system.

But here’s the thing. I know that’s what eight weeks looks like because I have the data.

Not a gut feeling. A table.

That table tells me several things I couldn’t have articulated as clearly from memory alone.

The practice has a ceiling when the delivery manager is facilitating, around 6.5 on a good day. The 3.0 on that Friday, the team ran it without him, is not a blip. It’s a structural signal: the practice isn’t team-owned yet, it’s DM-dependent. And the 8.0 on the Friday I ran it? That’s the most important data point of all.

The highest-quality session in eight weeks was run by the external coach. Which means it doesn’t count as evidence of team capability. It counts as evidence of what the practice looks like when it’s done properly, a model for the team to aim at. But the coaching job isn’t done until the delivery manager, or anyone else in that room, can get to a 7 without me.

That’s not a feeling. That’s a gap I can measure.

The workflow (the bit you can use tomorrow)

Here’s how this actually works, practically, without revealing anything client-specific.

Step 1: Define your standard. What does a good flow check-in (standup) actually look like? Not vibes, but specific, observable behaviours. Invisible work checked. Ageing items walked oldest-first. WIP limits named. Pull policy applied. Blockers categorised. I have mine in a public GitHub repo (link at the bottom), but the point is that you need something to measure against. A rubric. Yours doesn’t have to be mine. It just has to exist.

Step 2: Record the session. I use Granola, which automatically transcribes and structures meeting notes, but any transcription tool works. The point is that you’re not relying on memory or observation notes scribbled in a notebook - you have a record.

Step 3: Run the transcript against the standard. This is where the machine earns its keep. I’ve built a Claude skill, a structured prompt, that takes the transcript and scores it against the flow check-in standard, dimension by dimension. It outputs a score, a breakdown of what was present and what wasn’t, what’s improving, and coaching priorities for the next session.

It takes about ninety seconds. It produces something I could never produce manually at this level of consistency across multiple teams, multiple sessions, and multiple weeks.

Step 4: Track the trajectory. A single score is just a number. Seven scores over eight weeks is a story, and the story answers the three questions I started with.

Is the practice improving? Yes, with the delivery manager - slowly, with two steps forward and one back. Who is the practice dependent on? Still the delivery manager, and underneath that, still me. What would happen if I weren’t there next Friday? A 3.0. We know this. We have evidence of it.

What the machine can’t do

It can’t notice the moment a developer asks the right question for the first time. It can’t read the room when someone is covering for a colleague who hasn’t yet understood the board. It can’t decide when to hand back the screen and when to keep holding it.

It can’t tell you why the Friday score is always lower, only that it is.

That’s still your job. The instinct, the judgment, and the presence are irreplaceably human.

But the machine can do something coaches have always struggled to do: it can give you evidence of your own impact, session by session, over time. It can turn “I think this team is improving” into “here’s the trajectory, here’s where the dependency sits, here’s the specific gap to close before I step back.”

That’s not a replacement for coaching experience. It’s what coaching experience looks like when it stops being anecdotal.

The question worth sitting with

Before I go, the three questions again, but this time pointed at you.

For any team you’re currently working with:

1. Is the practice improving?

2. Who is the practice dependent on?

3. What would happen if you weren’t there next Friday?

If your answers are “I think so,” “probably me,” and “I’m not sure”, that’s not a failure. That’s just where most coaching sits without the data.

The workflow exists. The tools are available. The standard can be built in an afternoon.

The only thing missing is the decision to make your coaching eye visible.

I’ve written about the coaching moment itself - the standup, the developer’s question, the tension between modelling and dependency, over on Medium this week. If you want the narrative version, that’s the place.

The flow check-in standard I measure against is public: github.com/Thrivve-Partners/flow-playbook

If you’re experimenting with something similar, or want to, I’d genuinely love to hear what you’re scoring.

Just before Christmas, I got tired of waiting for data.

Not because I’m impatient for the data team to do their thing, I work with excellent people, but because their queue is the bottleneck. And bottlenecks don’t just slow decisions, they shape which questions you ask in the first place.

So I built something different: an AI assistant that lets me query our web analytics in plain English, with answers back in 3-5 seconds.

No SQL required. No analyst intermediary. No tickets, no queues, no waiting.

This isn’t vapourware or a vendor demo. This is working code running in our consulting practice, built with tools that became viable only in December 2025.

Here’s how it works, how to build it yourself, and what actually changed when data access became frictionless.

What it looks like in practice

I open Claude and ask a simple question:

“How did the web stats from the company yesterday compare to the same day last week?”

Three seconds later, I get the answer. The AI generated the SQL, validated it was safe, executed it against BigQuery, and formatted the results, all from my natural language question.

No context switching. No opening BigQuery console. No remembering table schemas or writing WHERE clauses.

Just: ask a question, get an answer, keep thinking.

The Architecture

The system has two main components: Claude (the conversational AI) and n8n (the workflow automation tool that writes and executes the queries).

Here’s the flow:

1. Question in plain English: I ask Claude a question about our website analytics.

2. Workflow discovery: Claude searches for available n8n workflows via the MCP (Model Context Protocol) and identifies the analytics workflow.

3. Workflow execution: Claude calls the workflow, passing my question as a parameter.

4. AI-generated SQL: Inside the n8n workflow, another instance of Claude generates the appropriate BigQuery SQL query based on my question and the table schema.

5. Query validation: The workflow validates that the generated SQL is safe, so SELECT only, no dangerous operations.

6. BigQuery execution: The query runs against our analytics database.

7. Formatted response: Results are returned to Claude, presented conversationally.

The entire round trip takes 3-5 seconds.

The key insight: Using AI twice. Once to orchestrate (Claude in the conversation), once to generate SQL (Claude inside the n8n workflow). This separation means SQL generation can be constrained, validated, and logged independently of the conversational interface.

The n8n Workflow Breakdown

The n8n workflow that powers this has six components:

1. Webhook Trigger

Receives the question from Claude via MCP. This is the entry point; Claude calls this webhook when I ask an analytics question.

2. AI Agent (SQL Generator)

Uses Claude to convert the natural language question into SQL. The system prompt looks like this (I’m still tweeking it):

You are a SQL query generator for BigQuery.

Generate ONLY the SQL query, no explanations.

Table: project.datasetname.`web-analytics`

Schema:

- id (STRING)

- hostname (STRING)

- path (STRING)

- referrer (STRING)

- added_iso (TIMESTAMP)

- updated_iso (TIMESTAMP)
...

Rules:

- ALWAYS use backticks around the table name

- Use TIMESTAMP functions for date filtering

- “last N days”: WHERE added_iso >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL N DAY)

- Return only SELECT queries

- Use proper BigQuery SQL syntax
...

The schema context is critical because it tells the AI exactly what data exists and how to query it.

3. SQL Validator (JavaScript Code)

Ensures the generated query is safe before execution:

javascript
// Extract and clean SQL from Claude’s response

let cleanSQL = sqlResponse

  .replace(/```sql\n?/g, ‘’)

  .replace(/```\n?/g, ‘’)

  .trim();

// Safety checks

if (!cleanSQL.toUpperCase().trim().startsWith(’SELECT’)) {

  throw new Error(’Only SELECT queries are allowed’);

}

if (cleanSQL.match(/DELETE|UPDATE|INSERT|DROP|CREATE|ALTER|TRUNCATE/i)) {

  throw new Error(’Dangerous SQL detected’);

}

return { cleanSQL };

This validation runs before the query executes. If it fails, the workflow stops.

4. BigQuery Execution Node

Runs the validated query against our analytics database using n8n’s native BigQuery integration.

The BigQuery service account has read-only SELECT permissions. Even if validation somehow failed, the worst case is a failed query, not data corruption.

5. Result Formatter

Packages the results with metadata:

• Original question

• Generated SQL (for transparency/debugging)

• Result rows

• Row count

6. Webhook Response

Returns formatted results back to Claude, which presents them conversationally.

Exposing the Workflow via MCP

The magic that allows Claude to “see” individual n8n workflow instances is the Model Context Protocol (MCP), upgraded from beta by n8n in December 2025.

MCP lets AI assistants not just suggest actions but actually execute them by calling external tools and workflows.

In n8n, I configured the workflow to be available via MCP with this description:

Query the company web analytics from BigQuery using natural language.

Accepts ‘question’ in webhook body. Converts questions to SQL using AI,

executes against SimpleAnalytics data (page views, traffic sources,

user behaviour). Returns SQL query and results. Use when user asks

about website traffic, popular pages, referrers, campaigns or visitor 

analytics.

This description helps Claude know when to use this workflow. When I ask about website analytics, Claude sees this available tool and calls it automatically.

The n8n MCP server runs locally and connects to Claude via the desktop app configuration.

Security Considerations

Allowing AI to generate database queries raises obvious security concerns. Here’s how I addressed them:

Query validation before execution: Every generated SQL query is validated to ensure it’s a SELECT statement with no dangerous operations. The validator runs before the query is executed against the database.

Credential isolation: BigQuery credentials are stored in n8n and never exposed to Claude. The AI can execute workflows but can’t access credentials directly.

Read-only database access: The BigQuery service account has SELECT-only permissions. No writes, no schema changes, no data deletion.

Comprehensive logging: Every question, generated SQL, and result set is logged. We can audit what’s being asked and how it’s being answered.

Rate limiting: The n8n workflow can be rate-limited to prevent abuse or runaway costs.

Schema constraints: The AI’s instructions include the complete schema, so it knows exactly what data exists and how to query it properly. This reduces hallucination and invalid queries.

Is this perfect? No. Could a sufficiently adversarial prompt bypass validation? Possibly. But the risk profile is similar to giving someone SELECT access to a database, which is exactly what we’re doing, just with a more ergonomic interface, and without the SQL and BigQuery learning curve.

For internal product management use cases, this is entirely acceptable risk. For customer-facing applications, you’d want additional safeguards like query complexity limits, cost caps, and user-level permissions.

Beyond analytics: the pattern that generalises

Web analytics is just the starting point. The pattern applies to any data source with an API or database connector:

Customer feedback

Query Intercom conversations, support tickets, and survey responses.

“What are customers saying about our checkout flow?”

Product usage

Query application databases.

“Which features did users who churned last month interact with least?”

Development metrics

Query JIRA, GitHub, and deployment data.

“What’s our 85th percentile cycle time for bugs fixed this month?”

Financial data

Query Stripe, revenue databases.

“What’s our MRR retention cohort by cohort for the last six months?”

The power comes not from any single query, but from combining them in one conversation:

“Show me the top 10 features by usage in the last month, then cross-reference with support tickets mentioning those features, then show me the customer segments for users reporting issues.”

This kind of multi-source analysis was previously the domain of data teams spending days in Jupyter notebooks. Now it’s a conversation.

Each data source gets its own n8n workflow with appropriate schema context, validation rules, and access controls. Claude orchestrates them all via MCP.

Build time

My first working version took about 70 minutes, including:

• Setting up BigQuery connection in n8n

• Building the workflow

• Writing validation logic

• Configuring MCP

• Testing basic queries

Subsequent workflows for other data sources take 30-60 minutes once you understand the pattern.

The pattern is:

1. Webhook trigger

2. AI generates query/request

3. Validate it’s safe

4. Execute against the data source

5. Format and return results

Everything else is customisation.

What actually changed

Here’s what I didn’t expect:

It’s not the speed. Getting answers in 3 seconds instead of 3 hours is nice, but that’s not what changed my behaviour.

It’s the questions I started asking.

Questions I wouldn’t have bothered an analyst with. Tangential hunches. “I wonder if...” explorations that might go nowhere.

The friction disappeared, and with it, the self-censorship.

I noticed a pattern in referrer data and investigated it immediately rather than noting it for later (which meant never).

I designed an experiment because understanding the current state became trivial instead of heavyweight.

I asked follow-up questions in real time instead of batching them into a single data request.

This is what independence enables: continuous inquiry instead of periodic reporting.

Not quarterly business reviews with carefully prepared slides. Daily, hourly investigation into what’s happening and why.

The experimental mindset that evidence-based product management actually requires.

What This Isn’t

This isn’t a replacement for data analysts or data teams.

Good analysts bring:

• Statistical rigour

• Experimental design expertise

• Deep domain knowledge

• Pattern recognition across multiple contexts

• The ability to ask questions you didn’t know to ask

AI can’t replicate that.

What this does replace is the dependency on analysts for routine data access.

Simple questions that don’t require sophisticated analysis but do require quick answers: What happened yesterday? Which variant is performing better? Did that launch move the metric?

This shifts the relationship from “please get me data” to “here’s what I found, what am I missing?”

The analysts I’ve spoken with are enthusiastic about this. They’d rather spend time on complex analysis and experimental design than writing routine SQL queries.

The Pattern Is Emerging

The tools to build this have existed for less than a month. MCP launched in December 2024, and n8n took their “expose workflows” feature out of beta in December 2025. The pattern is still new.

But I’m convinced this represents a fundamental shift in how product managers can work with data, moving them from “requestor” to “independent investigator”, with direct query capability.

Not because AI is magic, but because it removes the friction that prevented curiosity from becoming inquiry.

When asking a question takes 3 seconds instead of 3 days, you ask different questions.

When exploring a hunch doesn’t require justifying it to someone else, you explore more hunches.

When data access isn’t rationed by analyst availability, you develop an experimental mindset.

This is what independence looks like.

And independence changes everything.

If you build this, I’d love to hear what you learn. What questions do you ask when data access is frictionless? What patterns do you notice? What breaks?

Hit reply and let me know.

You’re in the daily standup. Again.

Everyone’s giving updates. Cards are moving. The board looks healthy. Stakeholders are happy.

But you can feel it.

That nagging sense that you’re shipping things nobody asked for.

That work keeps flowing, but nothing ever feels like it matters.

That the metrics say you’re productive, but customers are still struggling with the same problems they had six months ago.

You escaped the Feature Factory once. But somehow, you’re back.

And here’s the twist: you didn’t even notice it happening.

Because the modern Feature Factory doesn’t look like the old one. It doesn’t have Gantt charts and waterfall documentation; it has OKRs, runs experiments, and even speaks fluent “customer-centric” and talks about outcomes.

It just never actually delivers them.

The recognition moment

Let me ask you something uncomfortable:

When was the last time you killed a feature after shipping it?

Not “deprioritised for later.” Not “added to the backlog for iteration.” Actually deleted it because it wasn’t working.

If your answer is “never” or “I can’t remember,” you’re in the factory.

Here’s another one:

Can you identify the specific customer behaviour that changed as a result of the last three things you shipped?

Not “we got positive feedback.” Not “adoption is tracking well.” Actual behaviour change. The thing customers now do differently because of what you released.

Struggling? That’s the sound of output masquerading as progress.

The modern Feature Factory is stealthier than its predecessor. It knows the language. It performs the rituals. It looks lean.

But under the surface, though, the core operating system hasn’t changed at all:

• Work is judged by how much gets done, not what changes

• Teams are praised for shipping, not questioning, and definitely not stopping

• Roadmaps are packed with features that no one remembers writing a hypothesis for

• The product strategy exists, but nobody knows how it connects to the next 10 Jira tickets

You’ve upgraded the rituals, but not the mindset.

The Feature Factory didn’t return, despite your modern tools. It returned because you mistook those tools for transformation.

What you’re really training your team to believe

Every time you operate this way, you’re not just failing to deliver value, you’re actively training your team that value doesn’t matter - that motion equals progress, and that “done” is the goal.

At one company I worked with, a team spent six months building a “strategic” onboarding revamp. It shipped on time, the dashboard lit up green, and everyone applauded during the demo. Three months later, activation was flat, trial-to-paid conversion hadn’t moved, and churn in the first 30 days had actually nudged up. Nobody could say what behaviour had changed, only that “we shipped it.”

The cost isn’t just wasted effort. It’s:

• Teams that stop asking “why are we doing this?”

• Engineers are burning out from delivering work that doesn’t matter

• Customers who quietly leave because nothing ever gets better

• Your credibility is evaporating with every launch that doesn’t land

As Viktor Frankl said: “Life is never made unbearable by circumstances, but only by lack of meaning and purpose.”

Shipping without impact is a morale killer.

The five warning signs you’re back in the factory

1. Throughput worship

You’re tracking what shipped, not whether it mattered.

The smell: “We closed 47 tickets this week!”

Better question: “Which of these deliverables made a measurable difference?”

2. OKRs as output karaoke

Your team talks about outcomes, but what they’re really tracking is deliverables with deadlines.

The smell: “KR1: Release onboarding v2. KR2: Improve sign-up flow.”

Better question: “If we didn’t ship this, what goal would we fail to meet?”

3. Feature graveyard syndrome

You ship it, move on, and never ask if it worked.

The smell: “Didn’t we already build something for that?”

Better question: “What would we need to see before turning this off?”

4. Success theatre

Internal demos are full of applause. Every release ends in celebration. The metrics never move.

The smell: “Stakeholders loved the demo!”

Better question: “What can the customer do now that they couldn’t before, and that they actually care about?”

5. Product = Project

Ownership ends at delivery. Once it ships, it’s “done.”

The smell: “The onboarding squad handled that. We’re the payments team now.”

Better question: “What have we learned since this went live, and what should we do next based on that feedback?”

If you’re measuring effort instead of evidence, you’re not managing a product - you’re scheduling hope.

Why smart teams still slip into the factory

Most teams don’t choose this. They slip into it. Because the Feature Factory is the natural byproduct of three systemic failures:

1. You reward the wrong things

Teams are measured by what ships, not what changes. Throughput, predictability, hitting dates—these are easy to track and comfortable to report. Impact is slower and messier, so it gets skipped. When shipping becomes the proof of value, teams optimise for motion instead of meaning.

2. Your words hide the truth

We call everything a “feature.” We call roadmaps “strategy.” We call outputs “outcomes,” and nobody blinks. The language we use flattens the difference between effort and effect. When a launch becomes a “success” just because it shipped, you’ve lost the ability to tell the difference between delivery and delusion.

3. Everyone owns value, so nobody does

Product work becomes a negotiation between sales priorities, customer success fires, leadership optics, and tech debt. In that chaos, the actual customer gets diluted. When everyone has a stake in the roadmap, but no one owns the outcome, value becomes whatever doesn’t make anyone uncomfortable - which is usually nothing.

The courage problem

Here’s the uncomfortable truth:

Most teams in the Feature Factory know they’re in it, but lack the courage to admit it out loud.

Because admitting it means someone has to take responsibility. Someone has to say “we were wrong.” Someone has to kill their pet feature or tell leadership the roadmap is fiction.

So they keep performing. Keep shipping. Keep pretending that one more release will be the one that matters.

If that’s you, the escape plan below won’t help because you don’t have a process problem; you have a courage problem.

But if you’re ready to stop pretending?

Here’s how to start…

The escape plan

1. Redefine success beyond “Done”

Stop treating “shipped” as the finish line. Success is what’s different in the customer’s world.

Don’t ask: “Did we ship it?”

Ask: “What would success look like in 6 weeks, and how would we know?”

2. Add intent to your backlog

Every item should be a bet, not just a task.

Simple framing:

• Hypothesis: “We believe this will...”

• Signal: “We’ll know it worked when...”

• Impact: “It matters because...”

This doesn’t slow you down. It saves you from shipping features nobody needs.

3. Make feedback loops relentless

Don’t just instrument features, interpret them. Schedule return visits for what you’ve shipped; I’m not talking in six months, but in six weeks.

Ask regularly:

• What did we believe would happen?

• What actually happened?

• What will we change next?

4. Track Learning, Not Just Throughput

Look at how often you’re proven wrong, and what you do about it.

Ask:

• Which bets have we killed or reversed this quarter?

• Where did we change course based on what we learned?

If your roadmap never shifts and your backlog only grows, you’re not discovering, you’re just delivering.

The Choice

The real job of product isn’t to ship.

It’s to matter.

And mattering requires something most teams have forgotten how to do: treating features as bets, not obligations. Returning to the work to ask if it changed anything. Having the courage to stop, learn, and try again when the answer is no.

The Feature Factory is comfortable. It’s busy. The dashboards are more than likely green.

But comfort is fragility in disguise. And sooner or later, your customers will vote with their feet, and your executives will start asking harder questions.

So here’s my question:

Are you managing a product, or maintaining a conveyor belt?

Look at your last three releases. Can you name the customer behaviour that changed? Can you point to the outcome that shifted?

If you can’t, you know where to start.

Your Move

Pick one release from the last quarter. This week, schedule a 30-minute session with your team to answer these three questions:

1. What did we believe would happen when we shipped this?

2. What actually happened?

3. Based on what we learned, what should we do next—double down, iterate, or kill it?

If you can’t answer all three, you’re in the factory.

And if you are? You’re not alone. Hit reply and tell me which warning sign hit closest to home. I read every response.

Know someone stuck in the Feature Factory? Forward this to them. Sometimes we all need permission to admit what we already know.

Last week, I came across a LinkedIn post that had hundreds of likes and comments.

You’ve probably seen variations of it over the years.

The message went something like this:

“If your backlog is full of technical tasks, you’re not flowing value. Write better User Stories.

Put the technical tasks inside the story. Slice vertically.

Stick to INVEST.”

It was packaged with confidence, sprinkled with 20+ years of experience, and wrapped in that unmistakable “this is the way” tone that LinkedIn absolutely loves.

And as I scrolled through the applause in the comments, I felt that familiar little sting of déjà vu, because this advice keeps showing up again and again, yet most teams I meet still struggle with the exact same backlog mess.

Which raises the obvious question:

If the advice keeps circulating, why doesn’t the problem go away?

The story behind the story

A few years ago, I worked with a team whose backlog was exactly as described in the LinkedIn post.

Wall-to-wall tasks.

Everything was “Implement X,” “Add Y to the API,” “Refactor Z.”

Their metrics were nonsense.

Their cycle times were meaningless.

Their predictability was, or rather, wasn’t.

At first, I assumed the usual diagnosis: the team wasn’t writing “proper” User Stories.

But the more I looked, the stranger it felt.

These weren’t lazy developers.

They were thoughtful, sharp, and collaborative.

They wanted to deliver value.

So why were they producing a never-ending stream of technical slivers?

The conversation that changed everything

One afternoon, I asked the Product Manager a simple question: “What’s the actual thing you’re delivering? Not the task or the ticket. The thing that matters.”

She didn’t hesitate: “Oh, that’s the customer onboarding redesign. It’s one big piece. The dev tasks are just steps.”

There it was. The team wasn’t flowing stories; it was something bigger, something meaningful, but the workflow didn’t reflect it.

The value lived at the epic level, while the system forced them to behave at the story level.

The result?

• Fragmentation

• Endless tasks

• Fake granularity

• Zero flow

• Metrics that lied

• Prioritisation that made no sense

They weren’t doing anything wrong, but they were flowing work at the wrong level.

This is why the LinkedIn advice misses the point

The viral post assumes that “User Stories” are the atomic unit of value, and sometimes they are, but often, they are absolutely not.

Most modern product environments flow:

• Epics

• Capabilities

• Experiments

• Service improvements

• Outcome slices

The story is just scaffolding - a container for conversation - a tool for planning, and not the unit of value.

So when you try to force flow at the story level when the value sits higher up, you get exactly what that LinkedIn author was lamenting: a backlog full of technical tasks.

Not because teams are bad at slicing.

Not because they’re skipping INVEST.

Not because they’re “doing Agile wrong.”

But because the workflow is designed around the wrong thing. The real question is painfully simple

Before we fix backlogs, formats, slicing techniques, or where technical tasks “should” live, we need to ask:

At what level does value actually move through your system?

Whatever the answer is, epic, feature, capability, that’s the level you flow.

Everything else belongs _inside_ it, not alongside it, pretending to be independent work.

When you fix the level, everything clicks into place

Once a team flows value at the level where value really lives:

• Technical tasks stop flooding the backlog

• Flow metrics become useful

• WIP limits start working

• Predictability returns

• Work item age means something

• The team sees the “why,” not just the “how”

• Decisions get easier

And the backlog stops being a glorified to-do list and becomes a product tool again.

Case in point

That LinkedIn post meant well.

Lots of advice like it does.

But it keeps trying to repair story hygiene in a world where the story isn’t the problem.

The problem is the unit of value.

Get the level right, and the system breathes again.

Get it wrong, and you spend your days shuffling tasks instead of delivering value.

So if your backlog looks like a graveyard of technical chores, don’t start with story-writing workshops.

Start with the question the LinkedIn post forgot to ask:

What’s the actual slice of value you’re trying to move?

Find that, and the rest finally starts to make sense.

This piece started with a conversation I had in London this week. I was with my team, eating, joking, and drifting into that end-of-day honesty you only get when people genuinely like each other. We ended up talking about where our lives landed compared with what we imagined as kids, and what our Instagram feeds say about us now.

James, who wanted to be a Shaolin monk because of that old TV series Kane, is now 57 and being force-fed AI doomsday content. Mine, at 54, is mostly people cuddling cows… and Porsches. And with my son turning nine this week, when someone asked, “What advice would you give your kids if they wanted to do what you do?”, I was a little stumped for a few seconds (I am rarely stumped for long!)

That’s when it hit me: the lessons I’d want my son to know are the same lessons I wish someone had told me — the ones that stop you wasting years pretending you know the future, chasing the wrong goals, or mistaking movement for progress.

So here they are, the expensive and hard-won ones.

1. Value is unknowable upfront, and flow is what turns potential into reality

I wasted years trying to predict value before building anything: research, analysis, frameworks, canvas after canvas, all of it. And every time something flopped, I blamed myself.
The truth? Value is unknowable upfront, and every idea is just potential until it moves through the system and into a customer’s hands.

ProKanban defines flow as “the movement of potential value through a system.” That line changes everything. If work doesn’t flow, then no one learns. And if no one learns… nothing becomes valuable.

The job isn’t to “prioritise value”, but to create the conditions where value can move. You don’t reveal value through prediction; you reveal it through flow.

2. Most decisions are tea-without-milk decisions, so stop treating them like Earl Grey

In the UK, we drink a lot of tea, and, as it happens, it gives us the perfect metaphor for reversible vs. irreversible decisions.
Pour milk into Earl Grey, and it’s wrong? You’re starting over.
That’s a one-way door.
But most product decisions aren’t like that.
They’re tea-without-milk decisions; taste, adjust, revert.
I didn’t get this early on. I treated every decision like a milk-in-Earl-Grey disaster: high stakes, final, tense. The result was paralysis masquerading as diligence.
Most product decisions are reversible, and reversible decisions are where you learn.

Make cheap decisions, learn quickly, and reserve the expensive ones for when you actually have evidence.

3. The biggest risk isn’t slow delivery, it’s being wrong at scale

Early in my career, I worked on a project where we moved fast. Clean roadmap, smooth execution, weekly demos and stakeholders were thrilled.

We shipped the whole thing with high-fives all around, and customers quietly ignored it.
It wasn’t slow delivery that hurt us, but being wrong with confidence, and at scale.

Fast + wrong is far more dangerous than slow + right, and big batches hide wrongness, whereas flow exposes it early. Speed matters, but only after you’ve shrunk the blast radius of being wrong.

4. You don’t manage products, you manage learning

Ask early-career me what a PM “manages,” and I’d have said the backlog, the roadmap, and stakeholders, but none of that is the job — the job is managing the learning loop.

A product is a learning engine; a roadmap is a guess; discovery is calibration; and delivery is validation.

Once you see this, everything else clicks: small slices beat big plans, experiments beat opinions, behaviour beats narratives, flow beats heroics, and reversibility beats certainty.

The teams that learn fastest win — it will never be about the teams that ship the most.

5. Your organisation’s operating model beats your strategy every time

I used to think a great strategy could overcome anything — dependencies, politics, slow decision-making, unclear priorities — be damned, but strategy is only as good as the system it has to move through.

If decisions take weeks, that’s strategy.
If you rely on three teams you don’t control, that’s strategy.
If WIP is drowning everyone, that’s strategy.
If leadership changes direction monthly, that’s also strategy.

The operating model is the terrain, and your strategy is just the map; it just isn’t possible to drive a sports car through a swamp.

Once you see the system, you stop pushing harder and start fixing the environment instead.

6. Flow beats heroics, and it’s not even close

I spent years being the glue — chasing dependencies, filling gaps, soothing stakeholders.

It felt like competence, and people praised it, but the truth is, if the system only works because you’re holding it together, you’re not a hero, you’re a bottleneck.

Heroics are fragile, and flow is reliable.

Flow is built through small, unglamorous things:

• WIP control

• Small slices and right-sized work

• Clear ownership and boundaries

• Explicit and lived policies

• Visible blockers

Flow makes value move, and heroics just make people tired.

7. Backlogs rot, confidence decays, and most ideas die quietly

I used to treat the backlog like an archive, preserving everything important, but backlogs rot fast. Ideas have a shelf life and age out, context shifts, and assumptions expire.

A backlog isn’t a museum; it’s a compost heap. I still remember the first time I deleted 200 items in one go, my finger quivering over the Del key. Nobody noticed, nothing broke, and suddenly the real work surfaced.

Prune aggressively, and focus on the ideas you’re actually going to learn from. Delete the rest.

8. Behaviour tells the truth; everything else is noise

People say one thing and do another, not because they lie, but because they can’t predict their own future behaviour. There was a moment years ago when I finally stopped believing what customers said and started watching what they did. It was a feature customers insisted they wanted, and then never used. That was the switch for me.

Clicks. Drops. Repeats. Payments. Abandonment. Behaviour is the truth, and everything else is noise.

9. Confidence is a lagging indicator of evidence

I used to think confidence was about tone — be certain, be decisive, be strong. But real confidence is the residue of:

• Experiments

• Evidence

• Flow

• Feedback

• Outcomes

That’s when clarity arrives, trust shows up and when the performance stops.

Polish never built trust. Evidence did.

One Last Thing

If I handed this list to my younger self, he probably wouldn’t have listened. Some lessons only make sense after you’ve lived them, but maybe he’d have wasted less time pretending and more time learning.

And if my son ever chooses this path?

He’ll get the real version, the one I earned the hard way.

I’ve been thinking a lot lately about how fast the ground is moving under our feet.

Every week brings another AI announcement, another new capability, another moment that makes you stop and think, “How are we supposed to keep up?”

This piece is about that feeling, but also about what comes after it. It’s about a space I’ve started calling System 0: the thinking that happens outside us. And why, if we learn how to work with it, not against it, it might become our next superpower.

If you’ve ever felt both awe and exhaustion at the pace of change, this one’s for you.

OpenAI said this week that it’s plausible we’ll have an intern-level AI research assistant by next September and a fully fledged AI researcher by early 2028. That stopped me for a second. Not in fear, but in awe. Because honestly, I’m a fan. I work alongside AI every day, and when you treat it like a partner rather than a threat, it can be astonishingly good company.

But even for those of us who love this stuff, it’s hard not to feel the speed. Every week brings a new model (MiniMax M2, anyone?), a new plugin (Claude Code 2.0), and another breakthrough (“Solstice”, the latest US supercomputer). The irony is that the easier the tools get, the harder it becomes to keep up.

We were talking about it in our AI Discord channel yesterday at work, half fascinated, half frazzled, wondering how humans are supposed to stay in sync when progress keeps skipping steps. Someone joked that soon we’ll just think the work into existence through neurotransmitters. We all laughed, then paused, because really, does anything sound completely ridiculous anymore?

Lately, I’ve started thinking about this through the lens of System 1 and System 2, the fast and slow modes of thinking Daniel Kahneman described.

And it feels like we’ve entered something new: I’m calling it System 0, the thinking that happens outside us, aka machines anticipating what we’ll need before we’ve even had time to notice.

The human cost of acceleration

Let’s get real for a second, as my old colleague Josh used to say — that speed comes with a cost. Predictability breaks down, focus fractures, motivation wanes. If you’re like me, someone who’s always been proud of being a generalist, of connecting dots across ideas and domains, it’s kind of disheartening.

What used to feel like a superpower now feels like trying to catch snowflakes with your hands, and even when you do, they melt as more flutter in behind them. You can’t collect them, so you learn to appreciate the pattern while it lasts, the brief moment of clarity before the next flurry lands.

This isn’t about being anti-AI. I love what it can do, and even more what I can do with it!

But when everything is accelerating, tools, expectations, even our own curiosity, something gets lost in translation. The space to make sense of what’s happening. The space to decide why we’re doing it at all.

Designing for flow in a world of flux

At Thrivve, we’ve been having this conversation a lot, not about resisting change, but about learning how to stay human inside it, because when everything speeds up, the first thing that slips is sense-making.

Flow, for us, has never been about speed. It’s about rhythm — creating the conditions where people can still think, connect inputs to outcomes, and reflect on the best action given the context and almost even more importantly, timing.

When that rhythm disappears, you start paying flow debt. The system might look busy, but nobody’s really moving forward.

That’s why we talk about designing for human pace. Reducing cognitive load so people can focus on the right problems:

• Keeping feedback loops small enough that learning doesn’t get drowned out by noise.

• Making change absorbable.

• Not slowing innovation down, but building systems that help people keep up with it.

I saw one team do this brilliantly. Instead of launching another process overhaul, they picked one experiment: shorten retros from an hour to fifteen minutes and run them daily for a week. The change was tiny, but it created a rhythm; quick reflection, quick adjustment, no drama. Suddenly, improvement went from being a project to a habit. That’s what absorbable change looks like.

Humans are the constraint worth designing around.

We can’t outpace the machine, but we can create systems that let our best thinking: our curiosity, judgment, and empathy, actually show up.

Partnering with System 0

I’ve got to be honest — working with AI has made me rethink what good collaboration even looks like. It’s like pairing with someone who never sleeps and always has opinions I haven’t even had time to think about: brilliant, relentless, and occasionally overwhelming.

But the best results come when I slow it down, when I take a breath and ask why before what’s next. The goal isn’t to out-think it; it’s to frame the problem clearly enough that the machine amplifies intent, not noise. The more time I spend in that space, the more I realise our edge isn’t raw intelligence, but perspective.

Machines don’t care about context. They don’t feel timing, tone, or tension. They don’t sense the pause or hesitation in a conversation that changes everything.

That’s where the human advantage still lives, in the white space between the data points.

If we can learn to work with System 0, to combine its reach with our reflection, that’s where the next superpower lies, not in faster thinking, but in augmented understanding.

The more I work with System 0, the more I think it’s our next superpower, not because it replaces us, but because it reveals us. It pushes us to ask better questions, to articulate intent more clearly, to see patterns our own brains might miss. System 0 extends reach, but it’s still our responsibility to steer. That’s the partnership we need to master, not human versus machine, but human with machine, thinking together at the speed of context.

Staying human in the age of System 0

Maybe the real frontier isn’t artificial intelligence, but artificial awareness. System 0 can think about things, but only we can think through them. Only we can decide what should be built, not just what can be.

That’s where the human magic persists — in the pauses, the judgment calls, the messy meaning-making that turns movement into progress.

At Thrivve, we keep reminding ourselves: flow isn’t about speed; it’s about rhythm and intentionality.

The magic isn’t in keeping up; it’s in creating systems where being human still sets the tempo.

So maybe start small. Before your next meeting, pause for ten seconds and ask yourself: “What deserves my slow thinking here?” That moment of awareness, that tiny reclaiming of pace, is where the human magic begins.

As always, thanks for reading.

If you’ve felt both awe and exhaustion at the pace of change, you’re in good company, and maybe, right where the magic begins.

I spent this morning doing something I didn’t think I’d be doing a year ago: teaching an AI to forecast flow.

Specifically, I built two Claude Skills that let Claude run Monte Carlo simulations, the same kind we use in Thrivve Partners to answer those two evergreen questions:

1. When will we finish, given this number of work items?

2. How many work items will we finish by this date?

Claude can now answer both, using throughput data, simulation logic, and probabilistic reasoning, instantly and conversationally.

Why Build These Skills?

Every time I talk about probabilistic forecasting, I start from scratch. We review throughput history, confidence levels, percentiles, and sample sizes before running a simulation.

That’s fine when teaching, but inefficient when practising.

Claude Skills let me capture that logic once - defining how to interpret data, handle uncertainty, express confidence, and reuse it as a kind of embedded reasoning system. It’s the same principle we use in Kanban when we make our work policies explicit: we take something tacit and make it visible, consistent, and inspectable.

The Two Skills

1. “thrivve-mc-when” answers “When will we finish?”

2. “thrivve-mc-how-many” answers “How many will we finish by this date?”

Both use the same principles we teach in flow forecasting: simulate thousands of possible outcomes based on historical throughput, then use percentile-based confidence levels (50th, 70th, 85th, 95th, 99th) to describe likely completion ranges.

They don’t replace judgment; they reinforce it by making probabilistic reasoning repeatable and precise.

How It Works

A Claude Skill is a simple markdown file that defines behaviour, intent, and trigger phrases. When invoked, Claude knows what data to look for, how to reason about it, and how to explain the result.

Here’s a simple example:

The logic is the same as any Monte Carlo simulation you’d run in tools like ActionableAgile or FlowViz. The only difference is that now, it’s built into the conversation, available on demand, whenever you need it.

Why It Matters

In Kanban, we teach teams to make their policies explicit so the system behaves predictably. Claude Skills do the same for reasoning: they make the logic explicit, consistent, and testable.

It’s a small step toward encoding how flow thinks, not just how it measures.

And that opens some interesting doors: what if your AI assistant could sense WIP drift, spot SLE breaches, or help teams notice when flow predictability starts to wobble? We’re not far off.

What I Learned

Writing these Skills forced me to think carefully about how I teach forecasting. Every ambiguity I typically explain verbally - how many trials, how to handle zero-throughput days, what confidence actually means - had to be written down explicitly.

That’s the quiet power of this exercise: it exposes where your reasoning lives in instinct rather than design.

Validating Against ActionableAgile

Before trusting any AI-driven simulation, I wanted to validate it against the gold standard: ActionableAgile.

I ran the same throughput data and parameters through both the Claude Skill and ActionableAgile’s Monte Carlo engine; 10,000 trials, same input dates, same 104 work items, and the same level of confidence.

The results were remarkably close: Claude’s forecast at 85% confidence landed one day later than ActionableAgile’s.

That difference isn’t a modelling error, but normal variation.

Probabilistic forecasts are inherently uncertain, so a one or two-day difference between simulation runs is expected, even with identical inputs. The spread of outcomes, not a single date, is what matters.

Both tools tell the same story: 85% confidence that the work will be completed in roughly the same window, and that’s precisely what good probabilistic alignment looks like.

Try It Yourself

If you’d like to try these Skills yourself, they’re now available here: Thrivve-Partners / Claude-Skills-Forecasting

The repo includes both skills, along with usage examples and documentation.

Closing Thought

We’ve spent years helping humans learn to think probabilistically. Now, we can teach the tools we use to do the same.

Claude didn’t just learn Monte Carlo.

It learned how flow feels.

Goals point at the destination. Systems decide whether you ever move.

We love goals — stretch targets, OKRs, north stars, moonshots. They sound ambitious, inspiring, and just about concrete enough to make us feel in control. Leaders love them because they’re clear, directional, and make for great slides and even better all-hands speeches.

But goals only tell us where we want to go. Systems decide whether we ever get there.

And that’s why I have been pondering lately: if the way work moves through your team is the clearest reflection of your system, and systems shape success, why do so few teams treat system design as a first-class responsibility?

The seductive comfort of goals

Goals are tidy. Systems are messy.

A new target feels like progress, even if the underlying system hasn’t changed at all. Every quarter: new goals, same blockers, more “try harder” energy.

But you can’t motivate flow, or will a queue to shrink or a bottleneck to disappear, so setting a new OKR without changing your system is like expecting a motorway to handle twice the traffic without adding lanes. You’ve made the declaration, but the bottleneck still drives your reality.

We chase ambition because it feels controllable, inspiring, even, but systems are where ambition dies: in too much work, in queues, handoffs, dependencies, and all the invisible friction that optimism can’t fix.

Flow thinking flips the question: not “how do we reach the goal?”, but “how does work reach done?”

The messy reality of systems.

Systems don’t care about your intent, only your design.

Design isn’t about aesthetics, it’s about how work really moves. Every system already has one in its policies, limits, cadences, and invisible norms that shape what gets done and what quietly stalls.

When teams miss goals, it’s rarely because they didn’t try hard enough, but because the system pushed back in predictable ways: unclear workflow boundaries, vague rules of engagement, and little instrumentation to show where friction hides.

Flow metrics tell that story better than any retrospective:

• WIP only tells the truth if your Definition of Workflow is clear. When no one agrees on what “In Progress” actually means, your board is visualising confusion, neatly colour-coded though it may be.

• Work item age shows where things are quietly dying. It measures how long current work has been in the system. If something’s been “in progress” for weeks, it’s not flowing but turning effort into untested investment and invisible risk through a lack of feedback.

• Cycle time exposes drag. It reveals the time work spends waiting, blocked, or half-finished, and how smoothly (or not) it moves across the board. A two-day task that takes three weeks to complete isn’t a people problem. It’s a system problem.

• Throughput tells you how much actually gets out the door per unit of time. Not what you started or what you planned, but what you finished.

These aren’t vanity metrics; they’re your system’s vital signs, and when they look bad, it’s not because people failed, but because the system did.

I’ve seen teams hyper-focus their effort after missing a target, with more meetings, more tracking, more pressure, without it leading to better results; nothing changed except how tired everyone got. Ambition isn’t the enemy, but a system that can’t carry it, is.

Building systems that can handle ambition

Goals give direction. Systems make progress possible.

The best teams I’ve worked with don’t talk about working harder; they talk about working better through their systems. They know flow is the bedrock that makes every goal achievable.

Here’s what they do differently:

1. They make policies explicit.

Many teams can’t answer “How does something get started here?” without five different people giving five different answers. Healthy teams can.

I worked with a team recently who realised no one could say when a piece of work was officially “in progress.” Some counted it when they picked it up; others only after finishing their last task. That confusion meant they were committing too early and carrying more work than they thought. When they agreed on what “in progress” really meant and brought their WIP limits in line, their system WIP halved within a week, and cycle time soon followed.

Pull and exit criteria, the three levels of prioritisation (how teams decide what to finish, what to start next, and what to start later), blocker and expedite policies, and a shared Definition of Workflow are the guardrails that keep flow stable, predictable, and human.

2. They sense and steer in real time.

Healthy systems aren’t self-driving. The best teams don’t wait for the next retro cadence to roll around, but manage flow as it happens. If work item age or cycle time jumps on Tuesday, they’re talking about what to do about it in the flow check-in (standup).

One team I worked with started reviewing their ageing chart in their flow check-ins. In the first week, they spotted a story that had been stuck for 12 days and no one had touched. Five minutes of conversation later, they’d split it, unblocked it, and went on to deliver it that same afternoon.

Metrics aren’t just collected in dashboards; they’re part of how decisions get made. When an SLE trend drifts or a work item starts ageing out, the team acts. They adjust pull decisions based on real capacity and WIP signals, not wishful thinking.

It’s a daily practice of noticing, deciding, and intervening; tuning the system as it runs.

3. They create slack, not squeeze it out.

Slack isn’t wasted time; it’s breathing room, space for teams to swarm on blockers, test a new idea, or improve a policy before the next crisis.

The best teams protect that time the way a CFO protects cash reserves, because that’s what slack is: operational liquidity.

4. They improve continuously.

Great teams treat their system like a living thing, observing how it behaves, learning from its signals, and improving the conditions in which it lives. They don’t wait for permission or a quarterly review. When reality shifts, they adapt their workflow, update their policies, and evolve how they work together.

Continuous improvement isn’t a project, but the heartbeat of a healthy system.

Ambitious goals don’t build great systems.
Great systems make ambitious goals possible.

Before you dream bigger, fix your flow

When a team finally fixes its flow, something shifts. The noise quietens, decisions feel focused and easier, and work starts finishing faster. Not because people are trying harder, but because the system finally makes sense. That’s the point. You can’t improve what you can’t see, and you can’t design what you won’t confront.

Before you set the next stretch target, take a long, hard look at your flow.

Where does work actually wait or get stuck?
What decisions slow things down?
Who has to say yes before value moves forward?

Your goals will always be aspirational.

Your systems are operational.

Know the difference, because you don’t rise to the level of your goals. You flow to the level of your systems.

A roadmap looks like a plan, and that’s the trap.

In reality, it’s a bundle of promises in progress, and most of them are promises you can’t keep.

Every date, every feature, every milestone is another clause in a contract you’re almost guaranteed to break. And when those promises break, so does trust.

Roadmaps don’t prevent failure; they guarantee it. They soothe executives and calm customers. But beneath the polish, they set you up for disappointment.

If a roadmap still defines your product strategy, you’re not managing a product; you’re managing broken contracts.

Why we love promises in progress

Roadmaps survive because everyone wants to believe in them.

• Executives see dates and feel like they’ve bought certainty.

• Teams point at milestones and say, “See, we’re on track.”

• Customers anchor their hopes on delivery promises.

Roadmaps soothe. They sell. They simplify.

But every line on that roadmap is a fragile promise in progress. The future is uncertain, and yet the roadmap speaks in absolutes. That disconnect is why they so often collapse.

Six promises roadmaps break (and what to do instead)

1. The promise of certainty

“We know what we’ll build and when.”

You don’t, and the further into the future you go, the fuzzier it gets. Roadmaps cover this uncertainty with glossy slides and a confident narrative, but really, they set you up to fail.

Takeaway: The further out your roadmap goes, the more it belongs in the fiction aisle.

What to do instead: Replace dates with time horizons and confidence levels. For example:

• Now (0–3 months): Launch payments API, 80% confidence.

• Next (3–9 months): Explore loyalty features, 50% confidence.

• Later (9–18 months): Voice ordering, 20% confidence.

You’re still giving stakeholders a future view, but you’re being honest about what’s solid and what’s speculative.

A note on “no timelines at all”

Some argue that the answer is to strip time away completely, so no 0–3 month horizon, nothing. Just outcomes and sequencing. It sounds clean, but what I have learned is that in practice, it breaks down. Leaders need a sense of when bets are likely to play out, if only to coordinate budgets, dependencies, and expectations. The trick isn’t to erase time; it’s to be honest about it. Horizons are not deadlines. “Now (0–3 months, 80% confidence)” is radically different from “Feature X ships March 12th.” One pretends to know the future while the other admits uncertainty, while still showing focus.

2. The promise of priority

“This order reflects what matters most.”

In reality, sequencing is rarely rational. It’s political. The loudest client, the biggest contract, or the nearest quarter wins. Roadmaps camouflage bias under neat swimlanes.

Takeaway: The roadmap doesn’t prioritise work; it camouflages politics.

What to do instead: Frame work as investments, not queue positions. Instead of “Feature A in Q3, Feature B in Q4,” say:

“For the next 90 days, we’re investing in reducing cart abandonment by 15%. Here’s the first experiment we’ll try.”

That shifts the conversation from “when will we get Feature B?” to “are we solving the problem we said we would?”

3. The promise of strategy

“This roadmap is our strategy.”

It isn’t. Strategy is about managing uncertainty, placing bets, and deciding how much risk you’re willing to carry. A roadmap of features and dates is just a prettier Gantt chart.

Takeaway: A list of features isn’t a strategy. It’s a shopping list.

What to do instead: Write your strategy as a set of bets with expiry dates. For example:

“We’ll pursue mobile onboarding for two quarters. If churn doesn’t drop 20%, the bet expires and funds move elsewhere.”

This keeps strategy alive instead of ossifying it into a static document.

4. The promise of value

“We know this will be valuable for our customer.”

No, you don’t. Every roadmap item is an untested IOU disguised as a commitment. And the hidden cost isn’t just being wrong, it’s the opportunity cost of everything else you didn’t choose. Remember, a decision to work on one thing is an active decision not to work on something else.

Takeaway: Every roadmap item is an IOU for value you haven’t proven exists.

What to do instead: Stop treating items as guaranteed wins. Instead of “We will build this,” say:

“We believe this might create value. Here’s the smallest slice we’ll try to learn before we double down.”

Build in discovery, prototypes, and experiments that let you learn cheaply before you commit deeply.

5. The promise of outcomes

“This roadmap item will deliver the outcome we need.”

Even when roadmaps look outcome-focused, they often hide a bundle of untested assumptions collapsed into a single line item.

“Launch referral program → increase referrals → acquire customers → grow revenue.”

On paper, that’s an outcome. In practice, it’s four leaps of faith disguised as one deliverable. When you collapse them, you lose the ability to test and adjust along the way. You’re left with a binary result: did it work or not, without any insight into why.

This builds on the promise of value: even if the bet is valuable, you don’t yet know the pathway that creates it.

Takeaway: Roadmaps promise outcomes, but by collapsing assumptions, they stall learning.

What to do instead: Map assumptions explicitly as testable hypotheses. Show the chain: behaviour change, acquisition, retention, monetisation, and validate each link independently. A roadmap that exposes its assumptions isn’t weaker; it’s more powerful because it trades false certainty for faster learning.

6. The promise of done

“Once it ships, we’re successful.”

The roadmap milestone ticks over, the feature is released, and the slide turns green. It feels like victory. But “done” is a comforting illusion; it says nothing about whether the investment created impact.

In the cold light of day, delivery is just the receipt. The real question is whether the bet paid off.

Takeaway: “Done” is the easiest promise to keep and the most misleading one.

What to do instead: Replace “done” with success states. Instead of marking the work finished, measure the benefit created. Did churn drop? Did adoption rise? Did revenue move? Success isn’t shipping. Success is impact.

Show impact, not activity

One of the biggest traps with roadmaps is that they stop at “Done.” We celebrate shipping, we move cards across the board, we declare victory. But “Done” doesn’t mean the work created value, it just means it’s out the door.

As Roger Swannell argues in his work on Success State Roadmaps, the better question isn’t “Did we build it?” but “Is it succeeding?”

Instead of a “Done” column, imagine a “Success” column:

• Feature delivered → 20% of users engaged weekly (target: 50%)

• Experiment launched → Churn dropped 4% (target: 10%)

• New workflow added → Median task time reduced by 30% (target: 25%)

This simple shift reframes the roadmap from a bundle of promises about output to a living record of progress toward the outcomes we have defined as valuable for the customer and the business. It forces teams and leaders alike to see value not in what’s finished, but in what’s working.

Why this matters: “Done” is a comforting illusion. Success states tell the truth, and they qualify the benefit delivered by our investment in the cold light of day.

The true cost of broken promises

When roadmaps fail, and to be clear, they always do, the damage lingers.

• Trust evaporates: Stakeholders remember the promise, not the caveats. When the date slips, your credibility goes with it. And it’s funny that nobody remembers the nuance in the slide, but everyone remembers the date once it’s published.

• Discovery dies: Teams stop asking questions because the roadmap already has the answers. And when the promised results don’t materialise, discovery gets blamed as “wasted time.” The team loses authority to explore, when in fact, discovery was the only thing that could have saved them.

• Optionality burns: Early commitments shut down better paths that emerge later. As Teresa Torres reminds us, good product decisions are compare and contrast decisions, which means weighing multiple options side by side. But once a roadmap locks you in, those alternatives evaporate. You stop comparing; you just comply.

• Backlogs bloat: Every roadmap item becomes a zombie feature waiting to be justified. The backlog stops being a space for learning and becomes a mausoleum of broken promises. Instead of curating options, teams spend cycles defending artefacts no one will ever build, but no one dares to kill.

Features fade. Broken promises don’t.

And here’s the twist of the knife: every line on a roadmap is less about what you will build, and more about what you’ve silently killed. Roadmaps bury opportunity cost under the illusion of clarity.

Laddering it all up

Strip away the language and the glossy slides, and a roadmap isn’t a plan; it’s just a bundle of promises in progress, destined to break.

They promise certainty: “We know what we’ll build and when.” But the further out you look, the fuzzier it gets.

They promise priority: “This order reflects what matters most.” But sequencing is politics in disguise.

They promise strategy: “This roadmap is our strategy.” But a shopping list of features isn’t a strategy.

They promise value: “We know this will be valuable.” But every item is an IOU for unproven value, with hidden opportunity costs.

They promise outcomes: “This will deliver the result we need.” But bundled assumptions stall learning and leave you blind when things don’t work.

The way out isn’t to abandon planning. It’s to abandon the charade.

• Replace false certainty with horizons and confidence levels, so you don’t pretend to know the unknowable.

• Replace priority politics with investment framing, so trade-offs are explicit instead of buried.

• Replace shopping lists with bets and expiry dates, so opportunity cost doesn’t silently compound.

• Replace unproven value with cheap tests and slices.

• Replace binary outcomes with explicit assumption chains you can validate.

• Replace “Done” with success states, so you measure the benefit of the investment in the cold light of day.

This isn’t radical. It’s safer, saner, and more honest. It gives executives the visibility they crave without selling them contracts for failure.

The courage to break the contract

Here’s the truth: roadmaps survive because they meet an unspoken executive need for a “plan.” Not a strategy, not a set of bets, just the comfort of something that looks certain on a slide.

But safety today is fragility tomorrow. Every roadmap is a contract for failure, and every PM who draws one is complicit in the trust collapse that follows.

The stronger move is to pull back the curtain. Stand in front of your leadership and say:

“We don’t know exactly what we’ll ship in 12 months. And that’s a good thing. Instead, here are the bets we’re making, our confidence in them, and how we’ll adapt as we learn.”

That’s not weakness. That’s leadership.

Closing Thought

A roadmap looks like a plan.

In reality, it’s promises in progress, most of which you can’t keep.

Stop writing contracts for failure.

Start managing bets in progress.

Because the future isn’t a list of promises.

It’s a portfolio of bets waiting to be tested.

Flow fails quietly at first. Not because teams don’t care, but because they’re blocked from changing the system that surrounds them. Policies get locked in. Workflows become untouchable. And when someone asks, “Why are we doing it this way?”, the answer is, “Because that’s what I decided.”

This is Policy Lockdown, where decision-making drifts upward, improvement grinds to a halt, and autonomy dies behind a Jira status. It’s not always malicious. Often it’s just habit, hierarchy, or a misplaced sense of control. But it’s deadly all the same.

You can’t talk about pull systems, flow metrics, or continuous improvement if teams aren’t even allowed to change how they work. You’re not managing Flow, you’re simply enforcing stagnation.

And if that’s the system, don’t be surprised when it breaks.

What Flow actually needs

Before we talk about what’s broken, it’s worth grounding in what Flow requires:

• Pull-based systems, not push

• Low WIP to reduce context switching and drive throughput

• Collaborative ownership, not siloed roles

• Clear policies for intake, prioritisation, and completion

• Transparency around work status and delivery risk

• Feedback loops for continuous improvement

• Respect for data, especially around variability and predictability

What policy lockdown looks like

Here’s how “policy lockdown” shows up in the wild, and why it breaks Flow at the root:

• Work is pushed onto teams with no regard for capacity

• WIP limits are set high “to keep people busy,” not to finish faster

• Dev and QA remain siloed, with no shared ownership of outcomes

• SLEs are distorted into targets, then used to punish

• Data is dismissed: forecasting, Monte Carlo, and throughput are all seen as optional

• Reports are treated as compliance rituals, not learning tools

• Roles designed to improve Flow are blocked or dismissed

• Metrics are used to discipline, not to understand

It’s the opposite of a learning system. And worse, it pretends to be one.

The deeper problem: improvement is off-limits

At the heart of this is a mindset that says: “Improvement lives at the top.”

Teams are told they can’t change workflows, can’t question intake, and can’t adapt policies, even when the system is clearly broken. It’s inflexible and misinformed gatekeeping, plain and simple. It blocks learning, prevents local adaptation, and undermines everything that Flow is supposed to enable.

Flow only works if teams can adapt

If we want real flow, we have to stop locking teams out of their own improvement. Governance should guide, not dictate. If the people closest to the work can’t shape the system they operate in, then all the data, metrics, and cadences in the world won’t save you, you’ll just be measuring the speed of your own stagnation.

Because in the end, you can’t build a learning system by shutting down the people doing the learning.

You thought the hard part would be the ambiguity. The trade-offs. The messy decisions.

But no one warned you that the real weight would come from doing good product work in a place that doesn’t see it, or isn’t ready for it.

You show up with curiosity, clarity, and intent. You’re up for talking to users, mapping and challenging assumptions, and shaping the strategy. Instead, you find yourself stuck translating between teams that barely speak to each other. Soothing chaos. Coaching the basics. Fighting for space to think.

You didn’t fail the job. The job just wasn’t what they said it would be.

And yet you stay. Not for the frameworks, not for the glory, but because someone has to hold the line. Someone has to protect the conditions for good work, even when no one’s asking for it. Especially then.

This is about that work. The invisible labour. The quiet leadership. The product work behind the product work.

The Product Job You Didn’t Expect

I once worked with a CEO who, on my first day, pulled me into his office and pitched his top three feature ideas. The competitor had them. He’d made them better. He wanted them live yesterday. “Always be shipping”, after all.

When I suggested we experiment to see if our users actually wanted them, he cut me off. Told me to stick my experiments. Quoted Henry Ford and the faster horses. Then told me to get on with it.

I didn’t.

But I didn’t walk out either.

Instead, I stayed. Hired a researcher. Brought in a UX designer, and rolled up my sleeves alongside three product managers to make sense of a mess and unpick vague promises baked into decks and roadmaps without evidence. We rebuilt everything from scratch, grounded in real insight, not competitor mimicry or top-down assumption.

That wasn’t the job I thought I’d been hired to do. But it was the job that needed doing.

Joining a dysfunctional organisation as a product leader rarely looks like strategy work.

It looks like teaching agile 101, untangling myths, and pushing back against a culture obsessed with shipping over solving, and all the time, fighting the gravitational pull of output over outcomes. Sitting in rooms where shipping is the goal, not solving real problems, where features are plucked from thin air by sales teams and executives, guided more by gut feel than evidence, and the outcome isn’t resolution, it’s more complexity.

You didn’t fail the theory. The context failed the theory.

The courses you completed never prepared you for this. The books didn’t mention the part where you build a product culture before you ever build a product. But this, this mess, this misalignment, this long road back to clarity, is where the real work begins.

The Shift: Quiet, Invisible Leadership

At some point, you stop trying to win the argument.

You realise the work isn’t about getting buy-in for a new framework or proving how product should be done. It’s about slowly shifting the conditions so that better product decisions become possible, even if no one notices how it happened.

You stop preaching discovery. You just start doing it. Quietly.

You translate between sales and engineering. You sit in planning meetings and ask questions that change the shape of conversations. You protect space for a designer to think. You seed better habits in one team, knowing others might catch on.

You stop trying to control the roadmap and start listening for the real signals: the pain in support tickets, the pattern behind a sales objection, the opportunity hiding in an “edge case.”

It’s slow. It’s subtle. It’s rarely celebrated.

But over time, you see it: the team thinks more critically. Leaders ask better questions. Delivery feels less chaotic. And suddenly, you’re not the only one pulling for insight.

This is product leadership, not the title, but the practice. The quiet kind that builds a foundation without fanfare or theatre

It’s the kind of leadership that holds a system together while it learns to become something better.

And yet, sometimes even that isn’t enough.

I remember being pulled aside by a board member, same company, who told me I wasn’t doing a good job. I asked her why. Her answer has stayed with me ever since:

“Nothing you launch ever fails. That means you’re not pushing hard enough.”

She said it like it was a bad thing.

I told her: “My job is to make sure we don’t fail on launch. If I’m doing it well, we’re winning.”

She didn’t see it. She didn’t see the hours of shaping, testing, validating, and reworking that happened before anything ever shipped. To her, success looked like risk; splashy bets, big reveals. But good product work often looks like… nothing. Until it doesn’t.

That’s the risk of quiet leadership. When you do it well, it becomes invisible. And when it’s invisible, people forget it’s work.

Burnout and Invisible Labour

Burnout doesn’t come from being bad at the job. It comes from being alone in doing it well.

When your work is invisible, so is your effort. You can spend weeks nudging a team toward a breakthrough, quietly reshaping how decisions get made, and no one sees the lift. You protect people from chaos, but carry the friction yourself.

It’s not the frameworks that wear you down. It’s the resistance. The slowness. The constant translation between what’s needed and what’s possible. The weight of holding up a system that doesn’t yet know it needs holding.

This isn’t performance burnout. It’s cognitive and emotional labour, the kind that doesn’t go on your “Now, Next, Later” roadmaps or OKRs. You’re managing and grounding expectations, reframing failure as learning and opportunity, softening the blow to egos, and repairing trust. And you’re doing it all without authority, recognition, or even language for what it is.

You don’t need applause. But you do need oxygen.

And the hardest part? When you do this work well, when you really nail it, everything looks smooth on the surface. People assume it was always that way. That things just got better on their own.

So they give the credit to momentum. Or the roadmap. Or the new tool.

Not to the person who made the work work.

That’s what makes this labour so dangerous to ignore: it doesn’t ask for attention. But when it’s missing, the cracks start to show. And by the time people notice, it’s often because the person holding it all together has burned out or quietly left.

A Call to Recognition

If you have someone like this on your team, recognise them.

The person who asks the tricky question no one else saw coming. The one quietly stitching understanding between silos. The one who seems to “just know” what’s really blocking progress. They’re not lucky. They’re working harder than you think.

Don’t mistake calm for comfort. Don’t confuse subtlety with softness. And above all, don’t assume that just because something looks easy, it was.

These people are the quiet glue. They’re the ones shaping the environment while everyone else works inside it. The ones doing the product work behind the product work.

When they leave, and eventually, they do, the system doesn’t fall apart overnight. It just slowly gets heavier. Meetings get a little less clear. Decisions feel a little more rushed. Progress feels a little more fragile. And no one can quite explain why.

So if someone on your team is doing this kind of work, see them. Support them. Protect the space they’ve been quietly holding for everyone else.

What holds a team together isn’t always on the org chart. But it’s always worth noticing.

In closing

Sometimes, the work that matters most is the work no one sees.

And if you’re the one in the trenches, doing it, I see you. I know it’s an exhausting and largely thankless task, but it’s valuable, even when it doesn’t feel like it.

And if you’re lucky enough to have someone like that on your team, look again. They might not ask for recognition, but they deserve it.

“A bad system will beat a good person every time.”
W. Edwards Deming.

So build the system around them. Not after they leave. Now.

In most workplaces, the person who gets ahead isn’t the one who fills airtime, dazzles with detail, or drops the most acronyms.

It’s the one who says the thing that makes everyone else finally shut up and think:

Oh. That’s what we’re doing.

Clarity.

And not the polished, post-rationalised kind you get after two weeks of slides and seventeen versions of the plan. I mean real-time clarity. The kind that cuts through the noise when everyone’s busy being clever, cautious, or just plain confused.

That kind of clarity? Uncommon.

Not because people aren’t smart, but because they’ve been taught to add. More words, more detail, more data to cement the argument. More measurement is better, right? More options, more “just-in-case” thinking.

You’ve Probably Been Rewarded for the Wrong Things

Can we be honest with each other for a sec?

If you’ve ever been praised for your comprehensive stakeholder summary, your exhaustive roadmap, or your ability to please everyone without upsetting anyone…

Congratulations. You’ve been conditioned.

Conditioned to add, to hedge, to pad your language with just enough vagueness to stay safe. Conditioned to look like you’re adding value by making things more complicated.

But lately? That trick’s wearing thin.

I got feedback this week that stopped me cold:

“I don’t care about what you did. I want to know what’s next.”

It stung, but they were right. And they’re not alone. Most people are drowning in updates and starving for direction.

Clarity isn’t a recap. It’s a decision.

Not what we’ve done, but what we’re doing. Now.

The Burden of Being Smart

Let’s name another tradeoff no one talks about:

The pressure to always sound smart.

If you’ve ever sat in a room, virtual or otherwise, knowing someone has to say something insightful because the client’s waiting… you know the feeling.

Say nothing, and it looks like you’re not adding value.

Say something, and it better be clever, polished, and immediately actionable.

That pressure leads us to overcomplicate. To dress up the obvious. To drown our point in extras just to make it sound… smarter.

But clarity isn’t about looking clever.

It’s about having the nerve to say what’s already true, and then stop talking.

Clarity Is a Subtractive Act

You get to clarity the same way a sculptor gets to a statue:

By removing everything that isn’t it.

There’s a (possibly apocryphal) story about Michelangelo.

When asked how he created his sculpture of David, he supposedly said:

“I saw the angel in the marble and carved until I set him free.”

That’s clarity.

It’s not adding more. It’s seeing what matters inside the mess, and cutting everything else away.

It’s uncomfortable. Especially if your calendar is packed with meetings where “sounding smart” is the unofficial dress code.

But at some point, someone has to say it:

“Here’s the problem.

Here’s what we’re going to do.

Here’s why.

Everything else? Not now.”

That’s the leadership moment. Not when you’ve got perfect data, not when every voice has been heard.

Now.

Clarity doesn’t wait for consensus. It creates it.

The Real Skill? Making People Okay with Doing Less

This is the underrated bit.

The best leaders don’t just pick a direction.

They make people feel okay, even energised, about everything they’re choosing not to do.

They give people a way to think about tradeoffs. They explain what matters less, and why that’s not failure, it’s design.

That’s the bit most people miss. It’s not just deciding.

It’s framing the decision so others can follow it.

Steve Jobs once said:

“It’s only by saying no that you can concentrate on the things that are really important.”

“We’re always thinking about new markets we could enter, or new products we could build. But focusing is about saying no to good ideas too.”

It’s easy to say no to bad ideas.

The real skill? Saying no to great ones, because they’re not the right ones right now.

Clarity doesn’t just filter junk.

It forces you to choose what actually defines your focus.

Clarity Threatens People Who Trade in Ambiguity

Here’s the thing no one says:

Clarity isn’t just helpful. It’s threatening.

Because when you’re clear, really clear, you expose the people who rely on vagueness to survive.

• The leader (or dare I say, consultant) who hides behind “it depends.”

• The team that avoids accountability by keeping things fuzzy.

• The stakeholder who always wants more options but never wants to choose.

And sometimes, it gets personal.

I had a colleague once, sharp, principled, unafraid to call things what they were. During a tense meeting, he pointed out a “Death Star,” as he called it, a massive hidden plan being quietly shaped by an influential stakeholder behind the scenes. He wasn’t aggressive, just… clear.

He lost his job not long after.

Not because he was wrong. Because he made it impossible to keep pretending.

When you bring clarity, you cut through that fog, and not everyone thanks you for it.

Clarity isn’t just a spotlight. It’s a mirror.

And some people really don’t want to see themselves in it.

How to Practice It (Even in the Mess)

Try these. Especially when things feel a bit too noisy:

• Start with the actual problem.
  Most debates are symptoms fighting each other.

• Name what success looks like.
  Not the task. The change you want to see.

• Say what doesn’t matter (right now).
  Not as an apology. As a feature of focus.

• Draw a line and stand behind it.
  Yes, someone will be annoyed. That’s the point.

Clarity Doesn’t Mean Cutting the Soul Out

One thoughtful reader reminded me of something important:

“There’s real challenge in keeping the soul and vibrancy in something trimmed down. We can’t go so far that we communicate tersely or callously.”

They’re right.

Clarity isn’t about becoming robotic. It’s not permission to speak in executive summaries only, or to strip away all warmth, humour, or depth. It’s not about being terse; it’s about being true.

We still need stories. We still need energy. We still need to connect.

The art is in subtraction without losing the signal of humanity.

Clear and kind. Focused and vibrant. That’s the real work.

Final Thought

There’s always a moment when the chaos peaks, and everyone’s eyes start darting around, waiting (hoping) for someone to make it make sense.

Be that person.

Not with complexity. Not with cleverness. With clarity.

Because clarity is a decision, not a document.

It’s subtraction, not addition.

And it might just be the highest-leverage move you can make.

I’m always exploring how teams cut through ambiguity to deliver clarity. What has worked for you? Or what still feels messy? Drop your thoughts in the comments; I’d love to hear how you navigate it.

We got into it. Not hostile, just one of those conversations where the tension hums underneath. The client wanted to know why their new flow-based delivery setup couldn’t tell them exactly which stories would be in their next release. They had seen this done in Scrum; stories were tagged, sprints were committed to, and a nice board said, ‘These ones are going to get done.’

Now we were talking about Monte Carlo simulations, percentiles, and system-level forecasts. And they just weren’t buying it.

‘Why can’t Flow do what Scrum does?’

It’s a fair question. But it’s the wrong one.

Flow doesn’t exist to tell you what you want to hear. It exists to show you what’s actually happening.

The Illusion of Certainty

Scrum gives you something seductive: the sense that you know what’s going to happen.

The backlog is groomed, the sprint is planned, and the stories are all neatly tagged to a release. On paper, it looks like a plan. On a dashboard, it feels like control. Stakeholders nod, everyone breathes out, and delivery moves forward with a sense of direction.

But let’s be honest: that direction is often an illusion.

Work gets re-scoped. Dependencies explode. Stories roll over. Priorities shift mid-sprint. The board still says, “These stories are in this release,” but reality just shrugs.

The illusion works, right up to the point that it doesn’t. And when it breaks, we don’t question the setup. We blame the team, rework the backlog, and double down on ceremonies (because the 'non-event' language is prevalent in these situations). It’s control theatre, starring burndown charts and false confidence.

The real problem isn’t that Scrum teams are bad at delivery. It’s that the system encourages you to believe that certainty is the goal, and that commitments to specific items are how you get there.

Flow doesn’t play that game.

What Flow Actually Promises

Flow doesn’t promise certainty.

It promises clarity about your system, your risks, and your delivery capability. And that’s a very different offer.

In a flow system, we don’t pretend to know exactly which stories will get done by next Friday. What we do know, if we’re looking at the data honestly, is what our system has historically been able to handle. That’s what Monte Carlo gives us. It’s not a crystal ball, it’s a mirror:

"Based on what we’ve seen, here’s how many things you’re likely to get done in this time window.”

It’s a probability model built on throughput. It doesn’t care about your hopes, whether your story names have a verb in them, or your roadmap (cough...delivery plan). It doesn’t know, or pretend to know, whether you’ll do “Improve login UX” or “Refactor invoice engine” first. It just tells you how much, not which ones.

And if you haven’t prioritised anything? Then it really can’t tell you which ones, because the system has no opinion either.

When people say, “Monte Carlo can’t do what Scrum does,” they’re often confusing forecasting with selecting. Scrum only “knows” what’s getting done because someone manually declared it. Flow doesn’t do declarations. It reflects reality.

So yes, if you refuse to tag or prioritise work, you’re asking a probabilistic system to make deterministic promises based on a pile of unordered tickets.

That’s not how any of this works.

The Real Question

When someone says, “Why can’t Flow do what Scrum does?”, that’s not really a question about delivery practices. It’s a question about comfort.

They’re not frustrated that Monte Carlo doesn’t spit out a list of story IDs.

They’re frustrated that Flow won’t fake certainty when they haven’t made real decisions.

Because here’s the thing: if you won’t tag stories, if you don’t prioritise, if you can’t say what matters most, then you’re not asking for a forecast. You’re asking for a system that makes your decisions for you, but still lets you feel in control.

You want the computer to tell you what’s going to happen… without you having to be accountable for what should happen.

Scrum gave you the illusion that this was possible: a backlog, a sprint plan, a set of commitments, and a sense of direction. And if you’re lucky, or disciplined, or small enough, maybe it even worked. But most of the time, it was a soft promise built on shaky ground.

Flow just refuses to make the same promise. Not because it’s incapable, but because it’s honest.

It says:

“I’ll show you how your system behaves. But I won’t make up a future you haven’t earned.”

The real question isn’t “Why can’t flow do what Scrum does?”

It’s:

“Why are you still asking your delivery system to lie to you?”

A Better Way Forward

If what you actually want is confidence in your releases, then don’t reach for the comfort blanket of deterministic commitments. Build a system that earns your trust through clarity, adaptability, and real delivery data.

Here’s what that looks like:

• Prioritise with intent: If you care about certain stories that are making it in, tag them. Sequence them. Decide. Flow isn’t going to pull meaning from a backlog soup. If you want a meaningful forecast, start with meaningful input.

• Use Monte Carlo for scenarios, not promises: Ask, “What’s the likelihood of getting 8 out of these 12 done in the next 3 weeks?” Not “Will these exact 8 be done?” The model tells you what your system tends to do; it’s your job to decide which bets are worth making.

• Track actual progress, not planned intent: Use burnups, percentile charts, and throughput dashboards to monitor where things really are, not where you hoped they’d be. Make adjustments in the flow, not just at the end of a two-week cycle.

• Stop blaming the system for decisions you didn’t make: If you leave all work unprioritised, don’t be surprised when you can’t forecast specific outcomes. That’s not a flaw in flow, it’s a feature of reality.

This isn’t about Scrum vs Flow. It’s about choosing honesty over illusion. Control isn’t making the board look tidy. Control is knowing what your system can do, making hard choices early, and letting real data inform your next move.

In Closing

Flow doesn’t fail to give you what Scrum gave you.

It refuses to lie about what Scrum never really had.

We’ve been told the backlog is how we steer.

How we prioritise.

How we plan.

So we invest hours, maybe days, maintaining it:

• Refinement sessions

• Estimation rituals (battles?)

• Prioritisation debates

• Acceptance criteria roulette

There is an uncomfortable truth lurking here:

Most backlog management isn’t strategic. It’s organisational procrastination.

It feels like control.

But it’s actually delay dressed up in process.

This post is a call to rethink the backlog.

To see it not as your product’s brain…

… and start seeing it for what it really is:

A storage unit, full of maybes, misfires, promises in progress and huge mental overhead.

Quick Note:
A healthy backlog isn’t a graveyard, it’s a living, dynamic option set.
The real purpose of a backlog is to hold actionable, validated options for near-term delivery, not to archive every idea that’s ever been mentioned.
When managed well, a backlog fuels timely decision-making, sharpens strategic focus, and supports the flow of value to customers.

This post is about what happens when backlogs stray from that purpose, and how we can bring them back to life.

1. The False Sense of Control

A neat backlog gives the illusion that we’re managing the work.

It looks sorted, stack-ranked, and ready to go.

That insight from the sales team from last week? It’s in there, ready to help them close that deal. The CIO’s new big idea? Same. Captured. Broken down. Refined. Ready to go.

But here’s the problem:

It’s just a long list of possible maybees. Potentially valuable, but not a strategy.

We aren’t actually reducing risk.

At best, we’re organising it.

At worst, we’re just shuffling it around.

Backlog refinement feels productive, collaborative and reassuring.

But clarity isn’t the same as progress.

And while the team tidies, the world moves on.

The longer something sits in the backlog, the more stale it becomes.

You’re not refining.

You’re refrigerating.

And sooner or later, that work will rot.

2. WIP by Proxy

Backlogs don’t just hold ideas.
They hold psychological WIP; every item on the list is something your team thinks they might have to do.

That’s cognitive load.

The kind that sits quietly in the background, eating up the team’s decision-making energy.
And cognitive load drains focus.

Every “not now” is still a mental “maybe later.”
And “maybe laters” pile up until your team’s sense of focus collapses.

You’re not managing scope. You’re managing speculation.
And that speculation clutters decision-making when it matters most.

3. Prioritisation Theatre

Here’s the killer…

We spend hours deciding where a “maybe” sits on a list of “maybes”.

Backlog refinement often turns into a performance of prioritisation, where we carefully rank:

• Items no one understands yet

• Features without a customer need or a qualified business value

• Work that might never ship

• New items against those so stale no one even remembers what they meant, or why they mattered

All ranked neatly against each other, as if that makes it valuable.

But here’s the truth:

You don’t need to prioritise things you’re not going to build.

But prioritisation only matters when you’re actually going to do the work.
Everything else?

It’s debate for the illusion of control.

You don’t need to prioritise it.

4. Signal Decay

The older an item gets, the less relevant it becomes.

That “brilliant idea” from seven months ago?
The customer context has changed.
The business has shifted.
The insight has aged out of all usefulness.

But the backlog doesn’t know that.
It just holds the item. Quietly. Like an idea graveyard.

So often, backlogs become monuments to:

• Old promises made

• Political compromises struck

• Ideas long past their use-by date

And zombie items?

They come back to life, not because they’re right, but because they’re still there.

5. Strategic Drift

A healthy backlog reflects current intent.
A bloated one reflects past optimism.

When you hold onto too many stale items, your backlog stops being a tool for focus and becomes a list of what you used to care about, not what matters now.

The backlog becomes a lagging indicator:

• Of strategies never executed,

• Of assumptions never validated

• Of priorities already surpassed by new learning (hopefully)

Not a tool for steering, but a record of inertia.

And that disconnect?

It quietly misaligns and undermines your team, your focus, and your outcomes.

A Better Approach

If you stop treating the backlog like a to-do list, you can start treating it like what it really is:

A set of options. Not obligations.

That mindset shift is everything.

It means:

• You don’t need to keep everything

• You don’t need to rank everything

• You shouldn’t feel guilty about deleting old ideas

Because ideas aren’t valuable by default.

They are valuable when they are timely, validated, and actionable, and when they lead to outcomes that the user and the business care about.

So what do you do instead?

• Use expiry dates. If you haven’t touched an item in 90 days, ask why it’s still there.

• Practice backlog amnesty. Every quarter, clean house. Let go of work you’re not going to start soon.

• Prioritise only what’s real. Spend your decision-making energy where it counts: the next batch of work, not the fantasy road ahead.

My Answer: The Backlog Funeral

Want to make this shift stick?

Hold a backlog funeral:

• Once a quarter, gather the team.

• Delete anything untouched in 90 days. No debates. No defences. Just a ceremonial goodbye.

• Celebrate it.

Because every item you delete isn’t wasted effort,

it’s reclaimed focus.

You don’t need a roadmap full of ghosts and ghouls.

You need a system that helps you choose what matters now, not someday.

Final Thought

Backlog management isn’t strategy.

It’s often just highly structured procrastination.

What matters isn’t how many items you’ve groomed, it’s:

• How clearly you choose

• How quickly you learn, and

• How lightly your system carries what comes next

So, if your backlog feels out of control?

Don’t refine harder.

Cut deeper. Choose sooner. Learn faster.

That’s real backlog management.

With over two decades of experience, I’m here to tell you this:

Contrary to what you may have heard — or even said — Agile didn’t fail us.

It just never taught us how to manage flow.

Your team might have stand-ups, retros, and a nicely colour-coded board. But the work, the actual search for value, still crawls. Deadlines slip. Estimates? Guesstimates, more like, and that extra time you spent making them precise? Probably more waste than accuracy.

People are busy. But nothing’s really getting done.

Sound familiar?

Here’s the uncomfortable truth:

If you’re not managing flow, you’re not managing delivery.

You’re just organising the chaos — and calling it Agile.

Rituals Don’t Fix Systems

Agile made a promise: better collaboration, faster delivery, happier teams.

And what did most organisations do?

They ran headfirst into rituals.

Stand-ups, retros, backlog grooming.

Sprints, planning poker, story points.

Process everywhere. Flow? Not so much.

You can run the Agile playbook to perfection and still have work aging silently in progress.

You can have teams “fully utilised” and still have stakeholders breathing down your neck asking where the outcomes are.

Why?

Because ceremony without systems thinking is just theatre.

Agile rituals can help — but only if they’re in service of a system that flows.

And most teams? They’re managing the people, not the work.

They’re optimising meetings, not movement.

They’ve turned “doing Agile” into a checklist — and flow, if they’re even aware of it, into an afterthought.

Here’s the reality I see again and again:

• Stand-ups don’t fix stuck or ageing work — they’re often just a futile exercise in holding people accountable for being busy.

• Retros don’t reduce cycle time — mostly because teams spend their time explaining which movie character they felt like during the sprint instead of examining the data their process is already generating that could actually help them address the issue.

• Sprint planning doesn’t forecast delivery risk — it just locks in a plan nobody truly believes.

And the kicker?

They were never meant to.

Agile rituals give structure to a process.

But if your underlying system is bloated, overloaded, or opaque?

You’re just painting a house where the basement is full of water.

What Flow Actually Means (And Why It’s Not a Buzzword)

Flow isn’t about being “in the zone.”

It’s not a vague feeling of momentum. It’s not just moving work across a board.

Flow is the movement of potentially valuable work through a system — from idea to reality — in a way that’s visible, trackable, and improvable.

Let’s pause on that for a second:

Potentially valuable.

Because the truth is, most of what we deliver is based on assumptions.

We think it will help.

We hope it will resolve a problem, fulfil a desire, or meet a need, whether expressed or otherwise.

But until someone on the receiving end of the work tells us, “Yes, this helped” (or, more often, “No, not really”) — value is unconfirmed. Hypothetical. A bet.

That’s why flow matters. Because if your work isn’t moving, the system can’t generate feedback.

Without feedback, you’re not validating value — you’re assuming it. You might be right. But you’ll have no way to know, no way to repeat it, and no way to improve on it.

So, if flow is the system, what do we measure to understand it?

Not burndowns. Not points. Not how “busy” everyone looks.

You measure what actually moves. You measure how long it takes.

You measure whether things are finishing, not just starting.

Here are the four essential flow metrics:

1. Work In Progress (WIP)

How many things are we trying to do at once?

WIP is your system’s load. Let it climb, and responsiveness tanks. Let it stay high, and you’ll wonder why everything feels slow — all the time.

2. Work Item Age

How long has each work item been in progress?

Old work is risky work. The longer something hangs around, the more likely it’s stalled, stuck, or out of sync with what’s needed now.

3. Throughput

How much work do we finish per time unit?

Not started — finished. Throughput gives you your actual pace. It’s the only stable ground for any forecast that deserves to be trusted.

4. Cycle Time

How long does it take to finish something once we start it?

This is how responsive your system really is — not how long people are working, but how fast value (or potential value) gets to someone who can tell you if it mattered.

Flow ≠ Efficiency. Flow = Feedback.

Teams obsessed with efficiency can burn months delivering something fast that nobody needed.

Teams who manage flow create learning loops — systems that help them find out faster whether they’re delivering something that matters.

Here’s the truth:

If your work isn’t moving, it’s not generating feedback.

And if you’re not getting feedback, you’re not validating value — you’re assuming it.

Sure, you might get lucky.

Your solution might be right.

But without feedback, you won’t know how right or wrong it is or how to do better next time.

And if you can’t tell the difference, you’re not managing value — you’re just hoping for it.

If ROI Is Unknowable, Manage the Investment

ROI looks great on a slide. But in the real world?

You can’t measure return on work that hasn’t landed, been used, or been fed back on.

Value is emergent. ROI is hindsight.

So, what can you control?

Not the return.

The investment — and how long you’re exposed to risk.

And that investment?

It’s not just budget.

It’s not just effort.

It’s time.

More specifically, Cycle Time.

Cycle time is your Time to Feedback.

The longer it is, the more you’re spending without learning.

If you can’t confidently measure value upfront, then shorten the distance between idea and evidence.

Because the only thing worse than being wrong…is being wrong slowly.

“In the absence of knowable ROI, cycle time is your risk exposure.”

The Flow Frictions Killing Your Delivery (and How to Spot Them)

If you’re not actively managing flow, then friction is managing it for you — quietly, constantly, and at a high cost.

Most delivery dysfunction isn’t dramatic. It’s not the Big Red Project That Failed.

It’s the slow rot of unseen blockers, oversized work, and overloaded systems.

Here are the non-obvious flow killers I see every week — and how to spot them before they bury your roadmap.

1. Work That’s Too Big to Flow

“We’ll just finish it next sprint.”

Except you won’t. Because it’s not sized to finish.

When work items are too big, three things happen:

1. You can’t see progress until it’s almost done.

2. You can’t forecast anything except disappointment.

3. And worst of all? The world moves on.

The customer’s need evolves. The context shifts.

By the time the work is done, it is either partially abandoned, no longer relevant, or shaped for a version of the problem that no longer exists.

Watch for:

• Stories or tickets that span multiple sprints.

• Epics that have not been closed in 3+ months.

• Anything labelled “spike” that never got smaller.

Fix it:

Right-size the work. If an item can’t be reasonably expected to finish soon, it doesn’t belong in progress.

That’s not discipline — that’s flow hygiene.

Right-sizing isn’t about breaking everything into crumbs.

It’s about shaping work so it can flow, not fester.

You’re not trying to make everything tiny.

You’re trying to make everything finishable — fast enough to learn, early enough to adjust, and small enough to forecast.

2. WIP-in-Disguise

Not all flow problems are immediately apparent.

Some hide behind a well-meaning structure.

You’ve split the epic. You’ve created stories. You’ve sliced “small.”

But somehow, it still takes forever.

Why?

Because that so-called story still carries the full weight of the epic.

It’s not independently testable, releasable, or even understandable on its own.

It’s WIP-in-Disguise — and it’s one of the sneakiest forms of hidden overload.

Symptoms of WIP-in-Disguise:

• Stories that reference each other to make sense.

• Stories that all have to ship together to be useful.

• A single story taking multiple people across multiple sprints to finish.

Fix it:

Treat independently valuable as your definition of right-sized.

If it can’t move, test, or finish on its own, it’s still too big, no matter how small the card looks on the board.

3. WIP Is Out of Control

“We’ve got ten things in motion — we’re really productive!”

No, you’re just busy.

High WIP means everything slows down, feedback loops stretch, and priorities blur. It’s delivery traffic, and nobody’s getting anywhere fast.

Watch for:

• More cards in progress than team members.

• Boards with “In Progress” columns 3x longer than “Done.”

• Frequent context-switching in standups.

Fix it:

Set a WIP limit. Then, actually honour it.

Yes, it will feel uncomfortable.

Yes, it will surface difficult choices.

That’s the point.

WIP limits aren’t about starving teams of work — they’re about protecting flow and forcing focus over false productivity.

When you constrain WIP:

• Work finishes faster.

• Blockers surface sooner.

• Priorities stop colliding in midair.

WIP limits aren’t a constraint.

They’re a signal that you’ve stopped saying yes to everything — and started designing for flow.

4. Work Isn’t Prioritised Once It’s In

“It’s all priority one.”

Then nothing is.

Most teams prioritise at intake — and then never again. Once work is “in progress,” it’s out of sight, out of mind. However, in a flow system, prioritisation is ongoing. Every day, you’re making decisions about what to finish next, and those decisions shape everything from risk to trust.

The result of not managing this?

• Old items linger while shiny new ones leapfrog.

• Critical work silently ages.

• The system stalls, even when people are “busy.”

Fix it:

• Create a clear pull policy.

• Visualise work item age.

• Prioritise flow, not just backlog order.

And when in doubt?

If all else is equal — pull the oldest item first.

Because work that waits silently isn’t harmless.

It’s hiding risk, delay, and decay.

5. Blockers Are Normalised

“Yeah, that’s always waiting on legal/data/another team.”

Cool. So you’ve accepted that your system’s broken.

Blockers should be treated like fire alarms, not background noise. If work is blocked, the system has failed to support flow. And the system is yours to improve.

Watch for:

• Blockers that last longer than active work.

• A “blocked” column that’s basically permanent.

• Silence around systemic delays.

Fix it:

Don’t track blockers. Investigate them. Cluster them. Fix the top 3 repeat offenders, and watch your flow improve overnight.

6. Expedites Run the Show

“This has to go through. It’s a special case.”

Of course it is. So were the last four.

Expedites are the sugar rush of delivery: instant gratification, long-term damage. They trash predictability, consume slack, and leave everything else in a pile of flow debt.

Watch for:

• Repeated “just this once” exceptions.

• Work items that skip the process entirely.

• Teams quietly resentful about getting pre-empted — again.

Fix it:

Limit your expedite lane. Make it visible. Control it with policies.

• Set a hard WIP limit: even if that limit is one.

• Define clear entry criteria: what really qualifies as an expedite?

• Track the frequency: if you’re expediting weekly, it’s not an exception, it’s a process failure.

And most importantly: make the cost of expediting visible.

Every expedite delays something else.

So treat them like credit cards — you can use them, but you will pay them off.

If you want flow, you can’t let urgency run the system.

Expedites should be rare, deliberate, and slightly painful — that’s how you know they’re being used responsibly.

And ask the question no one wants to: What are we doing wrong that makes so many things urgent?

Flow frictions are everywhere. Most teams normalize them.

The best teams expose them — then design them out of the system.

Agile Without Flow Is a Dangerous Game

You can follow Agile by the book and still fly straight into a wall.
Because Agile gives you structure, flow gives you feedback.

Here’s what Agile doesn’t tell you:

• How many things are too many.

• How long things should take.

• What “done” really costs when work gets stuck.

• Why everything feels urgent, but nothing feels predictable.

Agile frameworks are deliberately lightweight. That’s not the problem — the problem is how teams fill in the blanks. Most organisations respond to delivery pain by tightening the rituals, not fixing the system.

What you end up with is this:

• Teams perfectly executing a broken process.

• Backlogs full of wishful thinking, not right-sized work.

• Roadmaps driven by belief, not evidence.

• Metrics that look good until the product fails to land.

And because it’s “Agile,” no one challenges it.

Let’s Be Blunt:

Agile without flow is just busyness in a hoodie.

If you don’t manage:

• Work item age, you won’t know what’s stale.

• Cycle time, you won’t know what’s slow.

• Throughput, you can’t forecast anything.

• WIP, you’re drowning in your own multitasking.

Agile can help you organise your process.
But only flow tells you how well it’s working — and how to improve it.

Agile’s not bad. But it’s incomplete.

And until you see your delivery system as a flow system, you’ll keep tripping over the same hidden failures, no matter how many sprint ceremonies you run.

What Flow-Led Delivery Actually Looks Like

So what does it look like when teams do manage flow?

Not perfectly — that’s not the goal.

But deliberately. Visibly. Systematically.

These aren’t magical unicorn teams. They’re just doing something most teams don’t: they manage the work, not just the workers. They treat delivery like a system — one they can shape, study, and improve.

Here’s what you’ll see when flow leads:

1. Work is Right-Sized to Finish, Not Just to Start

They don’t pull work because it fits nicely in the backlog. They pull work because it’s shaped to flow.

Ask yourself: Can this item be finished in a few days, not weeks?

If not, what’s stopping us from slicing it smaller?

Because “in progress” isn’t progress if it never gets done.

2. WIP Is Capped — and That Cap Hurts

Flow-led teams say no to starting something new, even when someone’s free.

Why? Because they know finishing is the goal. Not starting. Not appearing busy.

They limit WIP because:

• It shortens feedback loops.

• It exposes blockers fast.

• It forces prioritisation, not wishful multitasking.

They don’t feel efficient all the time. But they are.

3. Flow Metrics Used Every Day

Not just in a report. Not just once a quarter.

Every. Single. Day.

• If work item age is climbing, swarm.

• If WIP is up, pause intake.

• If throughput drops, investigate the system, not the people.

Successful teams treat these numbers like vital signs, not performance scores.

4. Forecasting Is Probabilistic, Not Political

No one’s promising “done by Friday.”

Instead, they’re saying:

“There’s an 85% chance this batch will finish by the 24th, based on the last 60 days of real delivery.”

And guess what?

Stakeholders trust it.

Because it’s based on evidence, not optimism.

5. Blockers Are Diagnosed, Not Tolerated

Flow-led teams don’t shrug at blockers.

They surface, study, and solve them at the system level.

They ask:

• Is this a repeat pattern?

• What team or function do we need to enable, not blame?

• Could we redesign the work to avoid this altogether?

Because every blocker is a chance to build a better system.

6. They Don’t Worship the Roadmap — They Manage Flow to Outcomes

They’re not shipping features to say they shipped.

They’re shipping to learn what works. To deliver value. To change outcomes.

And they understand that to get there, they need a delivery system that:

• Finishes what it starts

• Surfaces risks early

• Builds trust through evidence

Bottom line:

• Agile is about what the team does.

• Flow is about what the system enables.

And when you manage the system, the team starts to thrive.

Sidebar: Flow Isn’t Extra Work — It Is the Work

Managing flow isn’t overhead. It’s not a nice-to-have. It’s not something you tack on after the “real work” gets done.

Flow is the system doing the work, or preventing it.

If you’re not managing flow, you’re managing chaos.

And chaos doesn’t scale. It burns out teams, blindsides leaders, and buries outcomes.

Want predictability?

Want trust?

Want speed that lasts?

Start with flow.

The Shift That Changes Everything

You don’t need to throw out Agile.

But you do need to stop mistaking structure for system health.

Because until you manage flow, you’re just running delivery theatre — busy, expensive, unsatisfying theatre. And your audience (stakeholders, customers, teams) can feel it.

The shift is simple, but powerful.

Stop asking:

• Are we doing Agile right?

Start asking:

• Is value flowing?

Because when you focus on flow:

• Delivery gets faster, but also safer.

• Forecasts become useful, not political.

• Teams stop firefighting — and start finishing.

• Leaders get signal, not noise.

• The product improves because feedback is real-time, not postmortem.

This Isn’t About Doing More. It’s About Seeing Differently.

Flow isn’t just a metric layer. It’s a mindset.

One that stops blaming the team and starts tuning the system.

One that doesn’t settle for “busy” — it demands value.

And once you see delivery this way, you don’t unsee it.

Final Thought:

• Agile helps you organise your team.

• Flow helps you deliver your product.

So, if everything still feels broken, don’t double down on rituals.

Look at how work moves. And fix that.

Because, in the end, it’s the system that delivers the work.

If you’ve felt this pain — I’d love to hear how you’ve tackled it. Drop a comment or connect.

Your team just shipped a feature. The dashboards light up. Engagement is up 12%. Slack is buzzing with 🎉 emojis. Leadership calls it a win.

But what if I told you that success is an illusion designed to keep everyone feeling good about their bets?

Because most product teams stop thinking (and learning) too soon, and that’s why their biggest wins turn into slow-moving failures.

Here’s how success is defined in most product teams:

Ship the feature → Watch the first wave of metrics → Declare victory → Return to cranking out the roadmap.

But an uncomfortable truth lurks here: short-term engagement means nothing if the long-term impact is flat or negative.

Some “wins” are just delayed failures – initially look good but quietly unravel over time.

• You make checkout frictionless, but fraud skyrockets.

• You add more push notifications, but uninstalls surge.

• Your A/B test boosts conversions, but erodes brand trust.

But no one is paying attention anymore by the time these problems surface. The roadmap has moved on, and the focus with it.

The feature is someone else’s problem now.

• Ops? They’re firefighting unexpected bugs.

• Growth? They’re scrambling to figure out why churn just spiked.

• Marketing? They’re realizing no one actually cares about this feature.

• Sales? They’re praying the contract they just closed doesn’t come back to haunt them.

And Product? They’re already onto the next roadmap milestone, convinced they ‘delivered value.’

The real question isn’t ‘Did it work on launch?’ It’s ‘Will it still be working six months from now?’

Most teams never stop to ask that question. And that’s why they keep making the same mistakes — over and over again.

Why Product Teams Keep Declaring Victory Too Soon (And Pay for It Later)

Why does this keep happening? Because everything about how we measure product success is front-loaded. Teams obsess over dashboards the first few days after launch, checking engagement metrics like it’s the stock market. Clicks, signups, activations – all climbing. The team celebrates. The feature is a success.

But here’s the catch: no one (dares?) does a six-month retro on whether the “win” actually lasted.

The business rewards short-term impact. Leadership wants immediate proof that the roadmap is delivering. PMs are incentivized to hit release goals and not to check back later. Even teams that talk about outcomes often measure them too early, before the full effect of a change is felt.

The result? A cycle of false positives.

• Checkout friction drops → Fraud skyrockets.

• Push notifications increase engagement → Uninstalls surge.

• A/B test “wins” → Trust erodes over time.

The wrong lesson gets learned. A feature that works briefly is treated as a long-term success. And the team moves on before they can see the real impact unfold.

Success Isn’t What Happens on Launch Day — It’s What Happens Next

Every launch follows the same three phases:

• Phase 1: The Immediate Spike (Success Theater): The feature goes live. There’s an engagement bump. Leadership nods approvingly. Teams celebrate. The roadmap moves on.

• Phase 2: The Ripple Effects (Unintended Consequences): Real impact starts emerging – but no one is watching. Maybe it works. Maybe it backfires. Perhaps the benefit is smaller than expected. But the team is already heads-down on the next feature.

• Phase 3: The Plateau or Decline (The Real Outcome): The engagement spike fades. Users adapt. Some stick. Some churn. The long-term effects settle in. But by this point, the feature is there for good (and bad).

Most teams never make it past Phase 1. They track launch metrics, see the early engagement, and assume the feature worked. But actual outcomes aren’t what happens in the first week – they’re what happens six months later.

If you’re only measuring success in Phase 1, you’re not measuring success at all.

What If the Data Is Lying? Why Teams Must Have a Narrative, Not Just Metrics

Teams love to talk about data-driven decisions — I have written about this in Why Data-Driven Product Management Might Be Holding You Back. But here’s the uncomfortable truth: data doesn’t tell the whole story — people do.

Numbers aren’t neutral. They’re shaped by what we choose to measure, when we decide to measure it, and how we interpret the results.

And here’s how teams get it wrong:

• A feature “wins” an A/B test, so the team assumes it was a success — without checking whether long-term retention drops.

• Engagement spikes after a launch, so they celebrate — without realising it’s just a novelty effect that fades within weeks.

• A feature drives revenue, so leadership declares victory — without seeing customer churn increase simultaneously.

It’s not that teams ignore reality; we’re wired to see the positive first. The human brain is pre-programmed to seek validation and confirm success. Once we’ve put effort into something, our instincts tell us to look for proof that it worked.

The solution? Tie data to a story.

A single metric never tells the whole picture. The best teams don’t just look at numbers — they build a product narrative and test whether the numbers support or challenge it.

Ask:

• What is the whole user journey? What happens before, during, and after a feature gets used?

• Does the data match actual customer behaviour? Or are we just looking at surface-level trends?

• Are we measuring trade-offs? What are we giving up to gain this result?

Data can justify anything if you don’t ask the right questions, and if you’re only looking for what proves you’re right, you’ll never see the thing that tells you you’re wrong (hello, confirmation bias, my old friend).

The Myth of One-Way Doors: How Fear of Reversing Decisions Kills Learning

Most teams treat launches like one-way doors — once a feature is live, it stays live. No one wants to be the person who suggests rolling back a “successful” release.

But treating every feature as a permanent addition is a trap. It kills learning. It locks teams into early assumptions and makes adapting harder when reality proves them wrong.

The best product teams? They design reversibility into their launches by asking:

• If success is uncertain, how do we make this opt-in instead of default?

• Can we roll this back easily if we get unexpected adverse effects?

• Are we treating this as an experiment or as an irreversible commitment?

What is the difference between a great product team and a struggling one? The great teams don’t just ship — they build in ways to change course.

Ask yourself: If this fails, how easily can we undo it? If the answer is “we can’t,” you’re already in trouble.

Post-Launch Playbook: How to Stop Failing in Slow Motion

If Phase 1 is where most teams stop thinking, Phase 2 is where the real work should begin. The best teams don’t just ship and move on – they stick around to see if the thing they built actually worked.

Here’s how to break the success delusion and start measuring what actually matters:

Step 1: Stop Calling It “Launch Success”

A feature isn’t successful just because people use it in the first week. It’s a success when it drives sustained positive impact.

• Engagement spikes? Great. Does it last?

• Conversion goes up? Great. What happens to retention?

• More users sign up? Great. Do they stick around?

You aren't measuring success if you aren’t tracking what happens next.

Step 2: Use Paired Metrics to Balance Trade-offs

Most failures don’t happen because teams measure the wrong thing. They happen because teams measure only one thing.

• Increasing revenue? Check retention. If revenue rises but retention drops, you’re squeezing short-term gains out of long-term loyalty.

• More engagement? Check satisfaction. If engagement jumps but users feel bombarded, you might be training them to tune you out.

• More conversions? Check refunds. If more people buy but regret their purchase, you’ve won the wrong game.

Paired metrics create checks and balances. They prevent teams from blindly celebrating the first-order effect without considering the second-order cost.

Step 3: Track Outcomes Over Time, Not Just Spikes

Most teams measure impact too early. You miss the bigger picture if you only look at what happens in the first days or weeks.

• Set delayed success metrics: How does behaviour change 3 months later? 6 months later?

• Monitor second-order effects: Did solving one problem create another?

• Review features long after launch: Treat them like experiments, not one-and-done projects.

Step 4: Design for Course Correction

What if your big “win” turns out to be a slow-moving failure?

• Plan for iteration, not just delivery.

• If an outcome isn’t what you expected, have a mechanism to catch it and adjust.

• Features shouldn’t just be shipped – they should be actively managed.

The best product teams don’t just build. They keep thinking. They keep learning.

The Closing Punch: You’re Not Done Just Because You Shipped

Success isn’t what happens on launch day. Success is what happens six months later when no one is watching. The teams that thrive aren’t the ones that ship the most features. They’re the ones that stick around long enough to see what actually worked — and fix what didn’t.

So before you celebrate your next “win,” ask yourself:

• What happens next? Do we expect behaviour to stay the same, increase, or decline over time?

• What second-order effects should we track? What unintended consequences might emerge? Have we balanced this with a paired metric?

• What will we do if this backfires? Do we have a rollback plan or an intervention point?

• Do we have a baseline? Do we know what normal looked like before we changed something?

• What user behaviour are we actually trying to change? If this feature is successful, how will people interact with the product differently?

Because, at the end of the day, a product doesn’t succeed because of what it does. It succeeds because of what people do with it.

You’re not building a great product if your team isn’t asking these questions. You’re just rolling dice and hoping for the best. And as Morgan Freeman’s Ellis Boyd Redding says in The Shawshank Redemption:

‘Hope is a dangerous thing… hope can drive a man insane.’

The work isn’t done when you ship. That’s just when the consequences start unfolding — whether you’re watching or not.

About Me

I’m Paul, a Partner at Thrivve Partners and a Product and Flow Practitioner focused on data-informed, evidence-led ways of working. As a ProKanban trainer, I help teams and organisations navigate complexity, optimise flow, and deliver value without getting trapped in rigid frameworks. I believe in leading with curiosity, not judgment, and I help teams uncover better ways of working through exploration, learning, and continuous improvement.

You built the better product. Faster, smarter, and loaded with features your competition doesn’t have. And yet — no one’s switching. Here’s why adoption isn’t rational.

People don’t choose the best option. They choose the least risky, the most familiar — the one everyone else is already using.

This is where product teams screw up. They assume adoption is linear:

• Build something better

• People switch

• Success!

Wrong.

Adoption is chaos. There’s a giant chasm between early adopters (who chase shiny things — have we met?) and the mainstream market (who avoid change like it’s radioactive). That’s where good products go to die.

In this post, I will explain why your “better” product is failing and how to actually get people to switch.

The Great Adoption Myth: Why “Better” Doesn’t Win

Most product teams make the same fatal mistake: they assume users make rational choices. I have heard product managers having this conversation:

“If we build something 20% faster, 10% cheaper, and 30% shinier, people will obviously switch.”

It sounds logical, but let me tell you, it’s also completely wrong.

Here’s what actually happens:

• Users don’t make spreadsheets comparing your features or time themselves in their current and your product's main workflows to see if yours is ‘faster’.

• They don’t care about your roadmap.

• They definitely don’t read that 50-page white paper.

Instead, they ask themselves one question: “What happens if this goes wrong?”

• Will I lose my data?

• Will I have to explain this switch to my boss?

• Will my team hate me for dragging them into this?

• Will my ROI assumptions hold up, or will I look foolish justifying an investment based on potential benefits and many assumptions (on my part)?

This is switching cost — and it’s why “better” products lose every single day.

Just ask Google+. It was slicker than Facebook, more private, and free of algorithm nonsense, yet it still bombed. Why? Because Facebook was safe. Everyone was already there.

Better doesn’t win. Easier, safer, and more familiar do.

Why Users Stay Stuck: The Real Forces Behind Adoption

Adoption isn’t just about adding value — it’s about overcoming resistance.

Every potential user is caught between two competing forces:

Forces pushing them toward your product:

• It solves a real pain point

• It’s objectively better than what they have now

• Others are using it, creating social proof

Forces pulling them back to the status quo

• It’s unfamiliar — what if it doesn’t work?

• Switching takes effort — do I really have time for this?

• I already have a system that kinda works — why risk change?

• Re-learning cost — even if this is better, how long will it take me to get back to full speed?

• ROI is a lie — the “return” is unknowable upfront, just a bunch of assumptions about potential benefits.

If the forces pulling them back are stronger, they won’t switch — no matter how much better your product is.

Adoption Is Chaos: Why Your Growth Model Is a Lie

Product teams love smooth adoption curves. They draw nice, predictable lines:

• Early adopters love it.

• Then, the mainstream follows.

• Then, world domination.

Too bad that’s not how reality works. Adoption is a system of tipping points, inertia, and outright resistance. Instead of a smooth curve, you get this:

1. Early Adopters: Love shiny things. Willing to suffer through bugs, bad UI, and clunky onboarding if the upside is big enough.

2. The Chasm: A gaping void where most products die. Early adopters had fun. The mainstream? They don’t care. They need safety, trust, and guarantees.

3. The Mainstream Market: Doesn’t want innovation. It wants risk-free. It will switch when it has to, not when it can.

This is why “better” doesn’t cross the chasm.

• Google+ had better privacy than Facebook — flopped.

• Zoom wasn’t more advanced than Skype — it was just easier to use.

• EVs were better for years — adoption only took off once charging stations were everywhere.

Adoption isn’t about how good your product is. It’s about how easy, safe, and inevitable it feels.

How Adoption Actually Works: The JTBD Timeline

People don’t just wake up and decide to switch. Adoption happens as a slow burn, then all at once. Here’s the real timeline for switching:

1. First thought: “Hmm… my current solution kinda sucks.”→ But not enough to change yet.

2. Passive looking: “I wonder if there’s a better way…”→ They’re noticing problems but not taking action.

3. Active looking: “Okay, I need something better.”→ Now they’re comparing options.

4. The switch moment: “Screw it, I’m making the leap.”→ This is where your product needs to be ready and frictionless.

Most products fail because they try to sell to people at Step 1 or 2 — before they’re ready to switch. Instead, you need to design your adoption strategy around where people actually are in this journey.

How to Make People Switch: Engineering Adoption

Now that we’ve torched the myth that better means adoption, let’s talk about how to actually get people to switch. Forget features. Forget incremental improvements. You’re fighting against inertia, not competition. Here’s how to tip the scales in your favour:

1. Reduce the Risk: Make It Feel Safe

Users don’t fear your product — they fear what happens if it fails.

• Lower the stakes: Free trials, freemium models, and “no-commitment” options work because they make switching feel less risky. (For example, Slack lets teams onboard together before asking for a credit card.)

• Let them double-dip: People won’t abandon what they know overnight. Make coexistence easy; e.g., Apple lets you run iOS and macOS apps side-by-side before fully merging.

• Show them they’re not alone: Social proof crushes hesitation; e.g., Figma exploded when design teams saw other teams using it.

2. Remove the Friction: Make Switching Effortless

Users are lazy. If switching takes effort, they won’t do it. Period.

• No painful setup: If they need an IT team to install your product, forget it; e.g., Zoom wins because “click the link to join the meeting” beats Skype’s logins and downloads.

• Automate migration: Users won’t copy-paste their data. Do it for them, e.g., Superhuman scanning your Gmail setup to configure your inbox for you.

• Reduce decision fatigue: Give them one simple, obvious action to take, e.g., Calendly’s “send a link, pick a time” model, removing email back and forth.

3. Make It Inevitable: Engineer the Tipping Point

You don’t need every user to switch. You need enough of them to tip the system in your favour.

• Create network effects: If people’s friends, colleagues, or competitors use it, they’ll feel pressured, e.g., LinkedIn’s aggressive “connect your email” strategy.

• Make the old way feel outdated: No one wants to be left behind, e.g. when iMessage turned non-iPhone texts green, and suddenly, switching to iPhone felt like the smart move.

• Turn switching into the default choice: The best way to win is to remove the decision altogether, e.g., Microsoft bundling Teams with Office365, making it the “easy” option for businesses.

The Hidden Levers of Adoption

Beyond removing friction, there are non-obvious forces that help new products win:

1. The Wow Moment: The first-time users experience a transformational benefit. If users don’t hit this early, they’ll churn before adoption even begins, e.g., Figma’s magic moment when two or more designers work on the same design and collaborate in real time.

2. Status & Identity: People don’t just use products; they use them to signal who they are. If adopting your product elevates their status, they’ll push for it, e.g., Tesla buyers aren’t just driving electric; they’re part of an elite movement.

3. Urgency & Scarcity: People move when they have to. If switching isn’t time-sensitive, it drags out forever, e.g., limited-time offers, expiring free tiers, or the iPhone hype cycle.

4. Emotional Buy-In: People justify purchases with logic but make the decision emotionally. If your product makes them feel smart, safe, or ahead of the curve, they’ll sell it internally themselves, e.g., Apple’s marketing making users feel like innovators.

5. Zero Switching Effort: Adoption happens fastest when the transition is seamless. The closer your product is to plug-and-play, the lower the resistance, e.g., Zoom’s instant meeting links vs. Skype’s convoluted login.

The Unfair Advantage of Familiarity

Switching costs don’t just come from effort. They come from the brain’s need for familiarity. If something feels too new, too different — it feels risky. That’s why the easiest way to win adoption is to make users feel like they already know how to use your product before they even start.

People don’t want to learn new things. They want to recognise them — hijack their existing mental models.

• Slack didn’t “invent” workplace chat — it made it feel like an email inbox, AIM, and a group chat had a baby.

• Notion didn’t “reinvent” docs and wikis — it made them feel like an infinite whiteboard.

• Superhuman didn’t create a “new” email experience — it optimised Gmail’s mental model for power users.

The best products don’t just feel ‘better’ — they feel inevitable. They borrow mental models people already understand and subtly improve them. Dropbox felt like a folder on your desktop, so people used it instinctively. Zoom felt like a simple phone call with a link, so people didn’t overthink it. You’ve already lost if users have to ‘learn’ your product.

Takeaway: What is the easiest way to drive adoption? Make users feel like they already know how to use your product before they even start. Familiarity reduces switching costs more than any feature improvement ever could.

The Power of Defaults

Even if your product is better, it’s invisible if it’s not the default option. Users are lazy — they go with whatever is easiest.

• Microsoft crushed Slack by bundling Teams with Office365 — companies didn’t “choose” Teams; they just had it.

• Google Chrome overtook Firefox because it shipped as the default browser on Android.

• Apple’s Safari & iMessage dominance? They came preinstalled on iPhones, making them effortless to use.

Takeaway: If your product isn’t the default, you need to embed it where users already are — or make the old way feel obsolete.

The Adoption Ladder: How People Actually Switch

Switching isn’t an event — it’s a series of tiny commitments. Users don’t go from “interested” to “evangelist” overnight.

1. Awareness: “Oh, this exists?”

2. Interest: “Maybe this could help.”

3. First Use: “Let’s see if this actually works.”

4. Habit Formation: “This is how I do this now.”

5. Evangelism: “I tell others they have to use this.”

Takeaway: Most products fail because they don’t help users climb this ladder fast enough.

Final Takeaway: Adoption Is a System, Not a Choice

If your product isn’t taking off, it’s probably not because it’s not good enough. It’s because switching still feels too risky, too hard, or too optional.

Too many teams waste time trying to convince users instead of eliminating barriers. But adoption isn’t won through persuasion — it’s won by making switching feel like the only obvious choice.

The products that win aren’t just better. They’re the easiest, safest, and most natural option.

Familiarity makes your product feel safe. Defaults make it feel inevitable. Get both right and adoption doesn’t become a debate but a foregone conclusion.

Look at your own product. What’s the biggest friction point stopping users from switching today? Fix that, and adoption will follow.

What’s the biggest barrier to adoption you’ve faced? Drop your experience in the comments — I’d love to hear!

About Me

I’m Paul, a Partner at Thrivve Partners and a Product and Flow Practitioner focused on data-informed, evidence-led ways of working. As a ProKanban trainer, I help teams and organisations navigate complexity, optimise flow, and deliver value without getting trapped in rigid frameworks. I believe in leading with curiosity, not judgment, and I help teams uncover better ways of working through exploration, learning, and continuous improvement.

Subscribe now

As a kid, I thought my mother was justifying expensive purchases when she said, “Cost is what you pay; value is what you get.” It turns out she was describing the single biggest reason businesses make bad decisions.

A cheap pair of shoes that fell apart in six months? Bad value, even if they were on sale. A well-made pair that lasted years? Good value, even if they cost twice as much (and even if my younger self thought they looked a bit lame).

I see it everywhere. Businesses obsess over cost — budget, burn rate, margins. But value? That’s trickier. It’s assumed rather than measured, debated rather than understood. And the real challenge? Value isn’t a number. It’s contextual.

Take the diamond-water paradox. If I offered you diamonds or a bottle of water, you’d take the diamonds without hesitation. But if you were stranded in the desert, dying of thirst? The water would be worth more than all the diamonds in the world. Value isn’t fixed — it depends on circumstances, need, and perspective.

This is where businesses often get it wrong. They optimise for cost or efficiency without understanding what their customers actually value. They focus on outputs instead of outcomes, thinking that more automatically means better. But bad decisions follow when customer and business value don’t align.

“Price is what you pay. Value is what you get.” — Warren Buffett

So let’s talk about it. What is value, really? How do we balance what customers care about with what keeps a business alive? And how do we avoid the trap of optimising for one at the expense of the other?

The Value Misalignment Problem

Businesses love to talk about value. They throw the word around in strategy decks, mission statements, and customer promises. “We deliver value!”, “Creating customer value is our priority!” But ask ten people in the same company what that actually means, and you’ll get ten different answers.

That’s because value isn’t one thing — it depends on who’s looking at it. Customers see value in terms of outcomes: Does this solve my problem? Does it make my life easier, faster, better? On the other hand, businesses tend to see value through internal metrics: Revenue, efficiency, margins, and market share. The gap between these two perspectives is where things go wrong.

Take a classic example: customer support. A business focused purely on cost efficiency might decide to replace human agents with AI chatbots. On paper, this looks great — support costs go down, response times speed up, and executives pat themselves on the back for optimising operations. But from a customer’s perspective? The chatbot can’t solve their issue, so they go in circles trying to reach a real person, and frustration builds. The company saved money, but at what cost? If enough customers leave due to a terrible experience, that efficiency win becomes a long-term loss.

Or look at product development. Many teams measure success by the number of features shipped. More features = more value, right? Not necessarily. If those features don’t solve real customer problems, they’re just expensive distractions — bloat that cranks up the friction of the product in use. But because businesses often equate “delivering value” with “delivering something,” teams get rewarded for shipping more, not for improving things.

This disconnect happens all the time. Companies optimise for what they value, not necessarily what customers value. When those two things aren’t aligned, businesses make decisions that look smart internally but hurt them externally.

So how do we fix this? First, by recognising that value isn’t just what a company wants to deliver — it’s what customers experience and care about. Second, by understanding that business value and customer value don’t have to be at odds — when done right, they reinforce each other.

The best companies don’t just talk about value. They define it, measure it, and align their decisions to it. And let’s go there next.

When Value Gets Lost: Common Pitfalls

It’s easy to talk about value. It’s much harder to deliver it consistently. Even companies with the best intentions fall into traps that make them think they’re providing value when, in reality, they’re doing the opposite.

Sometimes, the mistake is betting the farm on certainty — believing so strongly in an idea that you ignore all evidence to the contrary. Other times, it’s an invisible drift — a slow, subtle shift from solving real customer problems to optimising for internal metrics, efficiency, or short-term gains.

Let’s take a look at what I see as the biggest and often overlooked ways businesses lose their grip on real value.

1. Betting the Farm on Certainty (a.k.a. The Assumption Trap)

It’s not what you don’t know that kills you — it’s what you’re certain about that turns out not to be so.

• You’re so sure you already understand what customers want that you stop listening.

• You fall in love with your own solution, ignoring signals that it isn’t working.

• Since you never defined value in the first place, you cannot measure whether you’re delivering it.

Real-world example: Blockbuster thought customers valued movie selection. Netflix realised they valued convenience. Blockbuster doubled down on late fees and in-store experience, while Netflix removed friction entirely. One of those companies no longer exists.

2. The “Efficiency Above All” Fallacy

Chasing efficiency is great — until it erodes what makes your product or service valuable.

• You optimise for cost savings without considering whether you’re making the right things efficient.

• Cutting too much removes necessary slack, making the business fragile.

• Customers feel the cuts in subtle ways: slower service, degraded experience, and lost trust.

Real-world example: Think about the last time you booked a flight. You got lured in by the cheap base fare — only to be hit with baggage fees, seat selection charges, and hidden costs (bathroom charges, anyone?) By the time you checked in, you realized the ‘cheap’ flight wasn’t cheap at all. That’s the efficiency trap: the business wins today, but the customer never comes back.

3. The “More Features = More Value” Fallacy

Shipping more doesn’t mean delivering more value.

• Teams equate output with impact.

• Leaders reward teams for shipping features, not for solving actual problems.

• Customers end up with bloated, cluttered products that technically do more but feel worse.

Real-world example: Microsoft Word in the early 2000s vs. Google Docs. Microsoft packed Word with hundreds of features people barely used. Google kept it simple and focused on collaboration — what people actually needed.

4. The “We Must Monetise Everything” Trap

Nothing destroys customer goodwill faster than forcing them to pay for things they once got for free — without adding any new value.

• You take something customers love and start charging for it without considering the value tradeoff.

• You erode trust by turning experience into transactions.

• Customers leave, and suddenly, your revenue and user base start shrinking.

Real-world example: Twitter (X) locking basic features behind paywalls. Instead of creating new premium offerings, they started charging for things that had always been free. The result? Users left in droves.

5. The “Vanity Metrics” Illusion

You get what you measure — and sometimes, you measure the wrong stuff.

• You track what’s easy to measure, not what matters.

• Internal KPIs drive decisions instead of customer reality.

• Growth numbers look amazing — until you realise no one sticks around.

The double whammy: It costs far more to acquire new customers than to keep existing ones. If people aren’t staying, the product isn’t delivering real value, and you’re just throwing money at the problem to keep the illusion of success alive.

Real-world example: Many VC-backed startups chase rapid user acquisition, reporting skyrocketing new signups to investors. But if retention is awful, all they’ve done is build a leaky bucket — one that gets more expensive to keep filling over time.

6. The “Committees Kill Value” Problem

The more layers of approval required, the less risky (and often less valuable) the final output.

• Committees dilute strong ideas into safe, mediocre ones.

• No one wants to be the person who bets on something bold — so nothing bold happens.

• The result? A slow, risk-averse business that moves at half-speed.

Real-world example: Nokia knew smartphones were the future. However, corporate inertia and committee decision-making prevented them from acting in time. Apple moved decisively, and the rest is history.

7. The “False Demand” Delusion

You mistake internal pain for customer pain — and you end up solving the wrong problem.

• You think because something is frustrating inside the business, it must be frustrating for customers.

• You build a process-heavy solution for an internal problem — customers don’t care, and now your operations are even more complex.

Real-world example: Enterprise software vendors who over-engineer workflows based on their own internal processes rather than actual customer needs, leading to bloated, unusable tools.

8. The “Market Will Catch Up to Us” Fantasy

You assume that people will eventually see the value in what you’re building.

• You blame the market for not understanding your vision.

• You wait for behaviour to change rather than adapt to what customers want now.

• You spend years educating the market instead of building something it values.

Real-world example: Google Glass. The tech was impressive, but the market wasn’t ready for wearable smart glasses. Instead of adapting, Google assumed people would catch up. They didn’t.

9. The “You Are Not Your Customer” Fallacy

One of the most dangerous mistakes a business can make is assuming that what they find valuable is the same as what customers find valuable.

• Your internal team understands the product in a way your customers never will.

• What seems intuitive to you might be utterly confusing to them

• You build for yourself instead of for the actual people using the product.

The result? Overly complex products, messaging that doesn’t resonate and features nobody needs — because they were designed from an insider’s perspective rather than the customer’s reality.

Real-world example: Early smartphone makers (Nokia, BlackBerry) thought customers wanted hardware keyboards and enterprise security. Apple realised they valued touchscreen simplicity and the app ecosystem — and the iPhone changed everything.

Bringing It All Together: The Danger of Assumptions

Each of these traps boils down to one core mistake: mistaking assumptions for reality.

• Assuming you know what customers value — without testing, measuring, or listening.

• Assuming efficiency equals value — without questioning what you’re optimising.

• Assuming growth = success — without looking at retention or long-term sustainability.

• Assuming your customers think like you do — when, in reality, they don’t.

When businesses lose touch with how customers define value, they make costly, avoidable errors—whether they bet everything on the wrong idea, chase efficiency at the cost of experience, or build for themselves rather than their users.

The best companies don’t just optimise for cost — they optimise for value, constantly testing it, challenging assumptions they are making about it, and redefining it based on observations and learning.

The Sweet Spot: Aligning Customer and Business Value

If the first half of this post was a tour through all the ways businesses lose sight of value, this is where we start to change the narrative and talk about how to right that wrong.

Let me start by reiterating that customer and business values aren’t in opposition. When done right, delivering what customers truly value should drive business success. The problem is that most companies optimise for one at the expense of the other — either chasing efficiency and monetisation at the cost of experience or over-indexing on delighting customers without a sustainable business model.

The real sweet spot is discovering what’s good for the customer is also good for the business.

1. User-Centered Design: Start With the Customer, Not the Business

A fundamental shift happens when companies stop asking, “What do we want to build?” and start asking, “What does the customer actually need?”

• User-centered design forces companies to think from the outside in. It’s not about what’s easy for the company but what makes sense for the user.

• It prevents the “You Are Not Your Customer” trap — designing based on observed user behaviour, not internal assumptions.

• Companies that invest in understanding their customers (through research, feedback loops, and continuous discovery) consistently outperform those that don’t.

Real-world example: Apple’s obsession with intuitive design. While competitors packed in features, Apple focused on making technology people wanted to use. The result? Higher customer loyalty, fewer support costs, and products that sell themselves.

2. Delivering Value, Not Just Features

Building more isn’t the same as building better, with the best companies focusing on solving problems, not adding features. They are asking:

• Does this solve a real user problem they care about?

• Does this improve the overall experience?

• Would customers miss this if it were removed?

Real-world example: Basecamp vs. Traditional Project Management Software. For years, project management tools kept getting more complex — Gantt charts, burndown reports, velocity tracking, deep integrations with dozens of enterprise systems. More features, they assumed, meant more value. Basecamp took a different approach. Instead of overwhelming users with endless functionality, it focused on simplicity — clear to-do lists, team communication, and a lightweight approach to project tracking. No bloat, no unnecessary complexity, just what teams actually needed to get work done. The result? Basecamp built a fiercely loyal user base, proving that more features don’t always mean more value — sometimes, they just mean more noise.

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupéry

3. Aligning Business Models With Customer Value

A great product with a poor business model won’t last. A great business model without customer value isn’t viable. The best companies align both.

• Usage-based pricing aligns value with customer needs (e.g., AWS, Stripe).

• Freemium models allow customers to experience value before paying (e.g., Notion, Figma).

• Subscription models prioritising retention over acquisition build sustainable businesses (e.g., Netflix focusing on content that keeps people subscribed).

Real-world example: John Lewis’ customer-first business model. Unlike many retailers focused on squeezing margins, John Lewis historically built loyalty through its commitment to fair pricing (‘Never Knowingly Undersold’) and employee ownership model. Because its staff (partners) share in the company’s success, the incentive isn’t just to maximise short-term profits and provide exceptional service and retain loyal customers.

4. Retention as the Ultimate Proof of Value

If customers stay, you’re delivering real value. If they don’t, you’re not.

• Acquiring a new customer is expensive — keeping one is much cheaper.

• A high churn rate means customers thought they saw value but didn’t experience enough to stay.

• Acquisition is flashy. Retention is what keeps you alive. Get onboarding right, and customers stay. Get it wrong, and they churn before you ever see a return.

Real-world example: Spotify vs. other streaming services. Spotify invests in personalisation (Discover Weekly, Wrapped, custom playlists), which keeps users engaged. Others rely on short-term promotions to get signups — but their retention suffers.

5. Feedback Loops: Measuring Value the Right Way

Companies obsessed with cost track every penny. Companies obsessed with value track what matters:

• Retention: Are customers sticking around?

• Advocacy: Would they recommend this product?

• Usage: Are they using key features regularly?

• Customer feedback: What are they saying?

Real-world example: Amazon’s relentless focus on customer feedback. They don’t just measure revenue; they track what customers say — and use that to drive improvements.

Bringing It All Together: The Value Flywheel

The best companies create a flywheel of value:

1. Deeply understand what customers value.

2. Build experiences that solve real problems.

3. Align business incentives with delivering customer value.

4. Measure and refine based on real-world feedback.

5. Repeat.

When done right, customer value creates business value. The trick is resisting the short-term temptations that break the cycle.

How to Measure and Manage Value

Most businesses track costs down to the penny. They know precisely how much they spend on salaries, infrastructure, and marketing. But when it comes to value? That’s often left as a vague assumption.

The best companies don’t just assume they deliver value — they define it, measure it, and actively manage it. Here’s how.

1. Measure Retention, Not Just Growth

Acquisition gets all the attention, but retention is the real test of value. If customers stay, you’re delivering value. If they are leaving in droves, you’re not.

Key retention signals:

• Churn rate — How many customers leave over time?

• Time-to-value (TTV) — How quickly do new users experience value?

• Expansion revenue — Are customers spending more over time?

Real-world example: Gym memberships vs. Peloton. Traditional gyms optimise for sign-ups, knowing most people will drop off after January. Peloton, on the other hand, focused on habit formation and engagement, ensuring customers kept coming back.

2. Track What Customers Use

Many businesses mistake shipping features for delivering value. Just because something exists in your product doesn’t mean it’s valuable.

• Feature adoption rate — What percentage of customers use a feature?

• Stickiness — How often do customers come back?

• “Would they miss it?” test — If you removed this feature, would anyone care?

Real-world example: Revolut vs. legacy banks. While traditional banks overload their apps with complex, rarely used features, Revolut tracks usage and prioritises what customers engage with — like real-time spending insights and fee-free international payments.

3. Use Customer Advocacy as a Signal of Value

Customers who truly find value in a product don’t just stick around — they actively bring others in. Instead of relying on the flawed “Would you recommend this?” question, businesses should track actual behaviours that indicate advocacy:

• Referral Rate — Are customers inviting others, not just saying they would?

• Word-of-Mouth Growth — What percentage of new customers come from organic recommendations?

• Usage Expansion — Do customers deepen their engagement over time (e.g., upgrading plans, using more features)?

• Customer Retention Over Time — Are more customers staying with the product long-term, or is churn increasing?

Real-world example: Monzo’s viral growth. Instead of relying on an NPS score, Monzo tracked referral signups, organic growth, and increased product usage (e.g., salary deposits, bill payments). Their real-world advocacy data was far more valuable than a survey question.

4. Align Internal Metrics With Customer Reality

Many businesses track vanity metrics that don’t reflect actual customer value. The key is to align internal success measures with customer success measures.

Bad metrics:

• Number of features shipped — Does not equal customer value.

• Total revenue — Doesn’t tell you if customers are happy.

• Page views/downloads — These don’t matter if engagement is low.

Better metrics:

• Customer lifetime value (CLV) — Are customers staying and spending?

• Task success rate — Can users complete key actions without frustration?

• Customer Engagement Score (CES) — Are customers actively using key features over time?

Real-world example: Amazon’s “customer obsession.” Instead of just tracking revenue, Amazon relentlessly measures customer satisfaction, delivery speed, and ease of use, ensuring that they keep customers, not just acquire them.

5. Close the Loop: Listen, Learn, Adapt

Value isn’t static — it evolves. The best companies have tight feedback loops to improve continuously:

• Direct customer feedback — Surveys, support tickets, qualitative insights.

• Behavioral data — What users do vs. what they say they want.

• Experimentation — A/B testing to see what delivers real impact.

Real-world example: Spotify’s personalisation. Instead of assuming what users want, Spotify constantly refines Discover Weekly, personalised playlists, and recommendations based on actual listening behavior.

Bringing It All Together: Value as a Living Metric

Measuring value isn’t a one-time exercise — it’s an ongoing process. The best companies:

1. Focus on retention, not just acquisition.

2. Measure what customers use and care about.

3. Track advocacy — happy customers bring in more customers.

4. Ditch vanity metrics in favour of meaningful ones.

5. Constantly listen, learn, and adapt.

In the end, delivering value isn’t about what you say — it’s about what your customers experience.

Bringing It Back: The Mindset Shift

My mother’s wisdom wasn’t just about money — it was about thinking beyond the surface. “Cost is what you pay, value is what you get.” She knew that focusing only on price was a short-sighted way to make decisions. The same applies to business.

Too many companies obsess over cost, efficiency, and output, believing that’s how they win. But value isn’t what you build, what you charge, or even what you measure — it’s what your customers experience. And when businesses lose sight of that, they make costly mistakes:

• They bet the farm on a certainty that turns out to be wrong.

• They optimise for efficiency at the expense of experience.

• They mistake more features for more value.

• They chase new customers instead of keeping existing ones.

The best companies? They align customer and business value by:

• Understanding what customers care about.

• Designing products and services around real needs, not assumptions.

• Onboarding properly and focusing on retention, not just acquisition.

• Measuring actual behavior instead of vanity metrics.

• Building feedback loops that continuously refine value delivery.

In the end, value isn’t a number on a spreadsheet — it’s the difference between a product customers tolerate and one they can’t live without.

The companies that truly get this? They don’t just survive. They thrive.

Because in the long run, cost is what you pay, value is what you get.

“The bitterness of poor quality remains long after the sweetness of low price is forgotten.” — Benjamin Franklin

About Me

I’m Paul, a Partner at Thrivve Partners and a Product and Flow Practitioner focused on data-informed, evidence-led ways of working. As a ProKanban trainer, I help teams and organisations navigate complexity, optimise flow, and deliver value without getting trapped in rigid frameworks. I believe in leading with curiosity, not judgment, and I help teams uncover better ways of working through exploration, learning, and continuous improvement.

Let’s get real: Ego gets way too much airtime. We worship hero leaders, glorify rockstar developers, and put visionary founders on pedestals. But at what cost?

Here’s the thing no one likes to admit: Ego is exhausting. Working in an environment where people care more about being right than doing right isn’t just frustrating — it’s counterproductive. The best ideas die in silence because they didn’t come from the ‘right’ person. Collaboration turns into competition. The focus shifts from solving problems to protecting egos.

Now imagine the opposite: an egoless organisation. A place where no one cares who gets the credit as long as the team succeeds. Where ideas win on their merit, not their messenger. Where leadership isn’t about who talks the loudest but who listens the most; these are the places where innovation thrives, trust grows, and work feels… well, amazing.

In this post, I’m diving into what makes egoless organisations so special — and why they’re worth striving for. I’ll explore what they look like, why they’re better for everyone (yes, even the occasional glory-seeker), and how to start building one. Leave your ego at the door, and you’ll be astounded at what can be achieved.

What Is an Egoless Organisation?

Egoless organisations are rare. They’re the unicorns in the world of work— the kind of places where no one’s fighting to be the loudest voice in the room, and no one’s hoarding credit like it’s a finite resource. These are places where the only thing that matters is the quality of the idea, not the status of the person who came up with it.

But let’s get one thing straight: egoless doesn’t mean personality-less. It doesn’t mean people don’t have ambition, drive, or a healthy sense of pride in their work. It means those things are subordinated to something bigger — the team's success, the product, the customer. It’s not about shrinking egos; it’s about shifting focus.

In an egoless organisation, leadership looks different. Decisions don’t flow downstream from the top person with all the answers. The environment holds space for creating and celebrating the best ideas, no matter who has them. It’s an environment based on active listening more than talking and enabling more than directing.

And here’s what I have been lucky enough to learn: it works. When you take ego out of the equation, incredible things happen. People feel safe speaking up, experimenting, and challenging the status quo. Teams stop competing with each other and start collaborating. Problems get solved faster because no one’s wasting time posturing. It’s not magic — it’s just what happens when the focus shifts from me to we.

Egoless organisations aren’t utopias. They still face challenges, tough decisions, and the occasional flare-up of human nature. But what sets them apart is how they respond: not with blame or defensiveness, but with humility and a shared commitment to improving. And that makes all the difference. “Fix the problem, not the blame” is the undertone which moves things forward.

Why Egoless Organisations Are Phenomenal Places to Work

Working in an egoless organisation feels different. It’s not just the absence of drama or politics — it’s the presence of something else entirely: trust, respect, and a shared sense of purpose. These are the places where you don’t dread Monday mornings because you know your energy is going into solving real problems, not navigating someone else’s power trip.

Here’s what makes them so remarkable:

1. Ideas Thrive, Not Hierarchies

Good ideas aren’t buried under job titles in an egoless organisation. The intern’s suggestion can carry as much weight as the director’s. Why? Because decisions are made based on merit, not status. When the best ideas win, you get better solutions — and a team that feels genuinely empowered to speak up.

2. Psychological Safety Is the Norm

In my experience, both through conversations and observations, I’ve noticed that most people tend to hold back at work. They stay quiet in meetings, avoid risks, or hesitate to challenge decisions because they fear how it’ll look. Not so in an egoless organisation. Here, mistakes are treated as learning opportunities, not career-ending blunders. It’s a place where you can experiment, fail, and grow without fear of judgment. And when people feel safe, they don’t just do their jobs — they innovate.

3. Collaboration Over Competition

Forget the glory hounds and the one-person shows. In an egoless culture, success is a team sport. Instead of taking the credit, people share it freely. Instead of hoarding knowledge, they make it accessible. The result? A workplace where collaboration isn’t just encouraged — it’s instinctive. Information turns into shared wisdom.

4. Sustainability and Resilience

Organisations built on ego are fragile. They depend on a handful of “heroes” who burn out or move on, leaving chaos in their wake. Egoless organisations, on the other hand, are built to last. They distribute ownership, responsibility, and knowledge so that no single person’s absence derails the team. It’s not about any one individual — it’s about the collective.

Egoless organisations are the exception, not the rule. But when you’ve experienced one, you can’t unsee what’s possible. They’re not just incredible places to work but what every workplace should aspire to be. And the best part? Building one isn’t about hiring unicorns or overhauling everything overnight. It starts with small, intentional changes that shift the focus from ego to outcomes.

The Challenges of Building an Egoless Organisation

Ego is deeply human. It’s hardwired in us. And even in the most collaborative, high-trust environments, it has a way of creeping back in if your attention slips. A subtle power play in a meeting. A leader who unconsciously dominates discussions. A team member more focused on looking good than doing good.

The truth is, creating an egoless culture isn’t about erasing ego altogether — that’s impossible. It’s about managing it, channelling it, and designing systems that prioritise the collective over the individual. Of course, that comes with its own set of challenges:

1. Ego Is Natural, and That’s Okay

First, let’s acknowledge the obvious: people will have egos. Ambition, pride, and drive aren’t the enemy — they’re fuel. The challenge is directing that fuel toward the right outcomes. In an egoless organisation, the goal isn’t to suppress ego; it’s to ensure it serves the team, not the individual.

“Pride makes us artificial; humility makes us real.” — Thomas Merton

2. Leaders Set the Tone — Whether They Mean To or Not

Leadership is the most significant make-or-break factor. You can’t have an egoless organisation with egotistical leaders. If a manager constantly interrupts, takes credit, or shuts down dissent, it sends a clear message: ego rules here. Leaders must model humility, encourage debate, take a back seat and actively listen — not because it’s “nice”, but because it’s essential.

3. Balancing Individual Recognition With Team Success

People still want to be recognised for their contributions — and they should be. The challenge is balancing celebrating individual achievements and reinforcing team outcomes. Over-index on one, and the other suffers. Get it right, and you build a culture where individual effort feels meaningful without overshadowing the bigger picture.

4. Recognising and Addressing Ego-Driven Behaviors

Ego doesn’t always announce itself. Sometimes, it’s subtle: withholding information to stay indispensable, lobbying behind the scenes to sway decisions, or even avoiding collaboration to keep ownership of a “win.” These behaviours need to be called out — not with blame, but with clarity about how they impact the team.

5. It’s Not a ‘Set It and Forget It’ Process

Even if you build an egoless culture, maintaining it requires ongoing effort, constant vigilance, feedback loops, and course corrections. Ego thrives in the cracks and the spaces between teams, and it’s up to everyone — not just leadership — to keep it in check.

Creating an egoless organisation isn’t about perfection. It’s about progress. It’s about fostering an environment where the focus stays on the work, the outcomes, and the team — even when ego tries to creep in. Yes, it’s hard. But the payoff? A workplace where trust, collaboration, and innovation aren’t just buzzwords — they’re your everyday reality. And that’s worth the effort.

How to Build an Egoless Organisation

If building an egoless organisation feels daunting, here’s the good news: it’s not about massive overhauls or perfect systems. It’s about small, intentional choices that, over time, shift the focus from ego to outcomes. You don’t need a clean slate; you need clarity, consistency, and commitment.

Here’s how to start:

1. Foster a Culture of Humility

Humility starts at the top. It sets the tone for the entire organisation if leaders can admit when they’re wrong, ask for feedback, and celebrate others’ ideas. Humility isn’t about being self-deprecating — it’s about creating space for others to thrive. When leaders step back, the team steps up.

Practices that matter:

• Encourage leaders to say, “I don’t know,” and mean it.

• Make active listening a core leadership skill. If you’re talking more than your team, flip the ratio.

2. Reward Collaboration, Not Individualism

What you reward is what you get. If the loudest voices or the “lone heroes” keep getting all the credit, don’t be surprised when collaboration dries up. Shift your recognition systems to celebrate teamwork and shared wins.

Practices that matter:

• Replace “Employee of the Month” with “Team of the Month.”

• Recognise individuals in the context of team achievements: “Their contribution helped us do X as a team.”

3. Encourage Open Communication

Egoless organisations thrive on transparency. People need to feel safe sharing ideas, feedback, and even disagreements. Open communication doesn’t just happen — it’s designed.

Practices that matter:

• Create regular forums for feedback where every voice counts, like retrospectives or anonymous surveys.

• Train teams to have constructive debates: challenge the idea, not the person.

4. Build Feedback Loops

Ego flourishes when people aren’t held accountable — or when no one points out its impact. Feedback loops keep behaviours aligned with the organisation’s values, turning unconscious habits into intentional improvements.

Practices that matter:

• Regularly ask: “What’s helping us succeed as a team? What’s getting in the way?”

• Encourage peer-to-peer feedback, not just top-down.

5. Invest in Leadership Development

Egoless organisations need egoless leaders. That doesn’t happen by accident. Leadership development should focus on skills like facilitation, emotional intelligence, and creating psychological safety — not just driving results. Some call this participatory leadership, where the leader’s role is less about directing and more about enabling. It’s about creating an environment where every voice is valued, decisions are collaborative, and ownership is shared across the team.

Practices that matter:

• Offer training that emphasises enabling teams rather than directing them.

• Coach leaders to measure their success by the growth and impact of their teams, not their personal achievements.

6. Reinforce Values Through Daily Behaviours

An egoless culture isn’t built on slogans or values in frames on the office wall. It’s built into the little things — how decisions are made, how meetings are run, and how success is defined.

Practices that matter:

• Make your values actionable: if “collaboration” is a value, design practices to support it (e.g., pair programming, cross-team workshops).

• Lead by example: when leaders embody the culture, others follow.

7. Recognise That It’s a Journey, Not a Destination

An egoless organisation isn’t something you “achieve.” It’s something you work toward every day. There will be missteps, and ego will creep in. What matters is how you respond — and how quickly you course-correct.

Practices that matter:

• Treat culture-building like a product: iterate, experiment, measure and refine.

• Celebrate progress, not perfection.

It’s not, but it’s worth it. It’s the kind of place where people feel safe contributing, where ideas flow freely, and where collaboration is the default. Start small, stay consistent, and watch your culture transform into something extraordinary.

The True Power of Egoless Organisations

Egoless organisations are powerhouses of innovation, resilience, and growth. Why? Because when you take ego out of the equation, you unlock the potential that would otherwise be wasted on posturing, politicking, or simply trying to “win.”

1. Innovation Becomes the Norm

When ego steps aside, people stop worrying about protecting their ideas and start building on each other’s. That’s when true creativity happens. It’s not about who’s right but what’s best. And when everyone feels safe contributing, no idea is too bold, risky, or “out there.”

Example: Think about the organisations known for their innovation — places where breakthroughs happen regularly. It’s not because they have more resources or more intelligent people; it’s because they have cultures where ideas can breathe, no matter who brings them up.

“None of us is as smart as all of us.” — Ken Blanchard

2. Resilience Is Built In

Egoless organisations don’t depend on a few “heroes” to hold everything together. They’re designed to thrive because ownership, responsibility, and trust are shared across the team. If someone leaves, the system doesn’t collapse — it adapts.

Example: Teams with distributed knowledge and collaborative practices are more likely to recover quickly from setbacks because the organisation's success doesn’t hinge on one person’s presence or performance.

3. People Stick Around

No one wants to work in a place where egos run the show. It’s exhausting, demoralising, and unsustainable. Egoless organisations retain great people because they offer something far more valuable than perks or promotions: a sense of purpose and belonging.

Example: Employees in egoless cultures feel valued for their contributions to the whole, not just their ability to stand out. That creates loyalty and engagement you can’t buy with a fancy title or a bigger paycheck.

4. Success Feels Different

In an egoless organisation, success doesn’t just feel like hitting a number or shipping a feature — it feels like “our success”. Individuals take pride in the team, the process, and the shared effort that made it possible. And it’s success that’s sustainable because it’s built on trust and mutual respect, not competition or self-interest.

Example: A team that celebrates a big win together, knowing that every voice and effort mattered, will always be more potent than a team built around individual glory.

Egoless organisations aren’t perfect — they’ll still face challenges, missteps, and the occasional ego flare-up. But what sets them apart is their ability to course-correct, adapt, and refocus on what matters: creating something extraordinary together. And that’s a power few organisations can match.

Where Do Egoless Organisations Start?

If you think this sounds like a lofty goal, it is, but it doesn’t require sweeping changes or a complete cultural reset. It starts small — one leader, team, and decision at a time. The key is intentionality: building systems, habits, and mindsets that reinforce humility, collaboration, and trust.

Here’s where you begin:

1. Leadership Go First

Egoless organisations begin with egoless leaders. If leadership is rooted in control, micromanagement, or a need to “own” outcomes, the rest of the organisation will follow suit. Leaders set the tone — not just in what they say, but in how they behave.

How to do it:

• Practice humility: Admit when you’re wrong and ask for help.

• Elevate others: In meetings, step back and let others lead the conversation.

• Measure success by your team’s growth, not your personal wins.

2. Make Values Actionable

Saying you value collaboration or trust isn’t enough. Your values must be reflected in how decisions are made, which behaviours are rewarded, and how conflicts are resolved. Culture isn’t what you write down — it’s what you practice.

How to do it:

• Align rewards with values: Celebrate team wins, not just individual performance.

• Incorporate values into decision-making: Ask, “Does this align with our commitment to collaboration?”

• Use values to signpost in challenging moments, not just in good times.

3. Redesign Incentives

People respond to what’s rewarded. If your systems promote competition, silos, or ego-driven behaviour, no amount of messaging about the collaboration will stick. Incentives shape culture, so design them carefully.

How to do it:

• Shift performance metrics to reflect team outcomes, not just individual contributions.

• Recognise and reward behaviours that align with your cultural goals — like knowledge sharing, mentoring, or cross-functional collaboration.

• Build feedback into the incentive system: Encourage peers to recognise each other’s contributions.

4. Create Safe Spaces for Honest Feedback

Egoless cultures thrive on feedback, but it can’t just flow from the top down. Teams need spaces where they feel safe to share concerns, challenge assumptions, and speak openly about what’s working — and what isn’t.

How to do it:

• Regularly schedule team retrospectives to reflect on what’s helping or hindering collaboration.

• Use tools like feedback surveys (anonymous if you must, but only to get started) to surface honest opinions.

• Train teams on how to give and receive feedback constructively.

5. Normalise Collective Ownership

In egoless organisations, success belongs to everyone. So does failure. Shifting the mindset from “my” work to “our” work changes how people approach challenges, decisions, and achievements.

How to do it:

• Build shared accountability into projects by clarifying team goals over individual tasks.

• When things go wrong, focus on learning and improving as a team rather than assigning blame.

• Celebrate milestones together, reinforcing the idea that every contribution matters.

None of this emerges overnight — it’s built through consistent, intentional efforts. Again, start small. Focus on the daily actions that signal humility, collaboration, and trust. It begins with the people in the room right now. And when they see the difference it makes, they’ll carry it forward. That’s how egoless organisations grow: one step, one person, one decision at a time.

Conclusion: Why Egoless Organisations Are Worth the Effort

Egoless organisations aren’t just great places to work — they’re transformative. They unlock creativity, build trust, and foster a level of collaboration that’s impossible to achieve in ego-driven environments. They’re resilient because they’re not reliant on individual heroes. They’re innovative because ideas win on merit, not hierarchy. And they’re sustainable because they create a culture where people want to stay, grow, and contribute.

It isn’t easy work — ego is baked into how most organisations operate today. Shifting from “me” to “we” requires courage, humility, and consistency. It means rethinking how you lead, reward, and create space for others to thrive. It’s about letting go of the need to control or own everything and embracing the idea that collective success is far greater than individual wins.

The payoff? A workplace where people feel valued, teams deliver incredible outcomes, and culture becomes your organisation’s competitive advantage. Egoless organisations aren’t perfect but honest, collaborative, and deeply human. And in a world where trust and authenticity are often in short supply, that’s what sets them apart.

So, here’s the challenge: what’s one small step you can take today to make your organisation less ego-driven and more egoless? Maybe it’s letting someone else take the spotlight. Perhaps it’s creating space for ideas you disagree with. Or maybe it’s simply listening more than you talk.

Because when you make space for others, you create something far bigger than yourself. And that makes egoless organisations not just fantastic to work in — but amazing to build.