You’re a bright young software developer in a tech slump. You have an idea to disrupt big dog-wash and have built an app to give the power back to pet owners. The 9-5 hasn’t paid a raise in the last 2 years and pickleball court rental fees only keep rising. You’re ready to launch your minimum-viable-product (MVP), you just need to, y’know, make it available and start charging. Should be easy, you’ve built your product. The rest is just marketing.
Minimum. Viable. Product. MVP. Viable - you want to put out something that has a shot of making money. If it’s not viable, it’s a tech demo or a toy. Not a product. How do you know your product is viable? Hopefully, you’re either talking to customers like it was your job (because it is), or you are the ideal customer and you’re building something for your own needs and you think others like you will pay money for it. You don’t really know though - that’s why you build the minimum amount of viability. You’re not really launching a product, you’re starting a long running experiment where you try things to see what works.
As with any experiment, you need data to make conclusions. “I think the reason nobody is buying is because the app is too slow. I’m going to spend 3 months refactoring the internals to make it faster.” is a great conclusion if you have the data to show your conversion rates are good, your churn rate is crazy high and your telemetry shows an average page load time of 5 seconds. Not such a great conclusion if your users are bouncing at sign-up and you’re not even getting trial users. If a page load takes 5 seconds and nobody’s around to read the result, did the page really load?
Except your MVP as-is isn’t instrumented. You have no way of knowing why your experiment is doing poorly - even if it’s doing well, you don’t know what knobs to turn to make your product better. The feedback loop on these kinds of changes is slow - you can’t be making random changes you hope will help. You won’t even know for at least a month if those changes helped, and if you were wrong it’s another month to correct back to where you were. So you pick some kind of instrumentation service or library and integrate that. Now you can see data on how it performs, where problems are, and get proactive reporting on errors.
Ok, now you’re ready to experiment. It should be as simple as getting a build together, making it available online and charging people for it. Hmm, charging for it. That’s something else you should probably set-up and figure out before you can really “launch”. It’s implied in the P of MVP. Maybe you know how to accept payments from credit cards online already, maybe you don’t and you need to research it. You hear about Stripe, Paypal, Woocommerce, Shopify. Hosted store front or REST API integration. Webhooks. Iframes.
Your leads need somewhere to make a decision about purchasing your product. They need to see a price, and they need to be able to safely and securely send you credit card information and payment details. Maybe you host it, maybe you just go with a store front on someone else’s website and decide that building your own brand can come later. Regardless, you need to make that decision and set that up before you can launch.
You’re ready now, right? Lets do a quick overview of the checklist of things we have. We have a product, we have a way of tracking the results of our experiments and collect data, and we have a way of asking users for money (and getting it) to use our product. Great! Let’s go!
You start to put together your product and make it live. You hook up your data monitoring, and you set up a store where users can access or download your product. It’s live! You’ve launched! You run a test transaction through your store, and download your product, or get access. You put access controls in right? To ensure that unauthorized users can’t use your product if they haven’t given you money - right? Your users can’t just send a link or a copy of your software on a USB to their friends and let them use it, right?
Downloadable products need some kind of verification that the user using it has paid. Online services need user accounts, and provisioning on payment, and things like that. Otherwise you might see your usage metrics nice and high and be bleeding money through your expenses, because nobody is giving you money for your product. Some products that are local and have a hosted (cloud) component need one or both methods.
While it’s easier to build this stuff into your product right from the very start, it can be something you easily gloss over in the excitement of building your idea and making it available for sale. If you already built it, great! Log in or provide your license key and get using! Otherwise, you’ll probably need to pull that MVP down while you build out that functionality. Or delay your launch while you implement it because you found the gap before you lost any money.
Where were we? Oh, your MVP that’s ready to launch. You have auth/licensing, monitoring, and an online store front to sell through. Let’s do this again. You put your MVP back up to be available, test a transaction and download your software. So far so good - now to turn the tap on your marketing on to sell this thing.
Starting your product or logging in, your daydreaming about the future wealth you’re about to come into is rudely interrupted by an error. You have a bug. Not surprising, and these things happen. Paying users are understanding and will often figure out work arounds. You can just fix it and push an update.
If you’re running a hosted service, this is easy. Just update the code that’s running on your server and restart it. Everyone gets your new version with the bug fixed. Having a downloadable component, such as a client or the whole application complicates things a little. You either have to have your application ask a central server for an update (automatically or at the behest of the user), or proactively ask your users to go and update their software.
You either need update functionality in your product, or you need the ability to contact your customers and tell them to update. You have a mailing list that comes from your customer DB and allows you to run marketing campaigns/transactional emails, right? Did I forget to mention that earlier? It’s ok if you don’t have that as long as your product can update itself. Oh, you didn’t do that either?
More downtime. Maybe you pull the product from the store again to triage this problem and stop it from growing. Maybe you fix it while you’re flying the plane. Either way, it’s not going to be a thing you can fix or do instantly, and it’s going to annoy your customers. You’ll probably need to offer partial refunds, or discounts, or some kind of incentive to keep your users. You’ll also need to be able to tell them about it, and explain why it’s happening.
Best just to do this before you launch. Now we’re up to a product, a store, a means of tracking data, auth/licensing, update functionality, and/or email or customer contact functionality. Is that it? If you’ve been following, you’ve had to pull your product twice now. It’s cost you lost revenue, lost users, and the trust of those who stuck around. That’s bad. Is there anything else you need to do to get ahead of it? What happens if users have problems with your product and need help? Do you have customer support solutions, at least an email address your users can email questions to and get help?
Let’s say someone is interested in working with you in a non-consumer capacity - some kind of enterprise custom deal, an integration, something unusual - can they contact you?
Is there anything else you can think that might come up?
Your Titanic has been hit by the MVP iceberg.
Unfortunately in 2024, the reality is that MVPs still need quite a lot of functionality and features that you might not think of, and might not even be interested in pursuing. Back in the 90’s you could get away with a CD that you mailed people and your trusty @att.net email address. These days, branding is important, user experience is important, and internet consumers are generally more sophisticated and critical.
It’s easy to get swept up in the excitement of finalizing a project, especially one that you can see a pathway to revenue with. It’s easy to forget these things and it’s hard to figure it all out once you’re asking for money and angry people are emailing you all day. Way easier to take a step back, think, and figure out how big that iceberg is before you try to navigate around it.