When Building Was the Advantage
Early in my career, I thought product progress looked like shipping.
I spent the first chapter of my career in teams where engineering was the strength—strong builders operating in a culture of fast delivery and high quality. If a customer had a problem, we could turn it into a feature quickly. The roadmap stayed full. Releases stayed frequent. It felt like we were winning.
Later, I stepped into a Go-to-market: how a company brings a product to market through positioning, sales, marketing, and distribution. environment. Sales, marketing, and delivery teams running a motion—chasing demand, shaping messaging, and closing deals. Watching that system up close revealed something I hadn’t fully appreciated before: markets don’t reward the team that builds the most. They reward the team that concentrates around a clear wedge of demand. Concentration makes the system easier to tune: messaging gets sharper, onboarding gets simpler, sales cycles shorten, and the feedback signal becomes easier to interpret. Without that concentration, speed doesn’t create clarity. It simply creates more surface area for confusion.
That shift gave me a different lens. Building fast is useful. Building without concentration is expensive. In practice, concentration means refusing adjacent feature requests, broader demos, and custom exceptions when they weaken the clarity of the segment you are actually learning from.
This pattern showed up repeatedly: building was rarely the constraint. In engineering‑heavy teams like ours, customer problems quickly turned into roadmap items. The roadmap moved, releases were frequent, and internally velocity started to feel like competence.
But velocity alone doesn’t tell you whether you’re getting sharper—or simply getting bigger. And in one product, that difference became impossible to ignore.
The PMF Island We Didn’t Concentrate On
The signal was there.
At first it did not look like obvious, broad product-market fit. It looked like one segment behaving meaningfully better than the rest. They retained better, converted faster, experienced less onboarding friction, and their usage patterns were far more consistent.
Looking back, the problem was not that the signal was invisible. It was that we had no explicit rule for when a concentrated pattern was strong enough to stop broad exploration and start concentrating around the wedge that was already pulling harder than the rest.
Individually, each signal looked explainable. Together, they pointed to something coherent. It was not dramatic and it was not viral. It was simply consistent.
That was our PMF island.
We noticed it, but we didn’t fully respect what it meant. Instead of concentrating there, we expanded. We generalized the product. We built for adjacent use cases and optimized for broader demos and larger conversations. At the time, the move felt rational: adjacent demand was real, larger conversations looked like progress, and broadening the product felt easier to justify than narrowing it.
The product became more powerful, but it also became less sharp.
Nothing collapsed. Revenue didn’t implode. Engineers stayed busy. From inside the company it looked like growth. The hardest part was not obvious failure. It was the growing gap between visible activity and weakening conviction.
But something subtle was happening beneath the surface. Focus diluted, positioning blurred, and the signal got noisier. We weren’t slow. We were distributing our conviction across too many directions.
And because we had no explicit wedge thesis, no shared record of what we believed, no clear falsification criteria, and no common rule for what counted as confirming evidence, every new feature looked like progress even when it compounded strategic noise.
A more useful falsification rule would have been this: if sustaining pull outside that segment required increasing customization, heavier sales explanation, or more onboarding hand-holding, then we were no longer seeing the same fit pattern extend outward. We were likely crossing the island boundary, and that should have forced a different decision: fortify the core, drop the expansion, or treat the adjacent segment as a separate bridge to design deliberately.
Rethinking Velocity
That experience reshaped how I evaluate velocity.
It also forced me to start thinking about how product teams could preserve clarity while moving fast. That question has shaped much of my work since.
I stopped asking, "What should we build next?" and started asking, "What must be true for this direction to hold?"
Velocity stopped being the indicator of progress. Evidence-backed conviction did.
At the time, there was still a natural limiter on how much damage misalignment could do. Building was expensive. Engineering capacity was finite. Even confused roadmaps moved slowly because the act of building itself imposed friction.
That friction quietly protected teams from their own strategic noise.
Today, that limiter is disappearing.
When AI Removes the Build Constraint
AI-assisted development is collapsing many of the constraints that once slowed product teams down. Routine coding effort is shrinking. Lead times are shorter. Experiments that once required weeks of engineering work can now be attempted in days.
A small example made this concrete for me: I recently built this website in Next.js, with a working content system, in under three hours. Six years ago, when I was still closer to code, I would not have expected to do that in a day or two—let alone after being away from hands-on development for years.
This does not remove coordination, rollout, or adoption complexity. But it materially lowers the cost of turning intent into working software.
For teams with strong product judgment, this is a real unlock.
But it changes what actually constrains product development.
The failure pattern I described earlier, expanding before concentrating and mistaking motion for progress, becomes far more dangerous when building is no longer the limiting factor.
Because AI does not just increase speed.
It lowers the cost of iteration, which means teams can change more things at once. As simultaneous changes increase, the number of interacting variables rises with them. It gets harder to tell what is actually driving the outcome. Learning gets noisier. And when learning gets noisier, concentration gets harder to maintain.
The Rise of Decision Entropy
I’ve watched versions of this play out repeatedly inside fast-moving product teams.
In one week you adjust pricing. The next week you introduce an AI‑assisted onboarding shortcut. A week later the dashboard layout changes to surface a new capability. None of these changes feel dramatic on their own. They are the normal, incremental moves of a team trying to improve the product.
But a few weeks later the numbers begin to move.
Activation ticks upward. Revenue per account nudges higher. At the same time, churn increases in a particular cohort.
Now the interpretations begin.
Growth attributes the improvement to onboarding. Sales points to pricing. Product believes the new layout helped users find key capabilities earlier. Customer success blames the new workflow for the churn.
All of these explanations sound plausible. None of them can be cleanly isolated.
The system changed in multiple dimensions at once, and the feedback signal is now contaminated by overlapping causes.
That is decision entropy.
Decision entropy is what happens when the pace of change exceeds a team’s ability to tell what is actually driving outcomes. Too many things move at once. Causes start to overlap. The signal gets harder to read. And once the team can no longer tell what produced the result, interpretations split and roadmap decisions become reactive or political.
Speed assumes clean feedback. Entropy breaks that assumption.
Where Speed as a Moat Breaks
The usual speed argument is that the fastest team learns the fastest. That only holds when teams can still tell what is actually driving outcomes. If the pace of change rises faster than a team’s ability to interpret results, learning does not accelerate. It fragments.
Speed still matters, but it compounds whatever direction the system is already moving in. When that direction is clear and concentrated, speed sharpens advantage. When it is diffused, speed amplifies dilution. Execution speed is becoming easier to access. The scarcer capability is preserving clarity as the system moves faster.
The New Scarcity: Clarity Under Speed
In an AI-accelerated world, execution speed is easier to access. The scarcer advantage is preserving causal clarity as teams move faster.
Most existing stacks are much better at measuring outcomes than preserving the chain between belief, decision, change, and result across overlapping moves. That is why dashboards, experiment tools, and reviews often help teams observe what happened without helping them stay clear on why it happened.
This is not just a discipline problem. It is also a systems constraint. Even strong teams lose the chain when the workflow does not preserve reasoning across product, GTM, and strategic changes.
That is why what teams often call a governance problem is usually a failure of attribution. The harder question is no longer whether a team can ship. It is whether the team can still tell what it changed, what it expected, and what the outcome actually means.
The Missing Chain
This pushes toward a more explicit operating model: every major product move should be treated as a traceable bet, not just an execution task.
At minimum, a team should be able to recover five things for any major move: who it was for, what it believed, what evidence supported it, what outcome it expected, and what would have proven the bet wrong. If that chain cannot be recovered later, the team may still see results, but it will struggle to know what those results actually mean.
That does not sound heavy. But once product, GTM, and strategy begin moving in parallel, most teams lose that chain faster than they realize. The problem is rarely that teams stop acting. It is that the workflow does not preserve the reasoning. The decision gets made in one place, the change gets shipped in another, the signal appears somewhere else, and by the time results move, the original logic has already fragmented across planning docs, tickets, dashboards, Slack threads, and memory.
That is why this cannot become another governance ritual layered on top of execution. Teams have rejected that model for good reason. When preserving traceability depends on separate documentation work, speed usually wins and the chain gets dropped.
For it to hold, traceability has to attach to moments where teams already commit to change: when a major move is prioritized, scoped, launched, or reviewed. The underlying bet needs to remain recoverable inside that flow. Not as a long memo. Not as a parallel process. As a small but persistent decision record that survives long enough to be tested against the outcome.
That persistence matters. If the record only helps explain one launch, it improves local clarity. If it survives across decisions, teams can start learning cumulatively instead of repeatedly rediscovering the same lessons under new pressure. Traceability helps a team understand one move. Persistence is what lets that understanding compound.
This is the part I’m most interested in testing: whether AI can change the tradeoff. Not by replacing judgment, and not by adding more process, but by reducing the manual work required to preserve that record. It can help draft the bet from planning discussions, pull expected outcomes and disconfirming conditions closer to the moment of decision, and make later review less dependent on reconstructing intent from scattered artifacts. That makes traceability more feasible inside execution, instead of leaving teams to piece it together weeks later.
That does not remove the need for judgment. It does not solve coordination by itself. But it changes the cost curve enough to make lightweight decision traceability more realistic in fast-moving teams.
In founder-led companies, that becomes a core operating responsibility: not just increasing velocity, but making sure the system can still tell what it believed, what changed, what the outcome actually means, and when a once-confident direction has stopped holding.