Minimum Differentiable Product
I've been thinking a lot lately about how the way we build things for the web is changing. To be precise, about the way it diverges towards both ends of the same spectrum in tandem, leaving an ever-wider chasm in the middle. Democratization is at one end, as complexity is abstracted away into services. Ever-deeper specialization is on the other as the decades accumulate under the iterative process.
These are symbiotic processes, each fueling the other. And it's not a new shift. It's been happening since the beginning. To one extent or another, all technological advancement is a process of progressive abstraction. Only the rate of change is variable.
Every now and then, we'll face a particularly impactful breakpoint and we'll look at that point in a different light. We'll see our futures on unemployment flash before our us as we stare into the eyes of GPT-3. We'll laugh at the no-code movement because we've heard this story before. Then, once our amygdala cedes control back to the rational brain, or a demonstration of abstracted power leaves our complacency shaken, we'll re-evaluate the shift in a sober light. It's all just abstraction. Variably impactful, but a process no different in concept than the abandonment of jQuery for React. Or the replacement of the command line as the default user interface by pointing devices and cursors, and eventually just pointing fingers.
Speaking of concepts, here's one that's taken on a life of its own: the Minimum Viable Product. It's a useful planning mechanism, a heuristic for market validation. But it's also myth and magical incantation, a placeholder for consideration that never took place. It's a tool for deferring the non-essential until we trust we're headed the right way. It's also a wave of the hand and breath past any real need to consider, plan, polish, or any of those other things that cost time and money, but delight the user as their most persistent problems are swept away.
As a human technology, the web is in its infancy. But in the seasons of progress we perceive within lifetimes, the web that we know today has begun to feel mature. A late-stage adolescent with a malicious streak, yes, but the parts are getting to grown-up even if the sum hasn't. Change in the technology that underlies it feels increasingly incremental. We can barely keep up with the stream of new tools, libraries, and languages, but we're really deciding on the workflows we want to employ at this point. Technological limitation doesn't stand in the way of most of us building web products, but for the most specialized teams. We're most likely to find ourselves blocked by resource requirements, competitive attrition, or the challenges of execution.
There's plenty of greenfield space. It's just that, as the cliché of recent years goes, it's not in photo-sharing apps anymore. Do you remember the name of the location-based photo-sharing app that took a $50 million Series A a decade back and became the butt of overvaluation jokes for years thereafter? Me neither. Those days are gone.
As we grasp at each rock on the final stretch of cliff-face before the next abstraction breakpoint — after which we all hope we'll frolic on the plateau of a large, green field — you need to be very careful about your strategy.
For every rock you manage to grab onto, there's another tumbling down from the top. The monopolists kicking away the chihuahuas at their heels, the tumble of all the other upstarts falling off above you. And you've just gone to market with whatever you whipped up to test the waters.
And that's okay. But you've got to do it right.
Minimum Viable Product is a serviceable name, but it misses some important nuance. Nuance that would've helped ten years ago, but becomes really important in periods of market maturity.
You may be better served if you think of it as the Minimum Differentiable Product. The Minimum Viable Product carries with it a sense that as long as everything works fine, delivers the essence of functionality without breaking too much, you'll be able to determine whether there's demand for the next version of whatever you've built.
That worked ten years ago because there was no point in building your hut next to a house (we seem to have abandoned the cliff-face for canines and construction — apologies to the consistent). There was too much open space to bother with that sort of inconvenience, unless you wanted to be a social network or photo-sharing app. And so you got a sense of your potential for success almost just by describing the thing you thought people wanted and linking to a registration page.
Not so now — people have options. Mansions stand door-to-door and the awnings barely have room to spill over alleyways.
That's why you need a Minimum Differentiable Product. Or perhaps it's a Minimum Viable, Maximally Differentiated Product, but we're really getting away from the the value of a snappy name here.
You can afford to get the basics in place quickly and iterate at speed. But your point of differentiation needs to have some thought, care, and craftsmanship put into it. You want to get a working model over the line without getting lost in weeks of weeds, but your point of difference? That's where you need to have spent 90% of your time. You need to make an argument so compelling that people are willing to spend the requisite time battling inertia and lock-in to escape their really-quite-fine-and-mature-thank-you product of choice.
One way to increase your odds of achieving that is to build something for yourself. If you read the one-month reflections of Jani Eväkallio, who built Foam (discussed in the first issue), you'll see this dynamic at play. Jani didn't need green fields — Roam Research, which he set out to improve upon for himself, is still in a new, wild ascent. This comparison is somewhat unfair because Foam is free. But it's an approach that has worked far better than the focus group across commercial and open source projects and every epoch of the web, and even across the history of human invention. You don't need me to prove that — rattle off the classics: Mailchimp, Basecamp, Twitter, GitHub... I'll stop there. You have Google too.
Even so, it's hard to gift a developer a free tool these days, and you, dear reader, will know why better than anyone. Foam took off so readily because it gave developers exactly what they wanted out of something like Roam. Extreme extensibility and control of their own instance. Git as the basis for versioning, protecting, and syncing that information. Functionality that otherwise kept Minimum Viable Pace with the competition. It's an exemplar of the minimum viable and the maximally differentiated. Even in the price tag, if you want to get cheeky.
Here's the thing to bear in mind when it comes to building a Minimum Differentiable Product, instead of an MVP that'll hang around the roadmap backlog for months or years, its stats never justifying the developer time to build the Iterative, Interesting Product.
Does your implementation make you want to use your solution over the mature competition when considering the differentiating vector in isolation? Better yet, are you using it because that vector makes the competition feel outmoded – in spite of your MDP's general immaturity?
If the answer is no: your product isn't minimally viable. Not in a market with challengers. And not in a market where you are the challenger.
Perhaps it's not sufficiently differentiated, or your supporting elements don't feel fluid enough to take it over bar. Maybe your differentiator isn't as helpful as you thought. Could be any number of reasons.
But I'll leave that to you to figure that part out. Happy building, and hit reply when you're done. I'd love to check your project out.