I’ve been reflecting on the past 3/4 years of building products, helping people build products and have come to a fundamental notion that for every MVP there is a corollary Appendix.
The Appendix is the annoying part of building product for people who just like to build
It’s all the paraphernalia, the optional features, the edge case optimizations, the onboarding documentation, the launch video, the help pages, any of these things.
The MVP is the part that a lot of people focus on and that’s great.
It’s hard enough to build a great MVP but, most times its not enough.
In Crossing the Chasm, which is a great book, Geoffrey Moore calls something similar to this the ‘Whole Product’
I’ve been thinking about this of late as a result of my experiences and I’m convinced now that there is a need to split the Whole Product into the MVP and the Appendix.
The reason I feel that we should split these up is simple, they’re actually different skill sets.
I’ve realised that some types of builders love building mvps and are even excellent at it.
This is the type that will throw themselves at a problem and don’t stop until they figure it out.
This part is what I like to think of problem discovery and iteration, this is a circular process that exits when the mvp gets shipped for the first time.
Once the MVP ships and you start getting feedback, there’s a parallel track that quietly starts demanding attention. It’s not the product itself - it’s everything around the product.
| MVP (Building to Succeed) | Appendix (Building to Not Fail) |
|---|---|
| Core feature development | Onboarding flows & walkthroughs |
| Problem discovery & iteration | FAQs, help pages, support docs |
| Technical architecture | Decision logs & institutional knowledge |
| Shipping v1 | Launch videos, marketing assets |
| User feedback loops | Customer support playbooks |
| What to build | What to document, explain, and maintain |
To the first type of builder, this stuff doesn’t sound like building. But without it, more often than not, what they ship will not succeed.
These are genuinely different skill sets, the MVP builder thrives in ambiguity and iteration, the Appendix builder thrives in structure and completeness.
Put differently, the second type of building is a hedge against failure, the first type is a hedge for success. Without doing #2 you’re planning only to succeed, you’re not planning to not fail.
If you haven’t seen a semiotic square before, it maps out the logical relationships between a concept and its opposites - not just the binary, but the in-between states.
Here’s how it works for our case. Succeeding and failing aren’t just opposites, there are two states in between that matter. Not failing is not the same as succeeding. And not succeeding is not the same as failing. The square maps these four states and the relationships between them: succeeding implies not failing, failing implies not succeeding, and critically, not failing opens the door to succeeding.
That last part is the whole point. The Appendix doesn’t make you succeed. It keeps you from failing long enough for the MVP to find its footing. Not failing buys you time, and time is the most underrated ingredient in product building.
I do understand and in fact agree with arguments for failing fast, but, there are some domains where you cannot fail fast, Healthcare, fintech, enterprise, anything where trust is the product. In those worlds, build the appendix and not fail for as long as you can.
They’re both really important, maybe #2 is even deprioritised. Very likely because teams that ship MVPs don’t want to build the Appendix, that doesn’t mean it shouldn’t get built.
I actually think there’s a real opportunity here. Imagine a services company that only builds appendices - you hand them a freshly shipped MVP and they build out everything else.
The onboarding, the docs, the walkthrough videos, the FAQ, the support infrastructure. Early stage startups are almost always staffed with type-one builders, the MVP types, and asking them to build the appendix is like asking a sprinter to run a marathon.
They can do it, but it’s not where they’re best and they’ll resent it. A company that says “you build the thing, we’ll make sure it doesn’t fail” - that’s a compelling pitch. I don’t know if this exists yet in any serious form, but it should.
We celebrate shipping. We should. But shipping is the beginning of a longer, quieter kind of work, the kind that doesn’t get tweets or launch days.
The appendix isn’t glamorous, but it’s the difference between a product that launched and a product that lasted. Not failing isn’t a consolation prize. It’s the foundation.
Thank you for reading
Sainath