Planning a proper MVP

So many founders screw up their first product by forgetting the definition of MVP.

It’s not about proving you’re the Most Valuable Player.

It’s about building the Minimum Viable Product.

When I first started building GoWild, we did a good job of planning out our launch into phases. Even then, I think we started with too much.

Today I’m going to break down the risk of building too much product for a launch, and share some tips for thinking through your first build.

First, pucker up

We are planning a new product launch right now for Holler Commerce. Holler is a product we’ve created from our tech at GoWild, so we know what’s possible and generally have a good feel for this build. Even then, I’m having to remind myself and the whole team that it’s critical we live by the KISS rule:

Keep It Simple, Stupid

You’re only stupid, in this case, if you don’t keep it simple. Shooting for a robust product launch has a few problems:

1. Delayed launch
   The more you pack into a launch, the longer it takes to start getting traction.

2. Delayed data
   When you delay launch, you’re not only missing traction, but you’re missing out on valuable data you could have from early users in terms of product performance.

3. Making the wrong bets
   The deeper you go into a build, the more you’re betting on yourself to make the right bets. The data will often prove your hypothesis wrong.

4. Falling in love with the wrong product

   Founders are often guilty of falling for their own product and missing the signs that a product is not working. The longer a product lives in testing and not the real world, the more likely it is that you’re setting yourself up to be your biggest fan (ahem, not good).

How to plan your MVP

Let’s talk about actually planning an MVP. I’m going to share my notes from our current Holler product as an example of how we’re doing this real time.

Step 1) Solve for your customers’ pain

When planning your MVP, it’s key to strip your product down to a really simple product with just the basic functionality. To avoid problem No. 4 above, it will help to talk to prospective clients or users. Don’t be afraid of going super niche on the MVP, either. It’s not only OK to have a hyper specific client in mind, it is good. As you’re talking to this audience, don’t pitch them on your product. Have a line of questions for each conversation, and try to find their pain points.

Once you have this anecdotal data, solve for the specific problems of this niche group. You likely uncovered problems that you can’t solve with an MVP—focus on the core issues within this exact user group.

Holler’s Example: For Holler, we saw a prospective problem among creators (influencers, YouTubers, bloggers, etc.). It seemed that affiliate marketing was falling short for them. We had a product idea, but before we started building, we talked to the creators we worked with to ask them about their pain points with affiliate marketing, and launching their own shops. We found a few problems we hadn’t identified yet and are now planning products to solve for those pains. 

Step 2) Plan, design and build lean

If your team is not familiar with living in Startupland, this might be a challenge. Team members from large corporations or agencies may not be comfortable with the idea of launching something that’s possibly broken or not perfect, but that’s exactly what you have to do. And you have to do it fast.

Every month that passes and you’re not live is a month where you’re not collecting real data from users or customers. If you build for perfection based on your hypothesis, there is a really good chance that you swing and miss, and depending on your company’s runway, seasonality, or market conditions, you may not have time to get another at bat. The key is launching fast so you can unlock the power of real user activity.

Holler’s Example: We have product features (and even some designs) for features that we will be building for the next 18 months. We can’t hold back the launch for many of these features, because we need the core product to be live so we can start building traction, monitoring our unit economics, and improving the product. In our product reviews this week, we’ve cut at least two major components of the product because they are complicated, needing time to think through the logic. We will launch those in later versions. 

Step 3) Find users to make the bug pool shallow

As you’re building your beta/MVP product, start building interest in what you’re doing by tapping into niche communities who align with your audience. Build a Google Form out that you can send to anyone who seems like a good fit, and have them sign up for a chance to test the beta product. We did this with GoWild and beta tested the app with 100 people in the summer of 2017.

This approach gave us a batch of hardcore users, tapping into the “1,000 true fans” theory, and it helped us find bugs we would have never found in internal testing. There is a saying in development that “nothing makes a bug pool shallow like users,” meaning you’ll find and plow through the problems in your product much faster when you have users who help you find them.

Have a process for documenting feedback from your early users, and have a team member in charge of creating tickets for each bug, and assigning priorities to each ticket. The truth is you’ll get bugs that are such edge cases, they aren’t worth fixing. But if you don’t document these problems, you’ll get 90 days past launch and have a collection of email complaints and no idea where to start on fixing the problems.

Holler Example: As we are working on our new creator product, we’re actively collecting beta users, just like we did in 2017 with GoWild. Each of these beta testers will be onboarded via the product’s standard dashboard, then we plan to meet and do interviews with each creator to get feedback on the product. 

Step 4) Iterate on the high impact suggestions, forget the rest

If we took all of the suggestions we’ve gotten for GoWild over the years, the app would be a mess. Someone has to review the ideas and decide what’s going to happen, and most likely, dear founder, that someone is you. If not you, it’s whoever is acting as the product owner. As you wade through the suggestions, balance the feedback that is going to improve the product’s retention, and also help you grow. If a feature is a “nice to have” but not contributing to retention or growth, it’s not getting built.

Holler Example: We’re already getting requests to do Holler in verticals that we’re not operating in. We are not bending our plans to launch in beauty, pets or golf until we’re ready. It’s critical you remember this is your product, and your business. You have the plan, you know the goals. If you let users tell you how to build your company, you’ll end up with a Frankensteined product that’s trying to appeal to everyone instead of solving a niche audience’s problem really well. 

A tremendous real-world example

Some of you may have noticed that months ago, I switched my newsletter from Substack to beehiiv. The beehiiv team is the best example of launching lean and scaling fast that I have ever seen. They are truly in touch with their customers, talking to writers and finding opportunities that Substack and all of the other newsletter companies are ignoring. beehiiv launches more products than anyone I’ve ever seen, and I’m willing to bet we’ll see them sunsetting products as they find they don’t fit. Tyler, the CEO, seems to be a bold leader who isn’t afraid of making the hard call of scrapping a product to keep a product in sync with his target audience.

Recap: 4 tips to building your MVP

Step 1) Solve your customers’ pain

Step 2) Plan, design and build lean

Step 3) Find users and have a process to digest their feedback

Step 4) Iterate on the high impact suggestions, forget the rest

Who I’m listening to: The Eagle Rock Gospel Singers

What I’m reading: “Elon Musk” by Walter Isaacson

Follow me for mid-week updates:

LinkedIn | TikTok | GoWild | Twitter | YouTube