Twelve-Week MVP

Startups

Mar 13

The name of the game in any startup venture is to find product-market fit as quickly as possible; and if you don’t hit it first time, to find an idea that works before you run out of money. Agile software development and Lean Startup methods both help you do it (ideally, used together). But while there is a lot written about the principles of Lean and Agile, there are precious few step-by-step guides on how to actually execute.

This post thus emerged from a series of discussions about what frameworks are available for running a fast and tight Lean Startup style project.

What follows is a project timeline and experiment framework we developed at Neo Innovation (now part of Pivotal Labs) from 2014 to 2015. Using this process, we ran at least a dozen separate projects that year. Few resulted in resounding commercial successes for our clients (hey, that’s startups), but all were successful from the perspective that we contained risk and validated (or invalidated) product market fit repeatedly within a fixed timeframe.

Preparation

Understanding The Key Principles

Before you dive into the process, we should review the key principles that underlie this method. Here are a series of diagrams we would draw at the start of every one of these projects to ensure the team is in methodology alignment.

Cross-functional Teams

This diagram represents the critical importance of the cross-functional team. We say a product is successful when it is valuable, feasible, and usable, and those aspects are generally overseen by engineering, design, and product. But notice that engineering overlaps with design and product, as do the other two overlap with their neighbors. You cannot build good products with functional silos.

Reducing Risk With Small Releases

The risk of product development is represented by this saw-tooth graph. In traditional product development, risk is accumulated until the first release. In agile and lean practice, feedback loops with customers allow you to reduce a large risk into a series of smaller risks. This risk strategy permeates all of the practices below.

Experiment Fidelity

This graph shows that as we reduce the uncertainty in our business model and product, we give ourselves permission to try gradually more complicated experiments. Experiments are used throughout our process, and range from simple to complicated, from cheap and easy to more involved and elaborate.

Required Skills

One last thing before we dive in. Who is on the team during this process? It’s important to remember that you are balancing several factors in each individual and as a team, including speed of output with quality of output, minimalism with detail-oriented focus, and so on. All of the team members, the engineers, designers, and product management and business folks, need to be the type of person that can make a high quality contribution, while simultaneously keeping things fast and simple. Everyone needs to be comfortable talking to customers. Everyone needs to understand the basic math of the business model. Everyone needs to make mature decisions about which corners are ok to cut, and which are not.

With the right team assembled and the principles clear, let’s jump in.

The Framework

Weekly Schedule

We organize the work into weekly sprints. Week 1 is taken up mostly by the Inception meeting (or “Kick-off”, if you prefer that term). The rest of the week is getting ready for the first round of experiments.

Every week, starting with week 2, should include a Monday weekly planning meeting to review the week’s experiment and plan the work.
Each work day should start with a brief daily stand-up meeting to coordinate tasks.
Each week should end with a retrospective meeting to air any concerns with the process and make adjustments.

Inception

As a rule, we always started our projects with an Inception, a one- or two-day working session intended to establish a common goal and to flush all of our hidden assumptions out into the open.

Everyone on the team attends the Inception, including the client, product manager, engineers, designers, and any other stakeholders who will need to be involved. In a bigger company this might include sales and marketing, or even legal.

It’s held in a single conference room (if possible), equipped with a whiteboard and plenty of stickies and sharpies. No laptop is open unless everyone is looking at it. And don’t forget the coffee, water, snacks and lunches!

This agenda is based on walking through the Business Model Canvas (or the alternative Lean Canvas) along with a few other exercises derived from different disciplines (design thinking, Lean UX, etc.).

Declare the Vision

Have a clear and simple vision statement that everyone on the team understands. It typically comes from the client or founder. This is the North Star that guides all of the decisions moving forward. You can pivot on strategy, customer segment, problems to solve, and solutions. But don’t ever pivot the vision.

Write the vision across the top of the whiteboard in large letters and leave it there for the entire Inception. Under it, write all of the following headings across the board, leaving space underneath each for a large number of stickies.

Customer Segments

Enumerate all of the customers that will use this product. If you’re making a market or platform include both suppliers and consumers. The best approach for this exercise (and all the others, frankly) is to allow everyone to spend a few minutes quietly dumping their ideas on stickies, and then go around the room reading them off and consolidating them. Place the final list on the board under Customer Segments.

Next, deviating slightly from the canvas walkthrough, briefly have everyone spend a few minutes creating simple and fast personas for each customer segment you listed above–or at least the major ones. Again, use five or ten minutes with everyone participating and then go around the room and share them. Tape the personas on the wall and leave them there for inspiration.

Value proposition

Based on the personas developed for each customer segment, we should by now have a good idea of the value proposition for each segment. If necessary, have everyone again quietly brainstorm their value proposition ideas on stickies, and then share them around the room. You will end up testing all of these assumptions during your experiments later in the process. So it’s fine to go both broad and deep. No ideas are bad ones. Just put them all on the board.

Channel

Similar to value proposition, we should have some idea from our personas about where our customers get information about new products and services. What blogs do they read? What social media networks do they use? Are there physical spaces they frequent? Dump all of your channel ideas on the board.

Cost

We typically built a simple formula on the whiteboard to calculate monthly burn rate for the proposed business. We would include all of the fixed and variable costs of building the product, as well as marketing and sales costs. Put these assumptions up on the board under Costs so everyone understands the expected burn rate of this business.

Revenue

Right next to the costs listed on the board, we calculate the total number of sales needed to break even. This typically ends up generating a lengthy discussion about prices and sales volume. You typically don’t know the ideal price for the product and you don’t know the size of the market. But if you have any research that you’ve done previously on these numbers, this is the time to bring it up.

Zero in on something reasonable for now, but don’t get lost in the weeds of your own assumptions. You’re going to test them!

Competition

Lastly, we need to understand the competitive landscape. For this section, it is important to hypothesize all of the various ways that customers are currently attempting to solve the problem that our business is intended to address. We will be able to validate the relative importance of competitor solutions in our problem interviews.

With the Inception completed (and we’re sure to take good notes and pictures to capture the whiteboard and all of the assets we generated), we are ready to begin our first experiments.

Problem Interviews

The goal of the problem interview is to make sure that our product or service is solving a real, painful problem that our customer segment actually has. This part of the process typically begins week 2 (expect to spend the second half of week owe finding and scheduling people for interviews).

It can take anywhere from one to three weeks to do a proper set problem interviews, depending on how easy it is to find your target customer. Don’t get discouraged, and don’t give up. If you get through a third of your timeline, but have a very clearly understood set of problems for your customers, you are in great shape!

Preparing

To run this experiment, we need to interview about 20 prospective customers. Team members should get started immediately finding and scheduling interviews with customers. How this is done varies greatly depending on your business model. But, if you can’t find 20 prospective customers to interview, there is no way you can acquire enough customers for your business to operate.

While you are searching for and scheduling interviews with customers, you need to develop your interview script. Our personas should have produced a series of problems that we think our customer segments have, and that are painful enough they would want to pay for a product or service to solve them.

List those problems on a sheet in the order that you think are of highest importance.
Next to each problem, include a binary Yes/No choice, and in the case of a “yes”, a numeric scale for importance (we used 1–5, usually).
Include space on the sheet for extra problems your users tell you that you didn’t think of in advance.
Make sure to inquire how they are currently solving their problems, and when was the last time they spent money trying to solve it.

Executing

Conducting customer interviews is something that everyone on the team should become comfortable with. It’s best to do it as a pair, so one person can do the talking and the other person can take notes. It’s remarkable difficult to do both by yourself. There are significant resources on how to do these interviews. I will simply refer you to my favorites: Talking to Humansand the Grass Hopper Herder blog.

Analyzing

After the interviews are complete, you should have plenty of qualitative data on your customers’ problems, and some structured quantitative data on their relative painfulness. If you sort the problems in order of most painful to the largest number of interviewees, was the order surprising to you? If you validated your assumptions about the most painful problems, congratulations! If not, you have learned something new about your customers. You win either way!

With a clear sense of what are the most painful problems for your customers, you are ready to delve into solutions.

Solution Experiments

By now you may have used up anywhere from 2–4 of your 12 weeks, and you are probably itching to start building the product. I would caution you to stick to the principle outlined above regarding the fidelity of the experiments. Start simple, and move your way up.

In keeping with the methodology above, we have a variety of solution experiments listed here. I have ordered them roughly by lowest to highest fidelity, but your versions may differ slightly. Each experiment type does test for slightly different assumptions from the canvas exercises above. Be sure to set out your specific hypotheses before running each experiment.

Concierge

This solution experiment is intended to validate whether your customers will pay money for the solution. You do this experiment by manually providing the service, and charging for it. Of course, there are products and services for which this test doesn’t make any sense (like data science products, for example). Use your discretion. However, for a service like online delivery, or some kind of data processing or customization, this test can tell you a lot about your customers’ expectations.

Paper Prototype

Ideal for tools and utilities, this test centers on the user experience of your product or service. It’s pretty similar to a usability test. You’re going to walk your customer through an example UI on paper or a digital clickable mock-up. It’s a way of validating that your UX provides the value they expect to see in the product.

Landing Pages

Marketers are very familiar with landing page experiments. The main hypotheses in these experiments is, Does the customer segment respond to value proposition messaging in this channel?, and do they do so at a sufficient conversion rate that the economic of our model will make sense. Usually, landing pages have a heavy up-front design component, because they need to be convincing as a completed solution. We would normally collect emails as our conversion target.

Wizard of Oz

A landing page experiment that focuses primarily on acquisition strategy and retention will expose the user to a fairly polished sign-up and on-boarding process. But you can extend that experiment with “Wizard of Oz”. The key is that all of the tech and design effort is on the surface, and the fulfillment in the backend is done entirely by hand. It is similar to the Concierge test above, but the customer just doesn’t know that you’re doing all the work manually behind the scenes.

A working MVP

Eventually, you need to actually test your core technology idea. At this point, you will want to have a rough but working version of your product online that you can test with users. Prioritizing the absolute minimal set of features necessary to learn from your MVP is a bit of an art more than science. But a general rule of thumb is to provide as much of the core value proposition as you can with as little technical work as possible. Don’t be afraid to keep major parts of the work “behind the scenes” manual for now. This is not yet the time to automate and scale. You are just making sure that you can provide the core value without losing your customers. Your focus is on learning!

Conclusion

This process works, if you follow it pretty tightly, and if your goal is to validate a business idea. It is not enough time to make a profit or to break even. So it’s important to recognize that your investment in this 12 week push should account for only a fraction of your total investment (around 10 to 20%). Expect to spend more money and time immediately following this 12 week sprint should you have the good fortune of actually getting a strong signal from the market.

This is just the beginning, not the end, of your process. Good luck!

Acknowledgements

I learned this stuff by reading books and working with other experts. Those books include “The Lean Startup” by Eric Ries, “4 Steps to the Epiphany” by Steve Blank, “Flow: Principles of Lean Product Development” by Don Reinertsen, and many others. I am gradually adding them to the book’s bibliography.

The people I learned from include Janice Fraser, Tristan Kromer, David Bland, Jonathan Irwin, Mike Long, Scott McLeod, Gon Zifroni, and countless others too numerous to list here.

[Edit: This is an old story posted back in my Neo days, in 2014. I admit that it kind of falls off at the end there. But I am working on a newer, revised and more thorough version, coming soon…]

How are your teams doing?

Take our free product organization self-assessment and find out! Take the assessment here.

Sam McAfee