How to MVP
For my first startup, I spent nearly $500k on our MVP. Yeah, crazy. But I was brand new at the startup game, and I had a cool idea. I just knew it was going to be “a game changer” and totally “disruptive” so I took all the money people threw at me and started building my dream application right off the bat.
I thought I knew exactly what I was doing. I really didn’t.
Things happened, launches failed, feelings were hurt, we somehow pulled the biz out of the crapper and sold it for parts and made a tidy sum. Even so, I learned a few lessons, and one of those was how to build an MVP.
Here is how:
1. Use off-the-shelf technology
I’m not kidding, and I don’t care what an awesome developer you are, how full your stack, how savvy your UX, or Behanced your visual design. If you’re diving in that deep on the MVP, you’re building a beta.
There’s great tech out there free to use or at minimal cost. Don’t build from scratch. Don’t reinvent the wheel. Why pay for it when you can steal it?
Don’t pay expensive bespoke costs when there’s perfectly viable solutions already built, tested and ready to go. Get out your gum and string and patch together what you need. An MVP should resemble Frankenstein, not Glinda.
People who are bootstrapping will understand this concept. When it’s your own money, you’re pinching that penny pretty hard. That’s a good thing!
2. Don’t build a beta
Look, development is expensive. And it’s time consuming, and goes easily off the rails. You don’t want to be yet another train rushing straight into the graveyard of railless tech startups.
For one thing, you need to understand your business model before you build a beta. If you don’t, your technology is leading your business — which probably means you’re a solution without a problem.
Iterate on your business model first, to figure out what customers want. Then build the beta and call TechCrunch.
3. Even off-the-shelf is better than a paper prototype
On the other hand, you should be past the prototype stage when you’re MVPing. This puppy should actually run, wiggle and pee on the floor.
Your launch partners should be able to use it — even if it’s painful. The business should be functional, if barely. This isn’t the idea stage, this is the doing stage.
Full disclosure, this is the stage where I generally go wrong. All those glaring problems with the app…for a designer, it’s like sticking a fork in the eye every time I look at font that’s not readable, copy that makes no sense, user paths that flow into the vortex of death.
I want to fix it all. Somebody tie my mouse hand to the chair.
But don’t fix it.
At least, don’t fix anything that’s going to cost money. Anyone that’s worked at a big tech company knows how much bad UX is in use every day, by millions of people. It is done. You’re not a wannabe because you haven’t updated the UI to last week’s visual styling. If Google doesn’t feel the need to fix their crappy app interfaces, you can control your impulses, too.
Act like your frugal uncle and refuse to spend a dime where you don’t have to. Muddle along, hold hands with your launch partners, beg forgiveness from your customer.
Be vulnerable. Explain why the tech is so hard to use (they’ll get it). Ask for helpful suggestions about how to improve it (they’ll love to tell you). But don’t pay to fix usability issues until you know whether your business model is functional.
4. Fix your Business Model Instead
The business model is an MVP too. Think on that. It’s where your head should be at this stage of the game. Do user research about business process instead of technology functionality.
Now is the time to put on your anthropologist’s pith helmet and go out into the field. Shadow your clients. See what frustrates them and what they don’t seem to mind. You’ll be surprised. It won’t be what you thought it would be. Pay attention, don’t be distracted by fun plugins and “wouldn’t it be great if…” thinking.
Instead, focus on how the business is working, and fix how the business is not working. But take a lot of notes on the technology — because this is the data you’ll use when you build your beta.
5. Write a PRD
Once you’ve got customers and clients you can start writing your product requirements document for the beta.
Things will move pretty quickly at this point. You’re running a functioning business — even if there are only 3 clients and 5 customers. It’s still a business and you can see how it’s working. You’re starting to get some data points to use as benchmarks for the beta launch. NOW you may finally start work on the real tech. Your super awesome, amazing solution to a real world problem.
So have at it. Just remember to use all the data you gathered during the MVP stage to inform your dev decisions. Congratulations, you’re already a year and a half ahead of most founders!
I am an entrepreneur, UX strategist and the founder of Rits & Co. I understand the challenges of building product design teams and establishing UX processes. My most recent MVP is about to launch!
