From Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything — the operating manual for building what customers want when AI can build anything. See every chapter.
Not another methodology. That's what you're thinking, and I don't blame you.
You've been Agile. You've done Scrum. You survived SAFe. You've been product-led, sales-led, engineering-led. You've bought the tools, hired the consultants, sat through the transformations. Now someone is telling you there's a better way.
Here's what every one of those systems had in common: they were belief systems. They asked you to trust a process and take a leap of faith that if you followed the ceremonies, good outcomes would follow. That isn't natural. That's why they failed.
Walk through the graveyard with me. Each grave has the same cause of death.
Waterfall: A Warning Everyone Adopted as a Plan
In 1970, Winston Royce published the paper that gave us the sequential development picture. Requirements, then design, then implementation, then testing, then deployment. One phase flowing into the next like water down a cliff.
What everyone forgets: Royce drew that diagram to warn against it. In the same paper, he called the pure sequential approach risky and said it invites failure. The industry adopted the diagram and ignored the warning.
To be fair, Waterfall solved a real problem. Before it, software projects were chaos. Teams started coding without knowing what they were building, requirements shifted mid-stream, budgets exploded. The industry needed discipline, and Waterfall provided it.
Then the world sped up. By the time you finished an 18-month project, the market had moved. You'd built exactly what customers asked for two years ago, and they didn't want it anymore.
Waterfall assumed you could know everything upfront. You can't.
Agile: It Told You How to Build, Never What
In 2001, seventeen developers met at a ski lodge in Utah and wrote the Agile Manifesto. Waterfall was killing them. Documentation mattered more than working software. Plans mattered more than responding to change.
Agile's answer was short cycles, frequent shipping, and embracing change. Respond to customers instead of following a plan. And it worked, for a while.
The flaw was structural. Agile told you how to build but never what to build. So the ceremonies multiplied: stand-ups, sprint planning, retrospectives, story points, velocity. Teams got extremely good at shipping fast with no idea whether they were shipping the right thing.
Agile became Waterfall with more meetings.
The Manifesto promised "customer collaboration over contract negotiation." Beautiful words. In practice, the customer was represented by a proxy, usually a Product Owner whose job was to interpret what customers wanted. The telephone game continued. Customers were still filtered through layers of organizational opinion.
Scrum: The Recipe Became the Religion
Scrum is actually older than the Manifesto. Ken Schwaber and Jeff Sutherland first presented it at the OOPSLA conference in 1995, and both signed the Manifesto six years later (see The Scrum Guide and the Manifesto's list of authors). But Scrum became how most companies "did Agile," and it arrived with certifications, roles, and rules: Scrum Master, Product Owner, Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum.
It solved a real problem. Agile was too vague; teams didn't know how to actually do it. Scrum gave them a recipe.
Then the recipe became the religion. Teams optimized for Scrum compliance instead of customer outcomes. They measured velocity and celebrated completed sprints whether or not a single customer problem got solved.
I've seen teams with perfect Scrum execution, every ceremony done by the book, shipping features nobody uses.
SAFe: Waterfall Wearing a Hoodie
Enterprises looked at Agile and asked: how do we do this with 500 people? SAFe was the answer, complete with Agile Release Trains, Program Increments, Solution Trains, and Portfolio Kanban. I'm not making these up.
The problem it solved was coordination at scale. The cost was distance. SAFe added so many layers between customers and builders that feedback loops stretched toward infinity. By the time customer input reached a developer, it had been translated, prioritized, re-prioritized, and scheduled across several Program Increments.
SAFe is Waterfall wearing a hoodie.
Product-Led: Two Ideas Hiding Behind One Word
In the mid-2010s, "product-led" became the thing everyone wanted to be. Almost nobody agreed on what it meant, because two completely different concepts were hiding behind the same term.
Product-Led Growth is how customers buy
Product-Led Growth (PLG) is a go-to-market strategy. The idea: a product can be good enough to sell itself. No cold calls, no elaborate funnel. Freemium, self-serve onboarding, viral loops, fast time-to-value. It solves expensive customer acquisition, and it worked for companies like Slack, Dropbox, Notion, and Calendly.
A Product-Led Organization is how you build
A Product-Led Organization is a decision-making structure. The product team sits at the center. The PM decides what to build based on data, research, and intuition. Product drives the roadmap, not sales or engineering. It solves sales-led chaos, where you build whatever was promised to close a deal.
| Product-Led Growth | Product-Led Organization | |
|---|---|---|
| What it is | Go-to-market strategy | Decision-making structure |
| Direction | External: how customers buy | Internal: how you build |
| Problem it solves | Expensive acquisition | Sales-led chaos |
| Key metrics | Activation, free-to-paid conversion, expansion revenue, K-factor | Engagement, time-to-value, NPS, feature adoption |
People conflated the two. Even sales-led companies started calling themselves PLG, because PLG signaled "fast-growing" and "innovative." Founders got embarrassed to admit they had a sales motion.
One is how you build. The other is how customers buy. You can be either without the other.
HubSpot is the clean example. You can sign up and buy the cheapest plans without talking to anyone, so a PLG motion exists. But partner agencies and the customers they referred accounted for about 49% of HubSpot's 2025 revenue, according to its HubSpot, Form 10-K, fiscal 2025. HubSpot doesn't break out a self-serve number, and everything it does report points to a sales-led business. Yet internally it behaves like a product-led organization: dense customer feedback loops, product teams driving decisions. Product-led organization, sales-led growth.
Other mixes are just as common:
- Google: an engineering-led organization, with PLG for Search, Gmail, and Docs, and a sales-led motion for Cloud and Ads.
- AWS: PLG self-serve on top of an engineering-led culture. You can tell by the complaints: incredible service, impossible to understand.
Why product-led organizations still fail
Even companies that get the distinction right hit the next wall. The PM becomes the oracle.
The PM interprets what customers want and sets priorities from data and intuition. Instead of sales telling product what to build, product now tells everyone else what matters. That's not removing the filter. It's moving it. The customer is still being interpreted, and sometimes the interpreter is wrong.
Sales-Led and Engineering-Led: The Old Standbys
Sales-led never went away
While methodologies churned, plenty of companies stayed sales-led. Sales closes deals, deals set the roadmap, engineering builds what was sold. The upside is real: you know exactly what customers will pay for, because you already promised it.
The downside is that sales will promise anything to close. Product can't build all of it. Customers get some of what they bought, and they churn. The company ends up at war with itself. Sales blames product for moving slowly, product blames sales for overpromising, everyone blames engineering, and the customer gets caught in the crossfire.
Engineering-led builds beautiful things nobody wants
In engineering-led companies, engineers decide what's interesting to build and technical excellence is the goal. That pushes the boundaries of what's possible. It also produces elegant architecture for problems nobody has. I've seen systems with clean code, thoughtful design, and nonexistent customers. Those AWS complaints are the signature of this culture.
The Common Cause of Death
Line them up and the pattern is impossible to miss.
Every methodology filters the customer through a department.
- Waterfall filtered customers through Business Analysts.
- Agile filtered customers through Product Owners.
- Scrum filtered customers through the Scrum process.
- SAFe filtered customers through layer upon layer of bureaucracy.
- Product-led organizations filtered customers through PM intuition.
- Sales-led filtered customers through quota pressure.
- Engineering-led filtered customers through technical interest.
The customer's voice enters the organization and gets translated, interpreted, and prioritized by people with their own agendas. By the time it reaches the people building the product, it's unrecognizable.
That isn't because companies are stupid. It's because every system we've built puts departments between the customer and the builders.
Rule of thumb: count the people between a customer's words and the engineer's keyboard. Every one of them is a filter, and every filter distorts.
Why the Filter Stopped Being Affordable
The world used to tolerate this. Switching costs were high, customers were trapped, competition was thin. You could ignore customers and they'd stick around.
That world is gone. Your customers have endless options. A competitor can spin up a credible alternative in days. Customers can build their own tools if you won't. They expect answers at the speed AI made possible, and they leave the moment they stop getting them.
Meanwhile, the old excuse, "we can't possibly listen to all our customers," quietly expired. AI raised the bar, and it also raised our ability to clear it.
Customer-Led Is Not Another Methodology
Every methodology in the graveyard was answering the same question: how do we build? Customer-led answers a different one: how do we build the right thing?
There's only one way to remove the filter. Let customers drive decisions directly. Not through a PM's interpretation, a sales rep's quota, or an engineer's curiosity. Directly.
And this is where the product-led confusion pays off. Customer-led is an organizational philosophy, not a growth strategy. It pairs with any of them: customer-led plus PLG, customer-led plus sales-led growth, customer-led plus partner-led growth.
How you decide what to build and how customers buy are independent choices. Stop conflating them.
Yes, I'll eventually hand you systems with names. The difference is what sits at the center. Every methodology above organizes around a process. Customer-led organizes around a person: the customer, by name.
And it requires no faith. Methodologies ask you to trust that rituals, ceremonies, and certifications will produce success. Customer-led asks you to check. You can verify every claim with your own customers, in weeks.
Go back 2,000 years, or 200, to any moment when someone sold something and someone else bought it. The businesses that survived listened to customers and made something they wanted. That isn't a methodology. It's how business works once you strip away the theater.
Every system in the graveyard added layers between you and that simple truth. The principle hasn't changed since the first merchant opened the first shop. What's new is that AI makes it possible to listen to thousands of customers at once.
If you want the full system for removing the filter between your customers and your builders, it's in Customer-Led Development.
And if this graveyard tour looked uncomfortably familiar, subscribe to the Context Limit newsletter for more essays on building what customers actually want, without the ceremonies.