Steve Sanderson

How Founders Move Past Their Carrying Limit

Thu, 28 May 2026 16:36:23 -0600

What if the current leaders are the right people and the next stage needs more leadership than they alone can hold? Then the question is not who replaces them but who is alongside them long enough to land what comes next. That is the question I sit with the current leaders to answer until what comes next is in place.

The Pattern

For years, what you did was build the company. Founding rewarded your domain knowledge, the relationships you carried, the decisions only you could make: about who to hire next, what to ship next, when to say yes and when to say no. Out of necessity, the decisions came from you. As the company accrued success, the scope and quantity increased (e.g. what was once a technical conversation about a few tickets and a new feature has become a consideration of the impact this change has on the existing users, the new segment you’re opening up, the architecture, etc.). Your perspective may let you see where the gaps are opening up before the market does. If not, the feedback will come: from existing customers, from deals that don’t quite close right. None of this was a mistake. It’s what founding looks like.

As CEO, CPTO, CPO, and CTO, I’ve seen this pattern multiple times. The leaders carrying the company - the founders, sometimes alongside leaders who came in early enough to shape what the company became - are the right people. You have the domain knowledge that won the first customers, and are still winning them; you have the vision the company was built around, and it’s still worth pursuing; you have the relationships with the earliest believers (investors, early hires, lead customers) and they’re still holding. None of that is the problem.

What I have also seen: when the leadership capacity required for what comes next exceeds what the founder(s) can carry alone, the company pays a cost. Not because of any failure; because the company has grown past the size that one founder, or two, or three, can hold across every dimension at once. The moves you’ve tried already - hiring below the level where the gap actually sits, taking on more, doubling down and/or micro-managing on the outsourcing relationship(s), haven’t fit because doing more of the same does not bend the arc of the company. Replacing the founders is not the move either. Your contribution is still load-bearing. What I have seen the company need is help alongside the founders, not above and not below.

I’ve seen this show up in many forms: daily decisions stacking up on the CEO’s desk; founders pulled into too many in-the-weeds calls because there’s no one else who can hold the cross-functional read; the organization asking for direction that isn’t coming, because the volume of direction-needing-questions exceeds what you can answer in the time available. Recent hires haven’t landed the way the prior round did because the specificity required to land them at this stage is different. Co-founder conversations have started carrying a tension that wasn’t there before. The CEO senses, often quietly, that the company can not grow past where they themselves can hold it. None of these are emergencies on their own. Together they’re the shape of the moment I keep seeing - not the rocket ship, not the total disaster, but the company that should be moving and is not.

The Moves

My first move is to diagnose. The shape of what we find is rarely a single-seat-shaped gap, even when the surface conversation makes it look like “we need a Head of Product” or “we need a stronger engineering leader.” I pull the problem out of single-function framing and read it across multiple layers at once: business model, operating model, product model, human-systems, all pulled through by the customer needs that are under real strain or unmet. The shape of the gap clarifies in a way that no single layer can produce.

There are three lenses that let me determine the shape of the problem. The first is having sat in the CEO seat myself, long enough to read what carrying a company at scale is like from inside the seat rather than from outside it. The second is knowing what success looks like in the operator seats - product and engineering - without needing to take them again. The third is seeing how the GenAI platform shift goes beyond any single seat and follows patterns from five other platform shifts, e.g. affecting infrastructure dynamics through software regeneration patterns, or triggering internal value-shifts.

What I do next varies. Sometimes I’m providing incremental engineering leadership while a permanent hire is being sourced. Sometimes incremental product leadership while the founder continues to carry the technical side. Sometimes both. Sometimes I’m augmenting the CEO directly - operator-grade peer-thinking alongside the CEO across functions, without filling any specific seat - and the engagement starts there and converges on a specific hire as the diagnostic clarifies what’s needed. One engagement I worked began as helping the CEO develop strategic, company-level, and executive-level criteria and distinctions - what needed to be true for the company’s next stage. It transitioned to my augmenting the existing team as those criteria clarified, and ended with the right permanent hire stepping into the seat the work had revealed needed to exist.

Where It Gets Hard

The human-systems dimension makes the work hard in a way that is different from technical or operational work. When I come in alongside the founders, it is not only a question of what I do - the decisions I help carry, the hires I help spec, the organization design I help shape. It is a question of what changes in the relational architecture of the company: who decisions go to, who the team looks to for direction on what, what signals route to whom, what gets harder, what gets easier. This is not soft work next to the operational work. It is the operational work, read from a different angle - what is actually happening between people in the leadership team, not just what is on the whiteboard. Get this wrong, and the whole thing falls apart under stress. Get it right, and you’ve unlocked the next level of growth.

I’m tracking three layers at once.

The first is the organization’s response. In one engagement, the company had reached the size where the founder-CEO could no longer hold every cross-functional call alone. The question was not whether operator-grade help would land - everyone agreed it would. The question I was working on was how the team would relate to authority that was not the founder’s. I saw decisions that had been routing to the founder by ambient default keep routing there even after I was sitting alongside. Hires that should have landed in front of me were landing in front of the founder one more time before they could actually start operating. What I was tracking was not whether the work was getting done. It was whether the routing pattern was changing.

The second is the co-founder dynamic. In another, two co-founders carried the company together - one with domain and some of the internal operational depth, the other with external relationships and the remaining operational depth. The unspoken thing I was reading was that they both already knew which of them was reaching the limit, and neither could be the one to say it first. Any move that read as “one of you is the bottleneck” would have damaged the thing the company was built on. What I was tracking was not whether the right capabilities arrived. It was whether they arrived without breaking what the co-founders had built together.

The third is the extant founder’s individual response. In a third, the founder-CEO had been carrying a services business for years; the next stage required adding product offerings - a shift the founder could see was needed but couldn’t yet hold the shape of internally. The work was discovering, with the founder, what would need to be true for that shift to land - and reaching the point where the specification for who needed to come in to lead the product side was visible to both of us. What I was tracking was not whether the structural shift would land. It was whether the founder would experience it as something they did - rather than something done to them.

What This Is Not

Here’s what this work is not, in case it pattern-matches to adjacent categories you’ve seen. It is not fractional CPTO. A fractional CPTO fills the seat ongoingly, often through marketplace channels, often as a long-tail engagement that becomes the de facto answer to the gap. My work is bounded - the engagement ends with the outcomes we agree to. It is not founder coaching - the work I do is not about your individual development; it is on what the company needs that you can not carry alone. It is not founder replacement - you are the right people, and the move only works if your contribution is what carries the company through the transition and out the other side. It is not consultant-from-outside - the work I do is operator-grade alongside you, with accountability while I’m embedded. It is not turnaround or transformation lead - your company is healthy and growing, not in distress or running a defined transformation initiative.

What’s Possible From Here

The work is alongside, not above and not below. Having already been in the CEO, CPTO, CPO, and CTO seats myself, I am not taking a permanent seat. My engagement is bounded, alongside you, and ends in a transition - most commonly into a permanent hire I help define, source, evaluate, and onboard. Sometimes I help land a different structural fix - a board addition, a co-founder rebalance, an organization-design change that doesn’t require a single named hire. Either way, what I help build during the engagement - the organization design, the hiring specification, the executive-team coherence patterns, the decision-frames - is built to survive my departure. Preparing the company for what comes next is the work, not a postscript.

The pattern is solvable. Two of the companies I’ve been inside through this exact founder-capacity transition reached acquisition exits - life-changing for the founders, with the founders intact through the transition and out the other side. Four of my engagements have ended in acquisition exits altogether; my work is to help advance the company toward that path, or whatever similar shape comes next for it.

The question is not whether you are the right people - you are. The question is not whether the next stage requires more leadership than you alone can provide - it does. The question is whether the company you built can hold an operator-grade peer alongside you for the bounded window the work needs, long enough to discover the shape of what is missing and land the right permanent structure on the other side. The companies that can, advance. The companies that can not, do not.

The Incumbent's Unexpected Unfair Advantage

Thu, 28 May 2026 14:11:00 -0600

What if the disadvantages of being an incumbent have quietly inverted into an unfair advantage - and the questions are whether the company you scaled can recognize it and can hold a problem that does not fit any seat at the table? Recognition is something you bring; holding the problem is the work I do alongside CEOs - for the bounded window the inversion opens, making the moves the scaling org can not make from inside its own gravity.

The Pattern

For years, the moves that built your company were the right moves. Scaling rewarded code, operations, and the slow accumulation of contracts: with users about how the product behaves, with buyers about how the business runs, with the team about what counts as winning. Your company learned to see the signals that drove scale - and over time, stopped registering much else, because those were the only signals worth seeing. Tacit knowledge stayed in people’s heads because nobody needed it written down. Discovery skills atrophied because they weren’t relevant to the work. None of this was a mistake. It is what scaling looks like.

This is not the first time an exogenous change has reshaped what scaling rewarded. Mobile reshaped the desktop-first companies that had scaled before it. Cloud reshaped the on-prem incumbents that came before SaaS. Regulatory regime changes have done it repeatedly: HIPAA and the follow-on waves in healthcare; PSD2 and MiCA in finance; FERPA and the state privacy laws in education; the AI laws emerging now. Customer-expectations resets do it too, more quietly. In each case the underlying arc holds: the shift arrives, the existing competitive position erodes, the team tries the functional moves it knows how to make, the gap widens. I’ve been inside this pattern through six platform shifts in different seats - CEO, CPTO, CPO, and CTO. The shape of the impact was always the same: the company that should be moving but was not.

So, in response, when a successful software company tried to find new PMF, what I saw was that the effort always got valued from inside the scaling lens - wrong patience, wrong metrics, wrong people - and always lost. The pattern was so consistent (thanks to Christensen naming it) it got treated as a near-law of incumbency: success makes the next thing structurally unfindable. From the inside, the pattern held because the people who could see the next thing were the people the scaling org could not fund or promote: the discovery-aptitude, the patience for unstable signals, the willingness to throw the work away. The scaling lens valued the opposite. So the new thing got valued from inside the wrong reference frame and lost - not because the people inside the company couldn’t see it, but because the company they were inside couldn’t carry it. The conditions that made it a near-law are dissolving.

The Inversion

I see two GenAI effects changing the equation. The competitive threat arrives faster and lands harder - that’s the side of the story everyone’s telling. But the same forces flip the position of the company that scaled:

The cost to test a new direction collapses to startup-speed through agentic coding.
The cost to adapt existing systems once a direction is proven appears set to collapse too. Phoenix Architecture and approaches like it are on the horizon: regenerate legacy from spec rather than maintain it, and the cost of structural change inside a scaled company moves toward startup-cheap.

The two structural disadvantages that made established companies slow - can not test cheap, can not adapt cheap - are dissolving in parallel.

This is not just an analytical stance - the building I’m doing at the infra level (DXOS, plugin-bramble, Phoenix-flavored regeneration) is showing me what’s possible when both cost-curves collapse together. What’s distinctive about the GenAI moment, from where I’m sitting, is that the inversion mechanism - cost-to-test and cost-to-adapt collapsing together - is unusually sharp.

The Asset

Meanwhile, what I see your company sitting on - and what GenAI-native startups do not have - is the asset it’s been quietly accumulating across its lifetime:

Customer interaction history
Buyer feedback
What sales has learned about objection patterns
What customer success has learned about where the product breaks down in real workflows
What account management knows about how the contract differs from the use
What the SMEs in the company carry in their heads but no spec has ever captured
Facts and assumptions about the market, customers, and company embedded in the existing software

Here’s what I’ve found makes the asset hard to see from inside the company: it’s not systematically written down anywhere. The CRM holds names and stages, not the texture of how customers actually behave when they hit the edges of the product. Sales calls leave the salesperson smarter and the company exactly as smart as it was before. Support tickets compress the situation that produced them into a category code. The texture lives in Slack threads, internal emails, the dialogue between an SDR and an AE the day after a hard customer call - and in the heads of the people who’ve been there long enough to remember the patterns. None of that shows up on any balance sheet. Which is precisely why it’s worth what it’s worth: a competitor can’t buy it, can’t replicate it, and can’t see what they’re missing until they need it and find they can’t get it.

From where I sit, the shift in what’s durable (e.g. code regenerates in a weekend, customer knowledge takes the lifetime of a company) favors the side that’s been building it the whole time. The asset has been on your books, valued at zero, the whole time. What changed is not the asset. What changed is what it’s worth, and whether the company you scaled is built to see the value.

What It Takes

What I see from inside a company you would recognize: the Head of [the new thing] hire is six to nine months in and the strategic clarity hasn’t arrived. Win-rates are declining in segments that used to be safe. Existing customers are happy but new logos are getting harder. The product roadmap has gotten longer, not shorter. Engineering and product are both shipping but cumulative momentum has stalled. Board conversations have started shifting from “growth strategy” to “market response.” None of these are emergencies on their own. Together they’re the shape of the moment I keep seeing before it can be named.

The window is open. In my experience, the first condition is something you bring to the room - by the time we’re talking, the threat is already recognized enough to be a question worth asking. Most companies don’t see the threat until it’s too late. Once the threat is recognized, engagement runs through you - the CEO - and reaches into different parts of the company depending on the move. The minimal moves necessary to create the right conditions are the ones I run alongside you and the relevant parts of the org:

Reframe what the scaling lens hides. The unfair advantage isn’t visible from inside the scaling lens that built the company. What’s visible is the threat - the GenAI-native startup with the disturbing demos. What’s not visible is the asymmetry of customer knowledge, valued at zero on every balance sheet, that the threat can’t replicate. I help your team make this visible to your leadership - what specifically lives in your Slack threads, in your support tickets, in the heads of your SMEs - so the conversation can shift from defense-against-threat to use-what-you-have.
Configure isolated discovery alongside scaling. Most discovery attempts against sufficiently novel opportunities collapse back into the scaling org’s gravity. The metrics, cadence, and aptitudes that scale a company are wrong for discovery work - and an effort that isn’t isolated from them won’t survive contact. Isolation here is more than reporting lines: it’s separate funding, separate metrics, separate hiring, separate cadence, and an explicit charter not to be valued by the scaling org’s standards. I help you design that configuration so that the work survives the gravity of the scaling org.
Run discovery alongside the scaling org. Discovery in an at-scale org requires different attitudes, different aptitudes, different cadence than the work that scaled the company, as well as insight into what is already true in the scaling org. The work is closer to what the founders did before any of the scaling rewards kicked in - and most of those skills have left the building. I bring the discovery-aptitude in and teach by doing - alongside the team, not in a separate room - so the muscle gets built back into the company.
Lower the switching cost for users. You don’t have to make customers switch to your new thing; you already own the relationship before any switch. The unique move available to you is to lower the switching cost, using everything the company already knows about your customers’ workflows, contracts, and dependencies. A GenAI-native startup can’t do this. They pay full switching cost. I operationalize that - helping your org turn the customer-knowledge asset into a switching-cost-reduction based on what’s already true with the current products, so the move feels to your customer like an upgrade, not a migration.

The Window

The investors I talk to are watching what happens when this transition isn’t made: the zombies in their portfolios. Companies that can’t grow, can’t be acquired, and can’t be wound up cleanly. Their last realized asset turns out not to be the code, the brand, or the customer list. It’s the Slack archives, the support ticket histories, the internal emails, the Jira boards, the source code repurposed as training corpus rather than working system. AI labs are paying $10,000 to $100,000 per company for them, because public web text doesn’t capture how work actually gets done, and the next generation of agentic systems needs that operational dialogue to train inside. The asset that sat at zero on every balance sheet has a market price the moment the company dies. And the buyers are the labs powering the next set of competitors. It’s the same asset class your company has been quietly accumulating - and far more of it than appears on any balance sheet, including yours.

What I’ve seen is that lack of intent is not what makes a zombie. Engineering tried. Product tried. GTM tried. Each tried from inside their function’s frame, and the problem doesn’t shrink to fit any of them. Finding the next shape is not an engineering problem, is not a product problem, is not an executive problem, is not a GTM problem. There is no seat at the table shaped exactly for this problem. The CEO’s is the closest, and even that seat has its own gravity.

The window is open. The advantage is yours. The question is not whether you have it - you do. The question is whether the company you built can create the conditions to solve a problem that does not fit any seat at the table you already have. This is the work that gets done inside the window, or does not, in companies that don’t yet realize the window has opened for them. The companies that recognize it early get to run the experiment with their own asset; the companies that recognize it late watch their asset get bought by the labs powering the next wave of competitors. The math does not permit a wait-and-see strategy.

What if the disadvantages of being an incumbent have quietly inverted into an unfair advantage - and the questions are whether the company you scaled can recognize it and can hold a problem that doesn't fit any seat at the table?

Thu, 14 May 2026 15:14:40 -0600

So when a successful software company tried to find new PMF, the effort always got valued from inside the scaling lens - wrong patience, wrong metrics, wrong people - and always lost. Christensen named this the innovator’s dilemma, and the pattern has been so consistent it’s been treated as a near-law of incumbency: success makes the next thing structurally unfindable. The conditions that made it a near-law are dissolving.

Two GenAI effects change the equation. The competitive threat arrives faster and lands harder - that’s the side of the story everyone’s telling. But the same forces flip the position of the company that scaled:

The cost to test a new direction collapses to startup-speed through agentic coding.
The cost to adapt existing systems once a direction is proven appears set to collapse too. Phoenix Architecture and approaches like it are on the horizon: regenerate legacy from spec rather than maintain it, and the cost of structural change inside a scaled company moves toward startup-cheap.

The two structural disadvantages that made established companies slow - can’t test cheap, can’t adapt cheap - are dissolving in parallel.

Meanwhile, the asset GenAI-native startups don’t have is the one your company has been quietly accumulating across its lifetime:

Customer interaction history.
Buyer feedback.
What sales has learned about objection patterns.
What customer success has learned about where the product breaks down in real workflows.
What account management knows about how the contract differs from the use.
What the SMEs in the company carry in their heads but no spec has ever captured.

The shift in what’s durable - code regenerates in a weekend, customer knowledge takes the lifetime of a company - favors the side that’s been building it the whole time. The asset has been on your books, valued at zero, the whole time. What changed isn’t the asset. What changed is what it’s worth, and whether the company you scaled is built to see the value.

The window is open. Whether you can use it comes down to five conditions:

Recognizing the threat. Most companies don’t, until it’s late.
Seeing the possibility. The unfair advantage isn’t visible from inside the scaling lens that built the company.
Running discovery isolated, alongside scaling. Most attempts collapse back into the scaling org’s gravity. The metrics, patience, and aptitudes that scale a company are wrong for discovery work - and an effort that isn’t isolated from them won’t survive contact.
Doing discovery. Different attitudes, different aptitudes, different cadence than the work that scaled the company.
Switching users to what’s next. You don’t have to make customers switch to your new thing; you already own the relationship before any switch. The unique move available to you is to lower the switching cost, using everything the company already knows about your customers’ workflows, contracts, and dependencies. A GenAI-native startup can’t do this. They pay full switching cost. Done well, the move feels to your customer like an upgrade, not a migration.

The VCs I talk to are watching what happens when this transition isn’t made: the zombies in their portfolios. Companies that can’t grow, can’t be acquired, can’t be wound up cleanly. Their last realized asset turns out not to be the code, the brand, or the customer list. It’s the Slack archives, the support ticket histories, the internal emails, the Jira boards, the source code repurposed as training corpus rather than working system. AI labs are paying $10,000 to $100,000 a company for them, because public web text doesn’t capture how work actually gets done, and the next generation of agentic systems needs that operational dialogue to train inside. The asset that sat at zero on every balance sheet has a market price the moment the company dies. And the buyers are the labs powering the next set of competitors. It’s the same asset class your company has been quietly accumulating - and far more of it than appears on any balance sheet, including yours.

Lack of intent isn’t what makes a zombie. Engineering tried. Product tried. GTM tried. Each tried from inside their function’s frame, and the problem doesn’t shrink to fit any of them. Finding new PMF isn’t an engineering problem, isn’t a product problem, isn’t an executive problem, isn’t a GTM problem. There is no seat at the table shaped exactly for this problem. The CEO’s is the closest, and even that seat has its own gravity.

The window is open. The advantage is yours. The question isn’t whether you have it - you do. The question is whether the company you built can create the conditions to solve a problem that doesn’t fit any seat at the table you already have.

What if the discipline of deleting code is the easy half - and letting go of the company you built around defending it is the work?

Tue, 12 May 2026 18:05:48 -0600

For thirty years, code was the moat. Years to build, decades to maintain, hard to replicate. The bet made sense and most companies made it - the architecture review, the technical debt fight, the patent strategy, all of it pointed at the layer that took the team the longest to build, because that was the layer competitors couldn’t copy.

Code regenerates in a weekend now. Customer understanding still takes years. The asset that used to compound is the one depreciating fastest, and the domain expertise that used to walk out the door is turning into the durable asset - captured directly from people, and indirectly extracted from the code itself. We protected the code because it was the form of domain expertise we could lay our (virtual) hands on.

So a company can find itself defended and exposed at the same time - the protect-it-at-all-costs attitude still pointed at the codebase, while the knowledge that’s now priceless gets built or lost in decisions no one is treating like they matter. The shift is to protect the knowledge the code was based on.

Jason Goecke makes the same argument inside the software stack in his recent piece: the durable artifact isn’t the code, it’s the spec, and the incumbent’s curse is the rational decision to preserve what should be regenerated - continuing the thread Chad Fowler opened. The discipline he names is cultural comfort with deletion, because the spec is what regenerates the code.

The same shift runs at the company level: comfort with letting go of the identity built around the current solution, because the capacity to reorient is what regenerates fit. The architecture question is whether you’re willing to delete the code. The CEO question is whether you’re willing to let go of being the company that sells what you sell - long enough to discover what your market needs now.

The Problem You're About to Solve for Agents Is the One You've Been Working Around With People

Thu, 07 May 2026 14:02:41 -0600

Your team is rushing to build context-sharing for AI agents. The problem they’re solving isn’t an AI problem. It’s the same context-sharing problem your company has been working around for twenty years - and the cost of working around it just stopped being tolerable.

Maggie Appleton’s research on agent-assisted development names the bottleneck cleanly. Every solution on the table - coordination workspaces, context-sharing layers, alignment dashboards - is being built so agents can do their work. Substitute “new senior hire” for “agent” in any of those proposals. The problem is identical. The infrastructure your team is rushing to build for agents is the same infrastructure your company has worked around with humans for years - because the workaround was good enough. New engineers ramped slowly. Senior leaders carried context in their heads. “They’ll figure it out” was an acceptable answer because the cost of context loss was a quarter of slow output, not a wrong product shipped in two days. Agents change the math.

The companies that build this for agents will have built it for people too. The infrastructure doesn’t know whether the receiver is human or a model. The organizations that ship the agent-context layer will discover they’ve also shipped a human-context layer - faster onboarding, retained institutional knowledge, decisions that don’t have to be reconstructed each time someone new joins the room.

The decision you’re making about agent infrastructure is more loaded than it looks. It’s not an AI investment. It’s the move the regime change has made non-optional - the move toward making how the firm works legible to itself - with a forcing function attached. The companies that recognize what they’re actually building will use the AI urgency to fund the broader change. The ones that don’t will end up with better agent productivity inside the same firm that can’t see the next PMF.

What's the language about your customers telling you - before the metrics do?

Mon, 04 May 2026 17:48:40 -0600

The most public version of this right now is AI products that fail in flight. When something goes wrong, the first thing you hear is what the user did wrong - they shouldn’t have been there, they don’t know the risks, they’re not experts. The design’s failure becomes a question about the user’s competence, and the company gets held harmless. It’s a familiar shape - health insurance has run on it for years, patients reconciling EOBs against provider bills and getting blamed for the miss.

The quieter version shows up in companies losing product-market fit. That’s a fast-growing list right now - the GenAI regime that produces those public AI failures is also restructuring demand for everyone else’s: what customers expect, what they’ll pay for, what they think the work is.

A year ago, “the customer doesn’t know what they want” meant we did. We were ahead of them; they’d catch up. Now, losing fit, the same sentence comes out in the same meeting and means something different - they used to want this, and they don’t anymore, and we don’t know what to do with that. The behavior didn’t change. Who’s expected to bridge the gap did.

Same behavior, a year later, opposite meaning. A company with product-market fit doesn’t ask its customers to bridge a gap. A company losing fit does, even if it never names it. You’ve stopped finding fit and started defending it - and by the time it shows up in churn, it’s been audible in the language for a quarter or two.

Stimulus: a line in a recent Gary Marcus piece - “a lot of people want to blame the user” - got me thinking about how this shape shows up much more quietly inside companies.

Every company wants a paradigm shift. What’s getting funded is better tools.

Tue, 28 Apr 2026 16:14:25 -0600

GitHub is building tools to solve the biggest problem in AI-assisted development: teams are shipping faster than they can stay aligned. Maggie Appleton’s research on agent-assisted development makes the bottleneck clear - when agents do the building, agreeing on what to build becomes the bottleneck.

Every solution on the table - coordination workspaces, context-sharing layers, alignment dashboards - optimizes how teams work. None of them changes what the organization believes is worth working on. The change everyone is asking for sits at one level - what gets valued, what counts as progress, what the organization is optimized for. These tools intervene at another - how work gets coordinated, how fast it ships, how aligned the team stays. And when that gap holds, the tools get adopted and the old model stays put. You get faster throughput of the same mediocre decisions.

That’s what makes this painful. The work is genuinely good. These are creative, well-engineered solutions to a real coordination problem. But no company has ever gotten to a new model by making the current one run better.

The irony is that GitHub may be inside the same trap. Chad Fowler’s Phoenix Architecture points out that as architecture shifts toward disposable, agent-generated code, the repository - GitHub’s foundation - may stop being the center of gravity. GitHub is optimizing coordination around the repo while the repo’s relevance is the question they’re not asking. The company diagnosing the gap is demonstrating it.

What if the gap between shipping AI and seeing it move your business has nothing to do with how fast you’re moving?

Tue, 21 Apr 2026 15:06:00 -0600

What if the gap between shipping AI and seeing it move your business has nothing to do with how fast you’re moving?

Your board, your investors, the conference you just attended - they’re right about the urgency. They’re wrong about the prescription.

You’ve moved. You’ve shipped AI features, hired the talent, run the pilots. The effort is real - and the metrics aren’t responding. Not because you moved too slowly. Because you moved without knowing where the pull is.

Most of the AI advice in your world right now is supply-side thinking - here’s what AI can do, here’s what your competitors shipped, here’s what the technology enables. That’s pushing a rope. It feels like progress because the team is busy and the board sees motion. But motion isn’t movement.

The companies where AI is actually working started from the other end. They found what their customers need now that the ground has shifted - needs that couldn’t be met before, or needs that were met by human expertise and can now be met differently. They found the pull first. Then they built to it.

What if the PMF that shaped you is what’s keeping you from finding the next one?

Tue, 14 Apr 2026 15:04:00 -0600

What if the PMF that shaped you and your company is now what’s keeping you from finding the next one?

Your company was built around a set of answers - what the market wants, what the product is, how to win. Those answers worked. You led it to be optimized around them for years - your pattern recognition, every instinct about the customer, the product, the competitive landscape, all trained on that regime.

You and your company were shaped by it - and the company still has to run. Board prep, quarterly targets, pipeline reviews, keeping the team aligned and executing. Everyone around you has a stake in the current model, and they need you focused on it.

The GenAI regime change is shifting the ground under everything you built - you’ve hired the AI expertise, brought in the advisors, run the task forces, had the peer conversations - and the metrics still aren’t responding the way they should.

No one else in the company holds all of it at once. You’re the one who has to put the whole thing back together - what you sell, how you deliver it, how you make money on it - and you’re already questioning whether your assumptions underneath all three hold in a regime that’s still taking shape.

How do you gain the perspective to find the new when you’re consumed running the old?

What I’m seeing with SaaS founders and CEOs navigating the GenAI transition — the ones who built something that worked, and are now in the gap between what they were fit for and what comes next.

Post 6 of 6

See how I’m making sense of the larger pattern: A lens drawn from Carlota Perez

The assets and the constraint are the same thing

Tue, 07 Apr 2026 15:00:00 -0600

You have real customers, real distribution, and committed people who built it all. So why is all that making it harder to see what comes next?

Assets don’t protect themselves. People protect them.

Real customers means a CS team whose careers were built on those relationships. Real distribution means a sales leader who knows exactly how the current motion works. Real data means engineers who built the systems that collect it. Years of market understanding means leaders who earned that understanding the hard way — and who are doing exactly what the firm rewarded them for.

None of them are wrong. That’s the part that’s hard to see. The constraint isn’t resistance to change. It’s good people, doing their jobs well, protecting the fitness that was right until the ground shifted. Every conversation where someone you trust pulls the room back toward what’s working — that’s the asset and the constraint operating as the same thing.

The CEO can feel the gap between what needs to happen next and what the organization will actually do. That gap isn’t a people problem. It’s a structural one — and it’s the hardest kind to name, because naming it feels like blaming the people who built the company with you.

Post 5 of 6

See how I’m making sense of the larger pattern: A lens drawn from Carlota Perez

You’ve been here before

Tue, 31 Mar 2026 14:50:00 -0600

Every major technology transition looks unsurvivable from inside it. That’s not a property of this one. That’s a property of transitions.

Every company that navigated the web ascending over desktop, mobile ascending over web, SaaS ascending over on-premise — was in this exact state. Post-PMF in the old system. Pre-PMF in the new one. Carrying everything they’d built while trying to find what came next. The ones that made it didn’t have better information. They had the pattern.

You have the pattern now. AI shifted what can be delivered and what customers expect. That’s the sixth time this has happened in fifty years. The first five times, the companies inside it thought it was unprecedented too.

What changes when you have the pattern isn’t the urgency. The window is real. What changes is the move — from reacting to something that feels like a crisis to navigating something that has a shape.

Post 4 of 6

See how I’m making sense of the larger pattern: A lens drawn from Carlota Perez

Your last PMF is now what's in the way

Tue, 24 Mar 2026 18:22:01 -0600

Your last PMF is becoming your next constraint.

Not because you built something broken. Because you built something that worked — and then optimized it over years, in every direction. The pricing model that converted. The architecture that scaled. The go-to-market motion that closed. The customer profile that drove everything. Each was a correct choice. Collectively, they are now the thing in the way.

AI shifted what can be delivered and what customers now expect. The company stayed exactly what it was built to be. The more precisely you were fit for the last regime, the harder the move to the next one.

Pre-PMF again doesn’t mean starting over. It means finding where the current PMF ends and the next one begins — while everything you built is still running.

Post 3 of 6

See how I’m making sense of the larger pattern: A lens drawn from Carlota Perez

The normal moves don't work because you're solving the wrong problem

Tue, 24 Mar 2026 18:18:59 -0600

You’ve shipped the AI features. You’ve run the strategy sessions. The effort is real. It’s not working because you’re solving a post-PMF problem when you have a pre-PMF problem.

Post-PMF problems respond to execution. More features, better go-to-market, tighter process — these work when you know what the market wants and you’re optimizing delivery. That’s the game you’ve been playing, and you’re good at it.

Pre-PMF problems require clarity first. What does the market want now? What does the product need to become? What assumptions from the last PMF are now the constraint? You can’t execute your way to answers to those questions — and every cycle you spend trying, GenAI startups gain ground. They’re pre-PMF too. They just started there. They’re not carrying what you’re carrying.

The AI initiatives aren’t wrong. They’re the right kind of work for the wrong kind of problem. When you’re pre-PMF again, the move isn’t more — it’s different.

Post 2 of 6

See how I’m making sense of the larger pattern: A lens drawn from Carlota Perez

What losing PMF looks like when you still have it

Tue, 24 Mar 2026 18:15:36 -0600

What I’m seeing with SaaS founders and CEOs navigating the GenAI transition — the ones who built something that worked, and are now in the gap between what they were fit for and what comes next. Post 1 of 6

Product market fit doesn’t announce its departure. That’s what makes losing it so dangerous.

The metrics still look right. ARR is up, or close enough. The team is shipping. The board meeting was fine. The AI features are live. And yet — privately — you have a feeling. Not a conclusion. A feeling. That the thing that made this company work has subtly shifted. That the roadmap you’d defend publicly isn’t the one you’d bet on privately.

That feeling is a leading indicator. The churn, the growth slowdown, the board conversation that goes differently — those come later. By the time they’re visible, the departure already happened.

AI shifted the ground under something that was working. That’s not failure — it’s the condition. What you’re feeling now is the beginning of being pre-PMF again, while the company still looks post-PMF from the outside.

See how I’m making sense of the larger pattern: A lens drawn from Carlota Perez

A lens drawn from Carlota Perez

Tue, 24 Mar 2026 17:38:47 -0600

Visualization based on Steve’s interpretation of Perez’s framework. See caveats below.

Every major technology transition generates the same claim from inside it: this one is different. This one is unprecedented. The speed, the scope, the lack of a roadmap — all of it points to something genuinely new.

The claim is usually wrong about the transition. It is usually right about the experience.

Carlota Perez is an economic historian who spent thirty years mapping how technological change actually moves through economies. What follows is my application of her framework — a lens I’ve been using to make sense of how these changes have unfolded over time, and why the current transition looks the way it does. This is not a summary of her views; where I extend her concepts beyond the scope of her original work, those extensions are my own.

The core observation: major technologies don’t arrive all at once. They arrive in waves — clusters of interrelated innovations that Perez calls technology systems. Each system has a cheap input (the cost that falls and drives adoption), a new organizational logic, and a life cycle: irruption, growth, maturity. Multiple systems exist within a single long wave of development — the current one, which Perez dates from the Intel microprocessor in 1971, has already produced five. Perez calls this the Information and Communications Technology (ICT) paradigm: the overarching organizational logic of the information age, built around cheap microelectronics, networked scale, and software-defined value.

Technology system	Approximate period	Cheap input
Personal computers	~1975–1995	Cheap desktop compute
Internet and web	~1993–2005	Cheap networked communications
Mobile	~2007–2018	Cheap wireless and sensors
SaaS and cloud	~2005–present	Cheap hosted compute on demand
Tech-enabled services	~2009–present	Cheap smartphone-mediated coordination
Generative AI	~2022–present	Cheap inference compute

The cost of generating a model output has fallen faster than almost any comparable cost curve in computing history. That cost fall is what is driving adoption, reshaping product expectations, and putting pressure on companies that were correctly fit for the SaaS and cloud system.

The pattern each transition follows is this: companies that were correctly fit for the previous system find themselves in a specific structural condition as the next one takes hold. The metrics still look reasonable. The team is still shipping. The product still works. And yet — the ground has shifted. What customers can get from a next-generation product has changed. What they now expect has changed. The company is post-PMF in the old system and pre-PMF in the new one, simultaneously.

This happened to companies built for desktop when the web ascended. It happened again to companies built for the web when mobile ascended. It happened again to companies built for on-premise and installed software when SaaS and cloud ascended. Each time, the companies inside the transition thought it was unprecedented. Each time, the structural condition was recognizable.

What changes when you have the pattern isn’t the urgency — the window is real, and transitions have clocks. What changes is the move: from reacting to something that feels like a crisis to navigating something that has a shape.

A few caveats worth stating. Perez’s framework was developed in retrospect — she identified the five Great Surges of Development after they had largely run their course. The table above reflects two working assumptions I hold, not settled conclusions from her work.

Tech-enabled services as a distinct technology system. The table treats companies like Uber, Airbnb, and The Helper Bees as instances of a distinct technology system rather than a downstream effect of mobile or SaaS. The argument: the cheap input is genuinely distinct — cheap smartphone-mediated coordination of physical labor and assets — and the organizational logic (platform economics governing physical supply chains) is a meaningful departure from pure SaaS. The alternative reading is that Tech-Enabled Services is simply SaaS logic deploying into previously unreformed industries. I hold the first position, though the second is defensible.

Generative AI as a technology system within the current surge, not the beginning of the next one. The table places GenAI as the sixth technology system within the existing ICT paradigm rather than the irruption of an entirely new paradigm. The argument for it: cheap inference compute is a cost-curve event within the broader microelectronics paradigm; the organizational logic extends the ICT paradigm rather than replacing it. The argument against it: the speed and breadth of GenAI’s diffusion is already paradigm-scale, and the organizational logic it implies — every workflow rebuilt around learned models rather than coded rules — may be genuinely discontinuous. I hold the first position, with a conditional trajectory toward the second as conditions develop. A new paradigm may follow. That is a different transition, and a different problem.

The framework doesn’t tell you what to build. It tells you where you are, and what the condition you’re navigating looks like when it has been navigated successfully.

Carlota Perez, Technological Revolutions and Financial Capital (2002); “Technological Revolutions, Paradigm Shifts and Socio-Institutional Change” (2004); “Technological revolutions and techno-economic paradigms” (2009).

Draft of a Pattern for when founder-led product stops scaling

Thu, 22 Jan 2026 14:38:55 -0600

… Services-to-Product Transition: A profitable services company begins adding products to reduce manual work, create leverage, or standardize delivery. Early products automate known workflows and are led directly by an executive with deep customer knowledge. Initial success masks the need to separate product leadership as scope and complexity increase.

… Founder-Led Startup After Initial Product Success: A founder-led startup ships its first product successfully through tight intuition and fast feedback. As customer segments diversify and product demands multiply, the founder remains the center of product decisions while teams grow around them. Delivery accelerates, but discovery and prioritization remain implicit and inconsistent.

… Scale-Up Adding a Second Product or Platform Layer: A company with an established product introduces a second product, self-serve motion, or platform capability. Product decisions that once fit within a single roadmap now require tradeoffs across products, customers, and teams. Existing product governance no longer scales cleanly.

… Post-Acquisition Product Expansion: A company acquires a business with a single, founder-led product and intends to evolve or integrate it. Product scope and strategic constraints increase immediately, but product authority remains implicit or split across organizations. Without an intentional reset of product leadership, decision bottlenecks or fragmentation emerge.

❖❖❖

As product scope expands, decision authority remains implicit while execution spreads, causing learning and accountability to degrade even as delivery continues. What worked when product decisions were obvious becomes a governance bottleneck once multiple products, customers, or constraints exist.

An executive, often the founder or CEO, continues to act as the center of product decision-making while responsibility for execution spreads across engineering, operations, and adjacent teams. This model works when the product surface area is small and decisions are straightforward. It breaks down once product scope increases and tradeoffs become frequent, consequential, and non-obvious.

Product output increases, but learning slows. Decisions are made, but their rationale is unclear or inconsistent. Ownership of discovery, prioritization, and customer outcomes becomes diffuse. Teams execute against direction, but no one owns the tradeoffs when priorities conflict.

Responsibility for the customer experience is shared across product, engineering, operations, customer support, implementation, sales enablement, and sometimes marketing. Each group makes reasonable local decisions, but no single role owns the end-to-end outcome or resolves conflicts between speed, quality, revenue, and customer impact.

The system appears functional. Nothing is visibly failing. Metrics may hold or even improve. This masks the underlying issue: the organization has not decided how product and customer-facing decisions should be made at this stage of its evolution.

Several forces reinforce this condition:

Founder or executive intuition continues to feel efficient and safe.
Operational momentum rewards shipping and responsiveness over learning and discovery.
Early success hides structural ambiguity and delays intervention.
Shared execution across product, engineering, operations, support, and go-to-market blurs accountability.
Growth pressure increases both the volume and irreversibility of decisions.
Hiring instincts focus on adding capacity in delivery, support, or sales before clarifying decision ownership.

As pressure increases, two failure paths emerge. Product and customer-facing decisions either remain centralized, turning the existing executive into a bottleneck and slowing adaptation, or they are implicitly distributed across functions, fragmenting ownership and eroding coherence.

In both cases, ambiguity accumulates. Execution absorbs structural uncertainty. Hiring more people or accelerating delivery increases cost without increasing clarity.

This is not a capacity problem. It is a governance problem.

The company has crossed a threshold where product and customer outcomes can no longer be coordinated through intuition and goodwill alone, but explicit ownership of decisions has not yet been established.

Therefore:

Establish a single, explicit product decision owner before scaling product further.

Name one role that owns product outcomes end to end, including discovery, prioritization, and tradeoff decisions across constraints. Transfer day-to-day product decision authority from the existing executive to this role, while retaining strategic guardrails at the executive level. Define decision boundaries in writing, route all product sequencing decisions through this role, and time-box the transition so decision flow can be evaluated and corrected early.

❖❖❖

v2 of simple d3 with Meteor - now rendering individual records

Sat, 08 Jun 2013 06:17:00 -0600

simplest d3 + meteor example I could make v2

steve/simple-d3-with-meteor · GitHub.

Learning meteor & d3 together – I wanted a simple example to build on. Since I didn’t find one, I’m sharing this. The minimal (for me) was that it took advantage of the reactive data synced between client & server to affect something I drew with d3.

Now, individual circles are drawn by d3 (via a template), each one as a result of individual record changes managed by Meteor. This is more like what (I think) Meteor intended, as it's much closer to how HTML is created by Meteor templates. One difference, the removal of something from d3 is triggered by use of a callback from observing the Things collection.

Add & remove records in "Things" collection using the "+" and "-" buttons
Each record in the "Things" collection will be shown as a circle, with the "name" attribute as the text inside of the circle.

Simplest d3 + meteor example I could make

Wed, 05 Jun 2013 21:04:00 -0600

Learning meteor & d3 together - I wanted a simple example to build on. Since I didn’t find one, I’m sharing this. The minimal (for me) was that it took advantage of the reactive data synced between client & server to affect something I drew with d3.

steve/simple-d3-with-meteor · GitHub.

Thanks to the following sources for their help

SNAP! - Programming for Kids

Sun, 14 Apr 2013 19:07:00 -0600

SNAP! (Build Your Own Blocks).

We’ve had great fun, and results, teaching kids to program with Scratch. Now, Berkeley has “an extended reimplementation of Scratch … that allows you to Build Your Own Blocks. It also features first class lists, first class procedures, and continuations. These added capabilities make it suitable for a serious introduction to computer science for high school or college students."

I’ve only played with it a little - but getting started with Snap! is even easier than Scratch - because it’s browser-based (i.e. written in Javascript and designed to run in the browser).

You can try it right away and it’s worth it - even if you’re not a kid.

Ad-Hoc Usability Testing With Craiglist Users #leanstartup

Tue, 19 Mar 2013 21:24:00 -0600

At Food on the Table, feedback from real users is the life-blood of how they do lean startup. When we needed qualatiative feedback from new users, one way was to hire people off of craigslist - a form of ad-hoc usability testing.

This question has come up so often, I promised to share the answer here:

Hi Steve:

I've got a question for you on doing usability testing via random folks on Craigslist. Do you have an example of the ad that you guys use? We're going to shamelessly steal this concept, but we want to make sure we don't write something that only attracts uber geeks.

The answer, abstracted a bit:

First, we need to pull together some information for the ad. Much of this should be derived from the experiment you're working on (i.e. as part of the problem + hypothesis + experiment you've got - right?)
1. what is the context of your experiment, e.g. "website" or "iphone app"
2. what does your hypothesis + experiment say about how to filter or categorize the participants, e.g. for Food on the Table, we may have wanted to filter / categorize whether they cooked, whether they shopped, whether they used coupons. Turn these into individual questions about the participant.
More broadly, given your product, what is a few words associated with your product, e.g. for Food on the Table it may have been "recipes, meal planning and grocery shopping"
Now compose the ad:

title: Usability Testers For Hire

body:

We are conducting a usability study, which means we would like your opinion about a new we are developing that has to do with .

The sessions last approximately an hour and pay $30.

Please answer the following questions with your response.

1. Name:

...

12. Would you be available to do a research session at a downtown Austin office? Y/N

13. What day and time work best for you? (most sessions will take from 1-1.5 hours)

TIPS

Often we had some additional questions in the email exchange - one of the big questions is "are you a developer" or similar; in our experience, developers make horrible usability testers - they want to critique the implementation, etc.
We don't include the name of our product or company because, as you may have guessed, we would like to guarantee that this is truly a new user, i.e. they don't look ahead.
Conducting these usability interviews is a distinct skill - without that skill the value of the learning is at risk. I hope to offer some specific tips on this later, but key points are:
- don't lead the witness - ask open-ended questions and wait... wait... wait...
- watching what they do is as important as hearing what they say, i.e. body language communicates tremendous information - such as hesitation with a mouse, while verbally they're assuring you it's all fine.
- try to get at least 2 people in the interview with the participant
- get interviewers to sit around the participant so they can get different views
- get all the interviewers to capture their thoughts during the process
- don't waste effort on trying to formalize results, instead debrief immediately afterwards with all the interviewers and the relevant other people in the company
- everyone (yes, everyone) should participate as an interviewer regularly - developers, customers support, marketing, bus. dev, CEO - everyone.

Here's a version of the ad we posted on craigslist:

Website Usability Testers For Hire

We are conducting a usability study, which means we would like your opinion about a new website we are developing that has to do with recipes, meal planning and grocery shopping

The sessions last approximately an hour and pay $30.

Please answer the following questions with your response.

1. Name:

2. Age:

3. Do you do all/most of the cooking in the house? Y/N

4. Do you do all/most of the grocery shopping? Y/N

6. How many children under the age of 18 are in the house?

7. What grocery store do you go to buy your groceries?

8. How often do you use the Internet?

9. Would you be available to do a research session at a downtown Austin office? Y/N

10. What day and time work best for you? (most sessions will take from 1-1.5 hours)

Moving on from Food on the Table & What's Next!

Thu, 14 Mar 2013 14:05:00 -0600

It’s been a great 3 1/2 years at Food on the Table, however it’s time for me to move on. As you’d expect with a team and investors of this caliber, everyone has been very supportive of my decision. While this next phase will be without me, I remain confident that the work at Food on the Table will lead to great results.

Working closely with Manuel Rosso and our team for the last 3 1/2 years has been a tremendous experience. Out of that I’ve become deeply passionate about my Lean Startup experience & knowledge as well as having radically evolved how I do product development.

Now, the fun part! I'm using this time to collect evidence for two alternatives:

I'll take on one or two consulting projects (Austin or remote) while validating some startup ideas; or
I'll sign on in a new leadership role with an Austin team that is creating new products in conditions of extreme uncertainty (i.e. typically an early stage startup, but possibly a team in a larger org).

Regardless of which alternative, I'm looking forward to new challenges in building products that will continue to evolve my product development approach and give me the right dose of hands-on technical work.

As always, you can reach me at by sending email to any address at stevesanderson.com, e.g. harvestthisemail@

Recovering the Shine

Sun, 15 Jul 2012 13:44:00 -0600

One of the joys of having a sailboat is (in all seriousness) restoring a boat to better than new. With my Precision 18, there’s plenty of opportunties for this. Today, I realized I wasn’t sure how to go about restoring the hull (the gelcoat is chalky, but there’s not many scratches) - what do I do, how do I do it and in what order?

Fortunately, I found a good article that gave what is essentially a hierarchy of steps for recovering / restoring the shine in the hull (after cleaning):

try waxing,
and if that isn't sufficient then try polish,
and if that isn't sufficient then try compound
and if that isn't sufficient then try sandpaper

Fortunately, I tried waxing last year - and the results looked good.

So, now I’m on to Practical Sailor to read reviews on wax.

How would you benchmark the productivity of a lean-startup product development team?

Wed, 08 Feb 2012 21:59:26 -0600

How would you benchmark the productivity of a product-development team in lean-startup?

Why?

In my experience at Food on the Table, we've been much more productive than any of the other early-stage startups I've been involved with. I believe that one of the causes is our pervasive use of lean-startup & feel as if we're on to something important here. So, how can I (dis)prove this?

Uh, really?

I recognize the some of the inherent issues in my question:

no accepted standard to compare productivity
small sample size
what's the impact of environment & how can it be separated
what does lean-startup have to do with this at all
etc.

... despite these issues, I'm still asking the question.

Ok, you might...

So if you've got some ideas how you'd benchmark product development productivity, and maybe how'd you'd take that to the next step, how to compare, then leave a comment below.

Thanks!

Food on the Table is Hiring!

Mon, 20 Sep 2010 09:33:00 -0600

Food on the Table is hiring - I’m looking for a great developer to work with us. Read more at We Are Growing! | Food on the Table Blog.

MC and Talk at Austin On Rails Tuesday, September 28, 2010 @ 7-9 PM

Mon, 20 Sep 2010 09:31:00 -0600

On the 28th, I’ll be MC’ing the Austin On Rails meeting - (Meeting: Tuesday, September 28, 2010 @ 7-9 PM).

There’ll be four talks:

Technical Feedback Loops - Marcus Irven
Product Feedback Loops - Ash Maurya
Process Feedback Loop - (me)
How My Community Saved My Life - Mando Escamilla

My talk will be a short version of my recent Lone Star Ruby Conf. talk "Get your facts first, then you can distort them as you please" or why I love continuous learning with continuous deployment. (video)

Check out the talks and hope to see you there!