What You’ll Find This Week
HELLO {{ FNAME | INNOVATOR }}!
I read a compelling post by Ibrahim Bashir the other day that got me thinking about how we make bets on product and innovation. He defined the swim lanes as Increment, Evolve, or Invent. And then goes on to point out that invention is what we strive for and yet we rarely find the opportunity to pursue.
This week, I’m breaking down the Increment/Evolve/Invent conundrum to arm you with the tools necessary to advocate for invention within an org that’s more comfortable incrementing.
Here’s what you’ll find:
This Week’s Article: Legible vs. Illegible Work
Don’t Miss Our Latest Podcast
This Week’s Article
Legible vs. Illegible Work
Why incrementing is easy and inventing is not.
There are two types of work in every org: legible and illegible.
Legible means the org can evaluate the work with existing scoreboards and processes. In product orgs, legible work usually shows up in three familiar shapes:
Increment: improves what exists.
Evolve: changes the way the existing solution happens.
Invent: re-evaluates the problem without solution bias.
Legible work gets funded.
Illegible means the org can’t read the work through those systems. Illegible work gets managed into compliance. And compliance is the death of invention.
This is why invention rarely dies in a dramatic explosion. Ideas don’t get rejected. They simply get reshaped until they fit inside the system.
Why Product Orgs Settle Into Increment
This post was inspired by something I read on LinkedIn. Ibrahim Bashir posed an interesting observation/question, first by framing the idea of product work as bets in the three modes described above: Increment, Evolve, Invent.
That framing is the right starting point because it matches how product leaders actually live. Every week is a negotiation between “keep the money machine running” and “make the next money machine real.”
And based on this framing, Bashir asks…
Is there a cultural reason we lean towards incrementalism? Could we [as product people] change something in terms of rituals or principles to do more invention?
So why do teams hit an equilibrium where most work becomes Increment, some becomes Evolve, and Invent barely happens?
My take? It’s not because people don’t care. It’s because organizations only know how to evaluate one of those modes at scale.
Invent isn’t failing at the idea level. Invent is failing at the evaluation layer.
And this is where the question of legible vs illegible matters most.
Legible vs. Illegible Isn’t a New Framework
It’s simply the hidden constraint inside the Increment → Evolve → Invent cycle.
We have already defined the three modes of work. What we haven’t done a good job of defining is three ways to judge them.
Most orgs run a single scoreboard and a single governance path. That path was built for Increment. When you push Evolve and Invent through the Increment machine, two things happen:
Evolve gets treated like “Increment with a bigger story.”
Invent gets managed into compliance until it behaves like a roadmapable delivery.
As I’ve discussed in the past (dating all the way back to the very first article on Innovate, Disrupt, or Die), we’re running headlong into the ever-present battle of efficiency vs. innovation. So, through that lens, the question becomes: how do we evaluate opportunities to Invent without being forced to pretend it’s Increment?
This is Why Invent Collapses
Inside a product org, “Increment, Evolve, Invent” isn’t a portfolio strategy. It’s three different kinds of uncertainty.
Increment uncertainty is execution. You mostly know what to build.
Evolve uncertainty is path. You know the problem, you’re testing alternative solutions.
Invent uncertainty is framing. You’re reopening the problem without solution bias.
But most systems treat all uncertainty the same: as risk. And by now, we know that risk in a corporate setting must be reduced.
The Bet vs. Scoreboard Matrix
A bet type can only survive if it’s paired with a scoreboard that matches its uncertainty. The mistake that’s hiding in plain sight is using an Increment scoreboard to judge Invent. An Increment scoreboard will always interpret Invent as risk that must be eradicated.
Bet Type | What You’re Proving | What Progress Looks Like | Why It Dies |
|---|---|---|---|
Increment | “This change improves the existing system.” | Movement within a known funnel or retention metric. | The metric (not the outcome) becomes the deliverable. |
Evolve | “A different path solves the same problem better.” | Comparative evidence across paths, measurable change. | Early evidence is taken as proof ending the experiment too early. |
Invent | “Theres a newer, better way to solve this problem.” | Belief change, user pull, repeated behavior, design partner commitment. | Dates, ROI, and dependencies are demanded before tangible proof exists. |
How Invention Dies
Every planning cycle is a silent auction for attention: headcount, roadmap slots, executive patience, and political cover. Increment and Evolve show up with bids the org understands how to price.
But Invent shows up with uncertainty which is interpreted as risk.
So the org does what orgs do: it tries to make Invent legible.
The Compliance Conversion Death Trap
When an idea shows up that falls into the Invent category, it isn’t maliciously killed. People simply ask the questions they’ve been trained to ask and rewarded for answering:
Scoreboard: “What metric will this move?”
Commitment: “By when?”
Justification: “Why should we fund it?”
Coordination: “Who depends on who?”
Safety: “How do we reduce risk?”
Without clear answers to these questions, ideas hit the chopping block. So we’re incentivized to produce answers to questions that are inherently unanswerable in an uncertain world. In an attempt to salvage the idea, we’re left with the most compliant version possible.
This is why invention rarely dies in a dramatic explosion. The idea doesn’t get rejected. The very attempt to keep the idea alive results in a watered-down version that doesn’t scare anyone.
Welcome back to the Innovator’s Dilemma.
Three Bets, Three Scoreboards
Increment, Evolve, and Invent produce different work supported by different kinds of proof. But most orgs only have one way to judge work. One cadence. One reporting format. One definition of “progress.”
That system was built for Increment. So when Evolve and Invent show up, they get dragged into the same accountability system that the org knows and trusts.
But a single scoreboard for different kinds of work isn’t “rigor.” It’s political safety. It lets leaders defend decisions with familiar numbers and familiar timelines.
If you want an org that can actually support three different kinds of work, you need to establish three scoreboards. But creating three scorecards creates a cultural speed bump. If people don’t understand why different teams are held accountable to different definitions of success, they might construe “different scoreboards” as:
moving the goalposts
special treatment
no accountability
In reality, you’re doing the opposite: matching accountability to the bet. The first step is socializing an understanding of how to align measurement to modality across Increment, Evolve, and Invent.
Once the org shares that understanding, different scoreboards stop feeling like a loophole and start feeling like competence.
How to Operationalize This Change
Start with a shared operating agreement that makes three scoreboards acceptable:
1) Name the bet type before you debate the plan
Don’t start planning with features. Start by defining the type of bet:
Increment
Evolve
Invent
If you can’t name the bet type, you’re already on the path to scoring everything like Increment.
2) Define the right scoreboard for each bet type
Make it explicit:
Increment gets judged on outcome metrics.
Evolve gets judged on comparative evidence across paths.
Invent gets judged on proof that the framing is right.
You’re not “lowering the bar,” you’re matching the bar to the uncertainty level.
3) Replace “ship date” with “proof window” for Invent
Invent work should commit to a 30–60 day proof window, not a full roadmap promise. The commitment here is: “We will produce proof.” Not: “We will ship the whole thing.”
4) Light governance early. Heavy governance later.
The earlier the bet, the weaker the signal. That’s exactly when most orgs increase governance.
Flip it.
Use lighter governance to get to proof. Increase governance only once the work becomes legible on its own.
5) Clarify decision rights and kill rules
Invent fails fast when teams can’t make trade-offs.
One owner. Clear mandate. A kill rule.
If leadership wants to Invent, leadership has to accept that some Invent bets should die. That’s what proof is for.
What To Say in the Meeting
The operating agreement above only works if you can hold the line when the old questions show up. When an Invent bet hits the table, the first three questions are where it falls apart. Use these answers to interrupt the conversion without dodging accountability:
When someone asks: “What metric will this move?”
Say: “This is an Invent bet. For the first 30–60 days we’re not scoring outcomes. We’re scoring proof. Here’s what proof looks like.”
When someone asks: “By when?”
Say: “We can commit to a proof window, not a ship date. On date, we’ll bring back evidence and make a go/kill decision.”
When someone asks: “Why should we fund it?”
Say: “Because we’re buying down uncertainty. If we don’t see proof by date, we stop.”
The Only Way Invent Happens
Invent dies for one reason: it’s hard to sponsor.
Leadership can defend Increment in a QBR. They can’t defend uncertainty that hasn’t produced proof yet. So the org forces the bet into something defendable. That’s compliance.
If you want to Invent, don’t ask teams to “take bigger swings.” Give leadership a way to defend those big swings: Proof window. Proof definition. Kill rule.
How did this edition land for you?
