How to Build a Scalable Minimum Viable Product
If I gave you unlimited funds, time, and talent, could you build a wildly successful product?
Wait. Stop. It’s a trick question. None of those things actually matter.
As recently as a few years ago, a startup could get away with hiring a crack development team to build a product from the ground up, based solely on a good idea. They would then test the market with a beta, tweak a few things, and go on to enjoy a successful release. That didn’t happen all the time. In fact, it was rare. But it happened.
The same strategy is just not possible today. Today, while not every product has to be software to be successful, almost every product must use software and data to measure and determine its scalability.
I’ve been building software products — as well as using software to build products — for over 20 years. I’ve built them the right way and I’ve built them the wrong way. Along that path, the conventional wisdom was always: “If we code this, we make money.” Turns out that’s almost never true. The truth is actually: “If we code this, we save money.”
Technology doesn’t sell a product, it only serves to make the product cheaper to scale. With today’s MVP approach, oftentimes the rush to market results in technology without flexibility. Then that technology fails at scale. So if you want to give your product its best chance at success, you need to build in maximum flexibility at the MVP stage. That used to be my competitive edge. Today, it’s a requirement.
The beautiful side effect of this now-mandatory flexible MVP approach is that it no longer takes a huge capital investment to build and prove a product, especially in software. Anyone can follow this approach. You can do this. And you don’t need unlimited funds, a time investment of years, or ninja-level hacker developers.
But you do need maximum flexibility. Here’s how to build that in from the get-go.
The Human Factor
As I write this, I’m bolting two new features onto an existing product, and if I do it right, we’ll have the beginnings of a direct-to-consumer marketplace for two new product lines. What hurts me most right now is that these two new features are killing my support team. They’re having to do things they’re not trained for, and they have to document each step in the process each time they do it.
But this is critical and, thankfully, temporary. I know these features are viable and have value. I already have that data (I’ve been collecting it for months, more on that later). What I don’t have is the tech to execute and deliver these new features through our existing systems.
Why? Because that tech, enabled now, would most certainly break several times a day. I’ve been doing this manually for a few weeks and I’ve already found a couple dozen ways the whole process can go haywire. If I’m not prepared for the tech to be flexible at those haywire points, everything will fall over and I’ll wind up spending a shitload of money to fix it and incur a ton of technical debt in the process.
So in the beginning stages, the support team executes and — this is important — documents everything that goes right and wrong. That documentation becomes the basis for the business requirements of the technical system. It won’t be unbreakable, it never is, but it’ll stand up to scale.
Now, I know what you might be thinking — “Hey, you have a support team, you have funding, you have options.” I understand this, but I’ve also played in the world where I don’t. And when I don’t have those luxuries available to me, it’s me. It’s all me. The support team, the documentation, the coding or the pseudo-coding. I do it.
Starting a company is not about putting up a website, creating a logo, and talking to influential people about what you plan to do. It’s about getting your hands dirty doing the stuff that will make and sell your product. And if you really want to take a whack at building a high-growth business, you have to do all the documentation and planning and thinking-through at the beginning.
The Data Factor
Before I put together the plan to build those two new features onto our product, I built a data collection system to pre-determine whether our customers wanted those things or not, then I collected a bunch of data, over months, to figure out how often they’d want the things, how much we could charge, and what our margins might be.
Let me rephrase that. The data collection system actually collected data on 15 different possibilities. The ones I’m building are the ones that made the cut. If I had built tech to accommodate all 15, it would have failed.
There are a lot of ways to collect data on viability and scalability, and the most manual (and cheapest) way is to ask potential customers and document what they say. The most accurate way is to build the kind of system I described above.
But data collection doesn’t stop with viability.
As I laid out before, I’m not only going to automate what my support team is executing today, I’m going to automate all the documentation they’re doing while they execute. I’m going to discover all the risky parts of the execution and build in back doors so when something does go haywire, I’ve got a pretty good chance of fixing it quickly.
And if I build the data collection systems properly, I’ll be able to catch those haywire moments before they actually happen.
I know, it all sounds like overkill, but this is why we entrepreneurs dream of big numbers, of scale, of serving millions of customers or at least millions in revenue from customers. It’s not about picking out which color Tesla we’re going to buy, it’s about making sure we can get to the promised land in the first place.
The Tech Factor
Developers are expensive and they always have been. This should come as a surprise to no one. But we often get a shock when our expensive developers build incredibly rigid code from our requirements.
I used to be a developer and I still code. And I’ll tell you the same thing today I would have told you 20 years ago. I’m going to build to the spec you put in front of me. So if we’ve built maximum flexibility into that spec via the human factor and the data factor, we’ve won half the battle.
That’s right, half the battle. There are some aspects of the technical part of the process that you should still own, and you don’t have to be a developer to own them. Here are some of those aspects, explained:
- Never use constants. Anywhere. What might be the norm today is not guaranteed to be the norm tomorrow. Even when it is, somewhere along the line that constant will break something further down the chain.
- Never store duration or counts, always use beginning and end points and do the math on the fly. In other words, don’t store the fact that it takes 32 minutes to do something, store the start time and the end time instead.
- Always make a table for choices, don’t use a static list. This is the same rule as the constant rule. If you’ve got three options for a choice that needs to be made, make a three-row table and store the ID in the original table. Better yet, store the chooser ID and the option ID in another transactional table with a timestamp.
- Never store transactional data with descriptive data. If your table includes columns like option_1, option_2, option_3, and so on, you need another table.
Those are the bare minimum. Just make sure your developers understand maximum flexibility, then get out of their way. The good ones will be like, “Oh, you want the code to NOT suck.” They might roll their eyes too. Let them. It’s fine.
Remember you’re not coding to make money, you’re coding to save money. You’re not building a jet, you’re building an ultralight. When the time comes to scale, it’s going to be much easier to harden the weak points than it will be to untangle the sticky points. And you’ll be thankful that you can pivot and reset with ease as you grow.
Hey! If you found this post actionable or insightful, please consider signing up for my weekly newsletter at joeprocopio.com so you don’t miss any new posts. It’s short and to the point.