12 Mistakes Building Your MVP (and What To Do Instead)

I’ve built dozens of MVPs, some were brand launches at Google, some startups that raised $3M in funding, and some productivity tools I conceived that got acquired by bigger companies. Here’s some of my hard won knowledge about building a product from the software perspective.

1. Not Hyper Focusing on a Single Problem and Demographic
You’re brand new. Your goal is to find a tiny group of similar individuals that can’t live without your product. They must love it, solving a pain point in a novel way. Don’t go broad market, you’re not going to compete with Google or any major incumbent by trying to address their whole market. Get hyper specific to a dedicated demographic. Then build for them, a MLP — minimum lovable product. Get die hard fans, and then broaden from there.

2. Building Everything Bespoke
You need to stand on the shoulders of giants. So much software has already been built in the open source community. Take it for free, and reapply it to your use case. If you worry about licensing concerns and build like Google, others will beat you to market. Build your audience first with a killer product that steals from libraries, services, and other projects as much as you can. When you have paying customers and VCs behind you, then you can worry about building bespoke.

3. Outsourcing for the First Time
If you’ve never hired a dev shop or contractor before, it’s very difficult to align incentives and communicate product direction. Engineers communicate in a different language, literally, so finding someone who is mission aligned as well as technically trained is key. You can find a PM, but there is a reason CTOs have a broader impact in their business alignment.

4. Not Building Something Polished and Lovable
You want to build as minimally as possible. But it has to be lovable. It has to be polished. If your main user journeys have hiccups or even blocking bugs, you cannot launch. What you show to the world has to be clean and professional. It’s easier to do this when you limit your feature set to only the most important. This doesn’t mean obsess over every color or button placement, but it does mean follow general UX principles and do user acceptance testing before launching.

5. Waiting for an Equity Technical Cofounder
Many companies wait indefinitely for a technical cofounder for equity. They refuse help until the perfect software executive shows up to work for promise of future earnings. As a first time entrepreneur, it is hard to have enough clout to attract someone of this pedigree. So many of the people capable of doing this work are making over half a million at Google for a 20 hour work week. The risk is too high for a CEO who is untested. Instead, you want to build a fast and dirty prototype and start gaining traction: user buy in or investment from angels.

6. Trying to Raise Funding without a Prototype
“Ideas are worthless,” is common wisdom that captures that execution is paramount. Bringing an idea to an angel or VC is not going to be compelling. Even wireframes and promises from partner companies is not convincing. Second to paying customers, a working demo or prototype is the most important thing to show an investor. It proves you can build something defensible, and gives the best flavor for the product direction. It can show a simple feature and not even be deployed, but it is real, and can be touched, interacted with. That’s powerful.

7. Preparing for Major Scale Prematurely
MVPs have to be nimble. They change so rapidly as you hone in on product market fit. Don’t build a huge testing suite, security protocol, and robust backend prepared for a million users on day one. All this adds bloat to the code base and makes it harder to pivot. It also slows down everything, the process is extended, and your time-to-market increases. Best is the enemy of good. Don’t let your competitor pass you by iterating quicker, because you launched a perfect version too late.

8. Building for All Platforms
Don’t build for android, iOS, and web all at once. Mobile web is a great choice for a lot of new products. But if it’s not viable for your application, find ways to make it work, whether it’s react native, or some hybrid solution. Similar to not scaling too early, don’t assume your initial features will be your final ones. Build great for one platform, and see the response, then you can intelligently expand.

9. Waiting for It to be Perfect
Do polish the MVP, but don’t make it your baby. It has to see the light of day, and be pushed back against by real users in the real world. Again, speed to market fit is key, and you want to get real user feedback asap. Friends and family will always give biased feedback, even if just by the nature of them having similar worldviews to you. Get it out there and learn.

10. Building Duplicate Features of Competitors
For your first version, don’t compete on anything. You want to be completely unique to find your value prop. In the future, when you have loyal customers, you can broaden and sell similar products to incumbents, but you won’t build loyal followers with anything that already exists in the marketplace. Build only unique features, and you can point customers to the best alternative for the other needs. Build them later.

11. Building Unwanted Features
Don’t build things people don’t want. If only it were that easy. But you can employ “painted doors” to see if users want a feature before wasting cycles building it. A simple example is to create a checkout page for a product that doesn’t exist. When someone clicks “purchase”, you can redirect to a message that says you’ve recorded their contact info to get in touch when it’s ready. It’s a way to conduct market research and create excitement for a feature without spending engineering dollars on it.

12. Worrying Too Much Over Choice of Tech Stack
Most apps can be built in a number of languages, and the incremental improvement of one over another is minimal. Choose a popular language stack like python or node and get working. By testing and obsessing too much, you risk delays and wasted energy on something relatively trivial. Make sure your stack has abundant resources to hire that are proficient in it as well as lots of community support and open source tools.

BONUS: Not Staying True to Your Vision If you overfit to the feedback of a small handful of users, you risk making them happy and alienating your chosen demographic. You want to listen hard to feedback, but seek to understand the problem, not take the solutions given by the users. They don’t know how to solve their problems, or else they wouldn’t be turning to your product. You’re the creative product builder, so you must stay true to your demographic and build for the market you chose for your business.

If you want some guidance navigating these pitfalls and many others, reach out, and I can help you build a defensible MVP on budget.

Original article posted at https://mvpengineer.com/12-mistakes-building-your-mvp-and-what-to-do-instead/