{"id":3725,"date":"2026-01-10T16:31:18","date_gmt":"2026-01-10T22:31:18","guid":{"rendered":"https:\/\/www.mooreds.com\/wordpress\/?p=3725"},"modified":"2026-01-10T16:31:18","modified_gmt":"2026-01-10T22:31:18","slug":"mvp-embarrassing","status":"publish","type":"post","link":"https:\/\/www.mooreds.com\/wordpress\/archives\/3725","title":{"rendered":"MVP = embarrassing"},"content":{"rendered":"

This is a re-post of an article I wrote in 2019 for the Gocode Colorado blog<\/a> which is no longer available. Thank you Wayback Machine<\/a>!<\/em><\/p>\n

“So, we need this feature to work, and it has to tie into this API, and we should put it all on the blockchain.\u201d<\/p>\n

\u201cWhat about feature X? And we need admin screens, and roles and groups for different kinds of users.\u201d<\/p>\n

\u201cYou\u2019re right! Let\u2019s add those to the list. We need to make something we\u2019re proud of.\u201d<\/p>\n

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.<\/p>\n

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.<\/p>\n

It\u2019s far too easy to get distracted by all the possibilities and build features that won\u2019t 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 \u201cready\u201d.<\/p>\n

You are never \u201cready\u201d, my friend.<\/p>\n

If you\u2019re not embarrassed by the first version of your product, you\u2019ve launched too late.<\/em><\/strong><\/p>\n

– Reid Hoffman<\/a>, LinkedIn Founder<\/strong><\/p><\/blockquote>\n

Keep your focus not on the software but on the user. \u00a0Spend 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.<\/p>\n

It can be scary to put what you\u2019ve built in front of people. It\u2019s often much easier to sit back and build new features than it is to ship. I have felt it myself\u2013as 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\u2019t have a consistent user interface.<\/p>\n

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.<\/p>\n

There are many ways you can show potential users what you are planning to build or are building without having a fully finished product.<\/p>\n