This post originally appeared on Engine Yard
Introduction
You’ve done it! It all started with an idea and two people 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 the 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 that 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 are your target demographic and platform? Which features make up the core of your offering? Which have resulted in the most clicks and positive feedback?
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 that they need to releave 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 corrected, features added, previously undiscovered 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. You’ve potentially expanded your market greatly, by giving birth to “The New (your product name here)”.
Do you think your product has what it takes to convert this new audience to your cause? As my friend and colleague Justin Jackson puts it, “the real question is: can you profitably acquire new customers every month?” MVP should show that you have some initial traction. V1 should show that 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 you can!
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, does what you’re about to build have the ability to 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, do you know how to 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 a high-pressure as finding an MVP that proves its value.
You might have an initial MVP that’s proven it has traction, put your head down for eight months to build V1, and by the time you release it, find out that you’ve made a big mistake. Maybe the features you focused on building out turned out to be ones that customers wanted – it’s just that they weren’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 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 actually pay for your service. When you were building an MVP, you proved that 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 your 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 sets stage for everything that will come 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 for what’s to come.
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.
Take the time to think through what kind of place you would like to work in, and try to manifest that reality as you build your V1.
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, and be the canary in the coal mine to let you know when things are about to go wrong.
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 to serve a heavy load of users. If you’re using Engine Yard, it’s easy to upgrade your servers from your dashboard with a few clicks, plus they’re always monitoring your app for emerging issues, and their support team is immediately available to support you as you respond to a high volume of requests.
As you start building your first release, make sure that 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 set up, which will have far-reaching effects into the future. 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.