Your MVP Sucks and It’s OK

We were sitting alone in a big, wood paneled conference room. This was the moment we had been waiting for, the vindication that our solution would upend decades of broken talent assessment and job matching to unleash a new era of workplace productivity!

We traveled to the client site to gather feedback on the first client implementation of our startup's HR analytics platform. We had secured a paid proof-of-concept weeks earlier based on the strength of our demo and strong alignment on customer needs. Now we waited for the initial results.

The client project team entered the room, and after an initial round of greetings, the program leader opened the meeting with, "I hope you like feedback!" Over the next hour, we received plenty of feedback, just not the type we were expecting.

Many of these comments are still seared into my mind years later. We heard things like, "The website was so slow, it took me four hours to complete the survey". The UX garnered a lot of attention with comments such as, "I had no idea what I was clicking on or how to proceed”. Then there was the handful of comments that could be best summarized as, "This is the dumbest, most pointless shit I have ever had to endure”.

After the user feedback, we then moved onto observations from the project team. None of the commentary was positive other than the fact that we were very accessible when problems arose. It was such a thorough and complete failure; I started imagining that under our chairs were trapdoors that would open and send us into a pit of ravenous sharks. But no, we had to endure a worse fate. The customer forced us to continue on and fix all of the software issues.

I do not believe anyone builds anything with the intention that it will be terrible. When we are just learning something, we do not expect what we create will be amazing whether we are doing art, cooking, music, or coding. We do however have pride of ownership and in the process of building. Unless someone is completely without skill or has no taste, generally what we create gets better over time and iterations.

This is what makes the process of creating your first startup product so painful. When we launch our product, whether on Product Hunt or with a small group of design partners, we are hoping that users see the blood, sweat, and tears we poured into building a valuable solution. We want customers to say that our product was exactly the thing they had been searching for to solve their problems and save the day. Instead, we get torn to shreds and exposed as morons.

The path to creating an MVP, or minimally viable product, is one built on layers of assumptions. Unlike software built inside companies that is guided by requirements gathered from existing customers and focus groups, a startup has little to go on other than the experience and taste of its founders. There are no existing customers to ask, prior software versions to build from, or neatly compiled feature requests. The product you are building is simply a best guess at what customers may need, what they think, and how they navigate.

Reid Hoffman, founder of LinkedIn, shared a quote many years back that has now become part of startup canon:

Many founders misunderstand the intent behind this statement. They thought he meant that startups should launch ugly, barely functional MVP's or to act recklessly to push an incomplete product to fool customers.

Reid later expanded on his original quote to highlight three reasons why being “embarrassed” is good:

One other point is that you should know enough about the customer and problem space to build a “viable” MVP. What customers cannot tell you though is what the solution looks like. That is the job of the startup founder to turn vision into a solution that a customer can use.

That is core challenge, taking something ambiguous and making it tangible. As the Henry Ford* saying goes, if you asked customers what they wanted, they would say “faster horses” instead of an automobile which seemed out of reach at the time. This is why Reid emphasizes launching and shipping quickly, getting and acting on feedback continuously, and allowing that motion to guide startups from lots of wrong assumptions to a validated product.

However, the process to go from a basic MVP to a highly adopted and valuable product is a long and winding journey full of potholes and detours. As Garry Tan, CEO of Y Combinator, recently shared about refining a product to be valuable:

His analogy was that of sanding down the sharp edges of the product, the aspects of the design and flow that get users stuck. It takes many iterations to sand down those edges so that users can smoothly use the product. In order to do that though, you need to start with a product that is simply going to suck because your assumptions were wrong.

In the case of my first startup, it took at least six months to build and refine the product to be usable enough to show value. In the case of enterprise software within a Fortune 500 company, that was record time, but we were maniacally focused on building a product that we could sell and ensure our startup could survive. We were fortunate though to have an executive sponsor that believed in our vision, had a burning problem to solve, and saw the long-term value of our solution.

As I start the journey with my second startup, I am once again thinking about the starting point for an MVP. I break is down into these key questions:

• How deeply do I understand the problem space and customers?

• Do I know or have access to customers that have that problem?

• Is there a clear & logical path from the problem to my solution?

• Can I articulate one feature that brings immediate value to customers?

• What is the simplest way to demonstrate that feature to customers?

• Which customers can I depend upon to support the journey early on?

• What unknowns and assumptions do I need clarity on?

These are guidelines to help me think about where to start, but of course you may have other questions that will help you in starting your MVP. One thing that does not change in the process of building and refining an MVP though is asking at each step along the way whether what you learn from users brings you closer to or further away from your vision and viable product. If your current MVP is not helping you to learn new things towards your vision, it is time to take a different path and start over.

What is your mental model for guiding decisions on building an MVP and how do you collect and process the feedback you get from customers?

Mark Birch

*Henry Ford never said this, but the quote was attributed to him many years later.

It was simply packed last week, which is why this newsletter is coming out on a Tuesday rather than my regular Friday schedule. I landed in Asia Monday night, flew to Jakarta for Tech in Asia and a few demo day events for the Bali Investment Club & Antler as well as Appworks & Tinc (Telkomsel Accelerator).

Then I hopped over to Taipei to pitch at the first AiSalon event in Taiwan! It was a mad rush to get there on time from Jakarta, but I made it and delivered an OK first ever pitch of my startup (more details to come soon).

I am in Hong Kong this week to catch up with investors and fellow founders during HK Fintech Week. Then next week I fly over to Cape Town, South Africa for the AfriLabs Annual Gathering 2024 from November 5th to 8th. AfriLabs brings African innovators, investors, startups, policymakers, and thought leaders from around the globe together to collaborate on solving problems through technology across the continent. I will be speaking on one of my favorite topics, how startup ecosystems can contribute to creating globally scaled startups.

If you are around this week in Hong Kong or in Cape Town next week, it would be great to meet!