The Lean-Agile MVP: Why Most Startup Failures Are Process Failures Wearing a Technical Costume
Last time I wrote about PromptOS, a catalog of prompt failure modes born out of one bad debugging session. This post is about an older, bigger habit of mine: watching technically sound projects fail anyway, and eventually writing down what I think is actually going wrong.
The Dilemma That Started It
Most of the failed projects I've been near weren't killed by bad code. They were killed by teams who built the wrong thing carefully, or the right thing in the wrong order, or a real thing nobody had actually validated wanted to exist. The postmortems always reach for a technical explanation — the stack was wrong, the architecture didn't scale, the team was too junior — because that's the part everyone can see. The actual failure usually happened weeks earlier, in a decision about what to build and how to prove it mattered, and it was a process failure the whole time.
The Lean-Agile MVP Revolution is my attempt to write the book I wish someone had handed me before my first startup attempt: a founder/technical-lead field manual for closing that gap, from validated business strategy through lean product discovery, acceptance-test-driven development, clean architecture, and continuous, data-driven adaptation.
What's In It
The book runs six parts across seventeen chapters, bookended by a prologue and five appendices:
| Part | Focus |
|---|---|
| 1 — The Framework | Core methodology and organizing principles |
| 2 — Building the Business Case | Business Model Canvas, Value Proposition Canvas, validation |
| 3 — Acceptance Test-Driven Development | Turning validated ideas into executable specifications |
| 4 — Release and Repeat | Shipping, iterating, and building release discipline |
| 5 — Feedback, Adapt, Pivot | Reading production signal and acting on it honestly |
| 6 — The Long Game | Sustaining the practice past the MVP |
Rather than switching examples every chapter, the whole book follows one fictional product: Landscape Pro, a field service management platform for the landscaping industry, serving three customer segments — project managers, field service technicians, and dispatchers — through three constituent apps (Dispatch Pro, Service Pro, and a Customer Portal). It's a composite, not a real company, but the design decisions inside it are drawn from real projects. Following one product from idea to first 90 days means the book can show a decision's consequences three chapters later instead of asking you to trust that it mattered.
The Idea I Actually Use
The organizing principle I've kept using outside the book is the Golden Thread: a naming discipline that carries the same name, unchanged, from the earliest customer interview all the way to the production event log. "Assign Equipment" starts as a job on a Business Model Canvas, becomes a box on a Value Proposition Canvas, a row in a User Story Map, a scenario in a Gherkin specification, a feature branch, a release tag, and finally an event in a production log — and at no point does anyone rename it along the way.
That sounds like a small discipline until you've worked without it. The usual failure mode isn't that requirements get lost — it's that they get translated at every handoff, and each translation quietly drops or distorts a little context. A product manager's "quick reschedule" becomes a developer's "UpdateAppointmentTime" becomes an ops dashboard's "SLA_BREACH_RESOLVED," and six months later nobody can trace an incident back to the customer conversation that motivated the feature in the first place. The Golden Thread's fix is almost embarrassingly simple: stop translating. Keep the name.
A Production Detail Worth Mentioning
The book itself is built with the same seriousness I try to bring to the code in this series: a .NET console tool using Syncfusion DocIO merges the Markdown manuscript into a single Word document formatted for a 7"×10" trade paperback — proper running headers, front-matter pagination in Roman numerals switching to Arabic at the first chapter, the kind of detail a reader never consciously notices but absolutely notices the absence of.
Where It Actually Stands
Same honesty policy as the rest of this series: the manuscript is on its fifth draft, and all seventeen chapters plus the prologue and appendices are written — thirty-four files of real prose, not placeholders. What's left is the pass every book needs before it's actually done: final layout and pre-release polish, the kind of editorial work that doesn't show up as a chapter count but absolutely shows up in whether the finished book reads as one coherent argument instead of seventeen well-organized chapters. I'm not going to cite a specific completion percentage here — I don't have one I'd stand behind in public — but "content complete, finishing the last mile" is accurate.
Why This Matters Beyond the Book
PromptOS tries to close the gap between "the prompt worked in testing" and "I understand why it broke in production." The Lean-Agile MVP tries to close a gap one level up: between "we validated this idea" and "the thing we shipped still traces back to that validation." Different altitude, same instinct — treat a class of failure as something to systematize instead of relearning from scratch on every project.
Next up in this series is the last deep dive: what's actually next for this whole body of work, and the smart-home project that's been running in parallel to all of it.
If you've watched a technically competent team ship the wrong thing — or watched requirements get quietly lost in translation between the people who wanted a feature and the people who built it — I'd like to hear how you caught it, or how long it took you to notice.