The Modern Leader
I have no doubt if you've been in tech for long enough, you've been involved in a conversation around balancing speed and quality to ship a new product. The tension often comes down to this:
Should we ship a Minimum Viable Product (MVP) or a Minimum Shippable Product (MSP)?
These terms get tossed around interchangeably, but they aren't the same. MVP is of course more commonly used, but I think there's an important distinction to make between the two when you're deciding what is "good enough" for your product.
I encourage you to think of MVP and MSP as a spectrum rather than binary choices. Where you land depends on two factors:
- The level of risk you're willing to take, and
- The trust your audience demands.
Here's how I break it down:
-
Internal tools: These can be closer to a true MVP. If it's a little buggy or visually not perfect but it's still functional, this may be all you really need. You can continue to adapt if the time spent is worth the effort. Speed matters more than polish here.
-
Beta features: A new feature in beta might allow some forgiveness, but there's still an expectation of functionality. This lands somewhere in the middle. Bugs are acceptable, but breaking trust isn't. (I assume you're using feature flags for beta features. Feature flags can help allow a more MVP-type product.)
-
Customer-facing features impacting access or PII: These demand a polished more polished MSP. There's little room for error when the stakes involve security, privacy, or customer trust.
One thing to note: An MSP does not demand perfection. Remember, it's still a minimum shippable product.
The best thing you can do is during planning, determine what your absolute must-haves are, then write down any trade-offs, assumptions, or risks you may be making by shipping an imperfect product. For example, if speed is absolutely paramount, you may decide to forego writing tests at the outset. Not ideal, of course, but if it must be done, write it downso you have it justified and agreed upon and then you can fast follow with writing tests.
Why this matters: This isn't just about semantics; it's about strategy. Misunderstanding the difference between MVP and MSP can create friction across teams. PMs may want fast iteration, engineers may feel overburdened by scope, and leadership may fear reputational risks. Introducing the idea of an MVP←→MSP spectrum at your organization can help reduce this friction.