MVP = embarrassing • Go Code Colorado


“So, we need this feature to work, and it has to tie into this API, and we should put it all on the blockchain.”

“What about feature X? And we need admin screens, and roles and groups for different kinds of users.”

“You’re right! Let’s add those to the list. We need to make something we’re proud of.”

I heard some version of this conversation over and over again at my last Go Code Colorado mentoring session. And I sympathize with the sentiment, I really do.

But instead of hitting it out of the park the goal should be to create a piece of software that achieves the bare minimum, or a minimum viable product (MVP). With a high-risk venture team members should aim to show features to the end user as soon as possible, and to let their interactions guide the future of development.

It’s far too easy to get distracted by all the possibilities and build features that won’t be used. Even worse, developers may compare their application to other applications they use and find it wanting. The level of polish an MVP needs is far lower than a production application like Gmail, but because you use production ready apps every day, their UX and polish can feel like a requirement. Building features or adding UX polish can delay shipping an MVP. You want to wait until you are “ready”.

You are never “ready”, my friend.

“If you’re not embarrassed by the first version of your product, you’ve launched too late.”

Reid Hoffman, LinkedIn Founder

Keep your focus not on the software but on the user.  Spend time talking to your target market and putting either mockups or working code in front of them as frequently as you can. Finding these people is another blog post entirely, but hopefully, you have some idea who they are and where they hang out.

It can be scary to put what you’ve built in front of people. It’s often much easier to sit back and build new features than it is to ship. I have felt it myself–as a startup co-founder, I built a web app that I was, frankly, embarrassed to show potential customers. It was missing features I considered crucial, was full of holes and bugs, and didn’t have a consistent user interface.

But showing it to potential customers early and often was the best choice. They pointed out missing features and also explained what was unnecessary. We got great feedback and I was better able to understand the types of problems the customer faced.

There are many ways you can show potential users what you are planning to build or are building without having a fully finished product.

  • You can show them mockups, either a paper draft, a series of powerpoint screens or a clickable prototype (Adobe XD or Balsam IQ are solutions). This is the cheapest way to get feedback because changing a screen in powerpoint is far easier than changing a screen in code.
  • Enroll potential customers in a beta program. Customers are more forgiving if they know this isn’t the final product, and they’ll give you suggestions. Don’t take each suggestion as truth, but do try to find out what problem the suggestion is aiming to solve–that’s gold. Offer people in your beta program a discount when you start charging–that gives them the incentive to give good feedback and can seed your customer base.
  • Build out mock features. Instead of building a full file upload facility, I have added a screen to an app with a link to “email us to add a file”, and fulfilled it manually. If enough people mailed a file, we’d know we needed to build the feature.
  • Have someone walk through the application in a video chat (using GoToMeeting or Zoom). Similar to a beta, people are more forgiving when they are shown something and you will be able to see where issues arise (“how do I do task A?”). This experience can be humbling and frustrating at the same time, like watching this: https://imgur.com/GpWZtCn

When building an MVP, use tools you know. Whenever I’m working on a project, I balance technical risk and business risk. If you’re building a true MVP, the business risk is very high, because you don’t know if the market actually exists. Therefore, minimize the technical risk by building with what you know.

But wait, aren’t customers expecting a polished application?

Some may. Early adopters who are looking to have a problem solved often can look past the rough edges and see the potential. It also depends on the domain and the competition. For instance, if you are starting an Instagram competitor aimed at consumers, the quality bar will be pretty high. If you are building a scheduling tool for tattoo parlors and your main competition is a spreadsheet, a web application built with any modern framework will likely wow your potential customers. It’s also important to show your customers that the application is continuing to improve–that will make them more forgiving of the inevitable issues.

You’d be surprised by how forgiving people can be, especially if you are building something to help them do their job better. Remember, if you aren’t a little bit embarrassed when you show someone your application, you should have shown it to them sooner.

Dan Moore, Director of Engineering at Culture Foundry and Former Go Code Colorado Mentor

Additional resources: