🔁 Beyond MVPs and SLCs
When does a product first reach someone other than the people building it?
Clemens Adolphs wrote a thoughtful article, MVPs are not products, and summarized it this way:
Jason says we should use SLCs instead of MVPs, but I say that, with Marty’s concept of MVP as prototype, those two can coexist. The MVP is the truly cheap not-a-product-ever version to validate the value hypothesis, and an SLC is the thing you build for an actual first release.
An MVP (Minimum Viable Product) is the smallest thing we can build to learn whether customers want what we are making. Marty Cagan treats it as a prototype that is never meant to ship. An SLC (Simple, Lovable, Complete), a term from Jason Cohen, is a first release that is small in scope, yet finished and enjoyable to use.
Release First takes this a step further: we release well before the MVP, starting on day two or three of the project. The first releases may be internal and may contain only documentation. The users are other people on the team, sales and marketing, management, and eventually early partners and customers. Exercising the release process early and putting releases in front of people besides the developers is how the flywheel starts turning.
Why does this matter? Two things:
- Releasing early and often pushes us to implement the workflow and automation to make releases efficient and safe.
- Getting something in front of other people (even internal people) provides early feedback and starts the iteration loop. These users always see things and find issues developers don’t see.
Everyone in the organization can sit down in front of an early release and give feedback. If someone needs help getting started, an AI assistant can walk them through it.
In Release First, I try to skip the prototype and treat every early build as a quality release. Nothing is throwaway, and nothing waits for “we’ll clean it up later.” The customer MVP is one incremental release among many, and so is the SLC. Each is a point in time where we pick a release from the stream for a purpose, not a special heroic effort.
What about risk?
Marty Cagan names four risks every product faces:
- Value: will customers buy or use it?
- Usability: can they figure out how to use it?
- Feasibility: can we build it?
- Business viability: does it work for the business?
Value risk is the risk that we build something nobody wants, and it is the one his MVP is designed to test. Does Release First address risk? At what point do we know our releases are heading toward something users want and can use, and that is buildable and viable?
Feedback from the releases confirms or disproves this over time. Release First does not set one point where we find out, such as an MVP. The answer emerges as releases land in front of people, and we often learn it sooner than with an MVP or a big 1.0 release.
A cheap, throwaway prototype sounds efficient. In my experience, cheap and throwaway rarely works out the way we planned. We often spend more time “fixing” cheap stuff than doing it right in the first place. On recent projects, setting up a release workflow in the first few days has taken a few hours with AI help, and it paid back the first time a build had to be reproduced.
Hardware is less different than it may seem. PCBs are inexpensive to build now. They still cost more than software changes, but little enough that more board spins are often affordable. Simulation is also a powerful tool to test concepts before building hardware, and a simulation is a release.
A concrete milestone like an MVP or SLC may still help motivate a team. The human side of this matters most, and it deserves more thought.
Related posts
