SitePoint Weekly: Minimum Differentiable Product

Deno's built-in tools, Node's Event Loop, a new way to do bootable USBs, and can we improve on the MVP concept?

No images? Click here

SitePoint Weekly – 25 August, 2020

🍓 The freshest resources, stories, and exclusive content for web developers, designers, and digital creators.

Pointed Advice

🦾 A selection of our latest articles and tutorials

How to Use Deno's Built-in Tools
Craig Buckler

One surprising difference between Deno and Node.js is the number of tools built into the runtime. Other than a REPL console, Node.js requires third-party modules to handle activities such as testing and linting. The Deno built-in tools provide almost everything you need out of the box.

The Node.js Event Loop: A Developer's Guide
Camilo Reyes

Gain an in-depth understanding of the Node.js Event Loop. Camilo Reyes shows you how it deals with the problem of multiple threads and manages context switching, with code examples.

React vs Angular: An In-depth Comparison
Pavels Jelisejevs

Our React vs Angular guide has been popular for years. It's now popular and updated for 2020. Don't make current year decisions on 2019 information! If you have a tech choice to make for an upcoming project, this is the guide for you.

Get Cloud Certified with ExamPro's Smart Learning Platform
Andrew Brown

Cloud certification exams are challenging, and involve retaining large quantities of technical information. They also open up significant new doors for career advancement and learning potential. ExamPro uses spaced repetition and AI techniques to solve knowledge retention.

🥳 Win a $100 Amazon gift voucher

We''d love to get your help. We want to understand our newsletter readers and the technology choices you make, so we can connect you with the most useful resources and content.

This is the final week of our newsletter reader survey! Take a few minutes to provide your thoughts and enter the draw to win a $100 Amazon gift voucher.

➤ Fill out our newsletter reader survey

Platform Problems

🍕 Web development and technology links from around the web

Rust Belt
Web development, design, and tooling

Garden Leave
Computing, productivity, personal automation, and desktop customization

Flight of... Fancy?
Technology news, society, and culture

Apple's efforts to further entrench itself in value chains it has no business entrenching itself in have continued since we last spoke. Firstly, there's a very interesting split decision here on an injunction filed by Epic — Apple is not permitted to block Unreal Engine, though it isn't being required to reinstate Fortnite. The judge's thinking is particularly interesting and I recommend taking a look at the story.

Another story broke over the weekend and we discovered that Apple had taken issue with the WordPress app. It had found a path to a page that mentioned WordPress.com plans in an unreleased update, and asked Automattic to provide IAPs. Automattic wanted to remove the page. Apple didn't want that solution — they wanted the IAPs. You can read more on that situation here. Apple relented, but that's a result of the reach that Matt Mullenweg and Automattic have. Apple's usual defense of its policy – that businesses on the App Store have succeeded because of the services underpinning that App Store — is ludicrous to consider here. WordPress is an open source poster child that significantly predates the iPhone and powers 38% of sites on the open web.

I ranted about Apple's behavior here last week. I don't want to repeat myself more than I already have, so I will leave it at this: a $2 trillion valuation is a very large number. Apple is clearly a Goliath. But it's no more invincible than the O.G. Goliath. Entities we considered too big to fail do fail on a regular basis, and all we really want to do is elbow Apple in the ribs and tell it to stop being a prick. There is looming uncertainty over its position in China, which is about as close as a company with a cash reserve that makes Scrooge McDuck look broke can get to a period of reflection. Between all of our credit cards, we have slingshots.

I spent some time on the weekend moving any App Store subscriptions that could be shifted to a direct developer relationship over to one. I suggest you back your fellow developers and do the same.

♾️

Land in our DMs with those 🔥 links.

Found a link you think would look great in the next issue of SitePoint Weekly? Did you perhaps even create it? Drop it here and we'll take a look.

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.

Connect with the community

We'll see you in the next edition — in the meantime, connect with us for a chat through our various communities or on social media:

🛳️ If you'd want to share the newsletter with your friends, we've created a shareable signup page just for them (and we love you for sharing it).

Thanks for reading, and for being part of the SitePoint community!

👋

Joel Falconer
Managing Editor