Goodbye MVP, Hello v1

You’ve done it!

It all started with a simple concept and two friends in your garage. After weeks of coding and tweaking, you’ve proven that your business idea is the greatest thing since sliced bread. You used the Build, Measure, Learn cycle to find out what your customers want, and you’re pretty sure you have a product market fit.

Now what?

It’s time to build your v1. In this post, we’ll look at how to take the most important lessons from the information you’ve gleaned during the MVP stage of your product’s lifecycle and apply them to building the first full release of your product.

V0: Minimum Viable Product

If you’re interested in building the v1 of your project, you’ve probably already spent a good amount of time iterating on features, measuring customer feedback, and learning more about what the market wants in your problem space. If you haven’t started building an MVP, or are still working on it, check out my thoughts on MVP and come back to this article when you think you’re sure your product is ready to be scaled.

If you have been using an MVP process, and you feel that you’ve validated your assumptions—that people would like to use and pay for your product—you’re probably ready to start thinking about building your v1. It’s time to take all of the metrics and feedback you’ve been gathering and put it together to make the first complete version of your product.

Before we continue, make sure you’ve answered these questions:

What is your target demographic and platform? What features have resulted in the most clicks and positive feedback? What features make up the core of your offering?

With all of these things in hand, let’s turn our attention to what it takes to release a v1.

v1: The Final Frontier

If you think about it, v1 is kind of a funny concept.

If you’ve been releasing MVP features for a while, you probably already have a functioning product. It might even be complete, in the sense that customers use it and pay for it, and aren’t missing anything they need to relieve their pain points.

Yet it’s definitely possible to draw a line in the sand between beta and v1.

According to Wikipedia’s definition of Software Versioning, the free-software community tends to define 1.0 as a “major milestone, indicating that the software is ‘complete’, that it has all major features, and is considered reliable enough for general release.”

Of course, we know better.

After releasing a piece software, there will always changes, big and small: security concerns addressed, features added, instabilities fixed. To plan all of our features, set a date, and keep everything shrouded in secrecy until then is a hopelessly waterfall-esque approach that leads to a far more costly product.

In many ways, the distinction between beta and v1 is largely a marketing concern. As you iterate on an MVP, those brave souls known as early adopters are by your side, helping light the way. But once you tell the world that what you’re offering is now a “real” product, you begin to see what the less brave among us are willing to buy.

Do you think your product has what it takes to attract this new audience? As my friend and colleague, Justin Jackson, puts it, “the real question is: can you profitably acquire new customers every month?” An MVP should show you can get initial traction. v1 should show you actually have a business.

Let’s take a look at some strategies you can use to make your transition from MVP to v1 a successful one.

Build A Roadmap

Before you start writing stories for the big release, pause for a second and question your assumptions. You might be excited because you think you’ve got a handle on what your customers want, and you’re ready to give it to them as soon as possible!

Stop. Take a breath. Think. How does what you’re about to build fit in with the plans you have for your business?

If you don’t have a roadmap, you should make one as soon as possible. It doesn’t have to be an all-day exercise, but you should be able to answer some basic questions.

Do you know which features you’re going to build? What about funding? If you don’t have investors, will what you’re about to build help attract them? If you do, are there certain things they’re hoping you will build? Do you have a plan for scaling your development team? What about marketing? If all else fails, can you pivot?

Set A Deadline

It’s tempting to think of v1 as the chance to sit back, take your time, and do the waterfall thing. You’ve moved fast and broken things to prove that you have a market fit, and now you can spend as long as you need to build the first stable version. That’s a mistake. Getting to v1 is just as high-pressure as finding an MVP with traction.

You might put your head down for eight months to build v1 and, by the time you release it, find out you’ve made a big mistake. Maybe the features you focused on building turned out to be ones that customers wanted. But perhaps they aren’t willing to pay for them. Maybe another company beat you to market. Maybe you overlooked a key integration with another service that would have allowed you to really take off. These are the kind of mistakes that you can’t afford to make as a business.

Taking too long to get to v1 is just as bad as taking too long to build MVP. Make sure that you know where you’re headed and when you’ll get there.

Identify Your Target Market

If you’re about to outgrow your MVP, you probably think you know your target market. But take a closer look. Your excitement could by hiding some assumptions. Can you get more granular about the different subdivisions that make up your user base, and use that information to find out more about who you’re targeting?

Have you figured out which customers you should be listening to? Hint: it’s the ones that would _pay _for your service. When you were building an MVP, you proved you could find paying customers. In v1, you want to prove that you can consistently pick up new customers that will pay you more than it costs you to provide a service to them.

Justin Jackson weighs in again: “To be successful, a product needs customers that are easy to reach, cheap to convert, and undemanding to support”.

To dig deeper into these questions, I highly recommend going through a User Experience (UX) discovery process. You should create personas and think about the emotional response that you are hoping to evoke. UX discovery can help answer important questions, like “should we move to mobile?” and “what are our key features?”

Identify Your Key Features And Cut The Rest

A huge part of the MVP process is measuring customer engagement with the different features you’re testing. Pull out all of our customer interviews and surveys. Read through the reports in your analytics software. Make a list of all the features that you’ve had success with, and rank them. Which ones were the most popular?

Your v1 should focus on your core features only. Cut the rest. Remember, for each feature you add, you have to think not only about the feature, but also tests, regressions, and bugs. Plus, you’ll be dealing with scaling your business. Employees, culture, and performance are going to be concerns in a way that they weren’t during the MVP process.

Keep it simple.

Build A Strong Cultural Foundation

The business you build when you’re going to v1 will set stage for everything that comes after. Now is the time to think about what kind of company you want to create. You will want to make decisions that build a strong foundation.

You will be hiring new developers. The culture you inspire and the process you set up for five developers are the blueprints that will be followed when you get to fifty. The process you use to acquire new customers had better be scalable, or you could find your pipeline going dry a few months down the road.

Build A Strong Technical Foundation

If you’ve done a good job of building MVP features at a minimal cost, you probably already have some technical debt that needs to be paid down. This is the time to switch out stopgap measures for a scalable tech stack.

Maybe you proved your concept with a simple WordPress site, an email list, or one of the other simple MVP approaches I discussed in my MVP article. These are all great ways to get started, but they’re not very customizable.

If you’re stuck with the features that you get with a certain WordPress plugin, you might find yourself unable to extend or change your features in a timely and stable manner down the road. Plus, moving away from plugins often cuts out the middleman and allows you to recover some capital that you were spending on things you can provide in-house.

Take the time to consider what kind of tech stack will meet your needs. Take the time to understand the tradeoffs between different technologies in the market, and find the ones that best meet your business’s needs. It can be useful to do a discovery sprint to find out what options are available to you.

Find ways to ensure that your code remains working and stable. I highly recommend following a Test-Driven Development process, writing functional tests, signing up for Code Climate, setting up a continuous integration service like Wercker, TravisCI, or CircleCI, and deploying to a staging server before releasing things to production. These safeguards will protect you and your team from accidentally breaking your application.

Finally, make sure you’re thinking about scale. If you’re hoping to get tons of new users you’ll want to have infrastructure in place that will allow you deal with that. If you’re using Engine Yard, it’s easy to upgrade your servers from your dashboard with a few clicks. Plus, Engine Yard support is always monitoring your app for issues, with a global team available 24/7.

As you start building your first release, make sure you’re investing in technologies that will support your business as it grows.

Conclusion

The move from MVP to v1 is a moment of transition for your business.

It’s vital to consider the norms that you’re about to establish, which will have far-reaching effects. You have to be smart. Know your customers, know your features, and don’t delay. But also build a strong foundation, culturally and technically. Finally, set a deadline and stick to it. This lets you build the buzz, keep your team focused, and provides a great excuse to throw a big party. Just don’t forget to invite me!

Until then, best of luck with your business.

P.S. Do you have any stories about the first release of your product? Got any sage advice for other readers? Leave us a comment!