MVP Planning Guide

[victorkane]

Intro

The title here might as well have been "Planning Guide" since under Lean, there is no other product than MVP, in its infinite iterations. In a certain sense, every user story (understood as one or more user hypotheses) is an MVP in itself, so the MVP (product) is a recursive fractal of MVP's. Just as a product idea is a recursive fractal of ideas.

So this is a planning guide for a single user story (a card in the Kanban), a sprint and its backlog if you use time boxed sprints, a multi-disciplinary cross-functional team "theme" of sprints, or for a whole product. It's about answering the question: what's the MVP for this idea?

"Your prioritized list of hypotheses has given you several paths to explore. To do this exploration, you are going to want to create the smallest thing you can to determine the validity of each of these hypothesis statements. That is your MVP. You will use your MVP to run experiments. The outcome of the experiments will tell you whether your hypothesis was correct and thus whether the direction you are exploring should be pursued, refined, or abandoned. --Gothelf, Jeff (2013-02-22). Lean UX: Applying Lean Principles to Improve User Experience (p. 56). O'Reilly Media. Chapter 5.

The MVP is the first working release of the product having the smallest feature set capable of providing meaningful product test results for the prioritized list of hypotheses. If successful, it provides the starting point for the next iteration. If unsuccessful, then a new set of hypotheses must be developed. Since this version of the product was built using a minimum of effort, pivoting is less costly, and success provides value information for planning the next iteration. It is the way a product should be iteratively and incrementally built.

Market, Problem, Product

At its heart, it's an idea broken down into market, problem, product and the validation of each always with an MVP, and the incremental iteration of the MVP into product and beyond.

Defining Market, Problem and Product: "A market is the group of people you think might want to buy your product.... A problem is the reason that those people are going to use your product... A product is simply the way that you’re going to solve the user’s problem. It’s the end result of what you’re building. It’s the thing that people, presumably in the target market, are going to pay you money for." (Klein, Chapter 1)

Validating the Problem: "You are going to discover a problem that exists within your target market that you are capable of solving. Remember, if there’s no problem, then there is no compelling reason for people to purchase your product.... You’ll know that you’ve validated a problem when you start to hear particular groups of people complaining about something specific."

Validating the Market: "Validating the Market: You’ll know that you’ve successfully validated your market when you can accurately predict that a particular type of person will have a specific problem and that the problem will be severe enough that that person is interested in purchasing a solution."

Validating the Product: "Just because you have discovered a real problem and have a group of people willing to pay you to solve their problem, that doesn’t necessarily mean that your product is the right solution.... You’ll know that you’ve validated your product when a large percentage of your target market offers to pay you money to solve their problem."

Tools for early validation: Ethnographic studies, Landing pages to see how many people feel the problem enough to sign up. Prototypes to see if your product could be a solution for a significant number of people. Ethnographic studies: questionnaires, lists of questions and checklists to use in dialoging with customers. Landing pages for validating the problem. Prototypes: Even though this is a product-wide artifact (the mvp is the code to be delivered and tested), the acceptance test for the user story is a prototype test to see if the product solves the validated problem.

"The important thing to remember is that you need to solve a real problem, and in order to find that problem, you need to listen to real people. It’s nowhere near as easy as I’m making it sound, but the only way to get better at it is to do it. Over and over and over." (Klein)

PDD Pain Driven Design

Before you have a product, you need to find out the pain points people have with their current solution (or lack of it), or with the product they are currently using. When you have an MVP, it's not going to be a pass/fail situation with the prototype product validation. It's going to be: what part of the UX is driving the customer crazy? These may be changes to the baseline (pristine backlog), or new change requests, or a new cycle of development within the user story you are working on, according to the maturity of product development. If you have no product yet, ask people "how they’re dealing with their problems and what the pain points are with their current solutions (or nonsolutions)". If you have a product, "something about your product is confusing or hard to use, and it’s driving at least one of your customers crazy.... Find all the pain points. Then come up with devastatingly clever ways to fix them."

So PDD in traditional Agile would impact on the backlog planning level, or else with the origination of change requests (also to be considered at a planning meeting). It may be the reason a user story is created in the first place, or else it may simply give rise to another iteration within a given user story given test results.

Validation Driven Design

Klein on the Design section of UX for Lean Startups: "I started this section by writing a step-by-step guide for designing a product, but I kept wanting to write, “The next step is X except for when it isn’t.” That’s when I realized that this sort of design is not a linear process. It’s a set of tools." Nine tools, to be exact:

Tool 1: Truly Understand the Problem

Artifact: Problem statement

Most requirements presented by users and stakeholders are solutions they believe will help them with a certain problem, which may be going unstated. “I want to add comments to my product,” not “My users don’t have any way to communicate with one another, and that’s affecting their engagement with my product.” It is essential to get to the bottom of the problem, from the user's point of view. We should also make sure that research be oriented not only to the all-important users of the product, but also to stakeholders within the client organization or company. This is the purpose of the problem statement.

When Is It Safe to Skip This? It is never, ever safe to skip this. If you don’t understand the problem, you can’t solve it.

Tool 2: Design the Test First

Artifacts: Hypothesis Statement, Acceptance Test

This is not only your common Agile acceptance test, but rather a measurable goal that allows you to know whether the design works. Each hypothesis statement has one, and it is to be included, along with the usual agile functional test for the solution, in the acceptance test.

When Is It Safe to Skip This? You really shouldn’t skip this either, although I’ve found that this particular exercise can take as little as a few minutes. Before you start to design or build anything, you should know very clearly what it is intended to do and how to know whether it is working.

Tool 3: Write Some Stories

Artifacts: Persona, Structure User Story, User Story Card

Klein says:

A lot of times when we think of stories, we think of the very specific Agile engineering stories that we write and track. These are not the sort of stories you’re going to write. You need to write down design stories. Think of these as a way to break down your problem into manageable steps. Also, think of these as a way to evaluate the design once it’s finished. A good story for our user help experiment might be something like, “Users who are having trouble making changes to their accounts can quickly figure out how to solve that problem.” Don’t forget to write admin stories, too! You might include something like, “Customer service reps can more quickly add new content to help users when new problems arise.” You’ll notice I didn’t suggest things like, “Customers can ask questions of other users and get immediate responses.” That may be a solution that you explore, but being too explicit about how you’re going to solve your problem can lock you into a specific idea too soon and prevent you from discovering better ones.

However, in Drupal Lean Process the agile user story card constitutes the Drupal Lean Process Kanban board "atom", mapping a structured user story's personas, stated problems, hypothetical solutions and measurable goals with features, and as such is the equivalent to the sum of all the hypotheses statements and other structured user story artifacts associated with this feature. The last clause of the User Story card ("so that ") is where the design story fits in.

Mike Cohn of Mountain Goat Software explains the format for a user story card:

User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a , I want so that .

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written." -- Mike Cohn, What is a User Story

When Is It Safe to Skip This?

Writing down stories is always a good idea. With that said, you’re welcome to skip writing stories for very trivial things like quick bug fixes; small changes to messaging; or visual design changes, like testing a new button color, that are better represented by showing the actual design. On the other hand, the very simplest stories should take no more than a few minutes to write, so consider doing it anyway, just as practice. Sometimes, in the process of writing design stories, you’ll find that you’re missing a crucial part of the design. For example, I was talking with a startup that was changing its home page rather dramatically. The team thought it was a very simple visual design change. However, once they started writing their stories, they realized that one part of the design involved testing different images on the home page. They also realized that they wanted to allow their marketing team to continue to test different images going forward, which meant that they needed an admin interface to allow that to happen. By writing the design stories, they thought through things like how changes would be made going forward—things they would otherwise have missed.

Tool 4: Talk About Possible Solutions with the Team

Artifacts: Collaborative design & Design Studio output wireframes

Gothelf is much stronger on this than Klein. The main concept here is to work with cross-functional multi-disciplinary teams:

Collaborative design is an approach that allows a team to create product concepts together. It helps teams build a shared understanding of the design problem and solution. It allows them to work together to decide which functionality and interface elements best implement the feature in their hypothesis. Collaborative design is still a designer-led activity. It’s the designer’s responsibility not only to call these meetings but to facilitate them as well. Sometimes you’ll have one-on-one sessions with a developer at a whiteboard. Other times, you’ll gather the whole team for a Design Studio exercise. The key is to collaborate with a diverse group of team members.

When Is It Safe to Skip This? By continually checking in with your team and the stakeholders, you’re going to save yourself time in the long run, because they will catch mistakes and problems that you might miss.

Tool 5: Make a Decision

*Artifact: Acceptance Test, User Story Card

This is the baseline for the user story product, matching the user story card solution to the stated problem(s) and hypotheses. Everything in the structured user story that is going to be used has been done, up to and including the user story card. Now implementation and review can go forward. Which solution is chosen should depend on ROI (the easiest solution that will enable the product to solve the problem in the market).

When Is It Safe to Skip This?

Never. Never ever ever ever ever. You must make a decision. There is nothing I see more often at failing startups than a fundamental inability to make a damn decision. If you have done your research and involved your team, you are ready to make a decision, even if you don’t know it’s the right one. Don’t worry. You’re going to validate whether this is the right idea or not. But first you have to pick a direction to go in.

Tool 6: (In)Validate the Approach

*Artifact: All structured user story artifacts

Last chance to bail out; now that a decision has been made on the baseline, take a moment to attempt to invalidate it before going on to the more costly steps involving design studio, prototyping and mvp implementation and testing.

When Is It Safe to Skip This? There are some features or changes that simply take more time to validate than they do to build. Before you implement a fake feature or come up with some other ingenious test to see if you’re going in the right direction, ask yourself how long the feature will take to build and how long it will take to test in this manner. If it’s almost as fast to just build it and test it in production, then feel free to do that.

Tool 7: Sketch a Few Approaches

Artifacts: Collaborative design & Design Studio output wireframes and sketches

You’re ready for it now. You probably already have a picture of what you want to design in your head.

Because sketching is so quick, it’s a great time to do things like work out the flows of basic tasks. Often people forget that what they are sketching is almost certainly not a static thing. It has actions and states. Buttons can be pressed. Forms can be filled in, sometimes incorrectly. When you’re sketching, it’s a good time to get through as many of the different states as possible to make sure that they can all be handled. Whenever you sketch an interactive element, make sure you’re adding a screen or a note about what happens when somebody interacts with that element. If you add a drop-down list, think through what might be in that drop-down list.

Pick one or two sketches that we think are most likely to fix the problems we observed in the initial research. The best way to do this is to get your sketches in front of actual users again.

When Is It Safe to Skip This?

When you’re making a change that is easier to communicate or test in another way, you don’t need to create a sketch. For example, if you’re making a simple visual design change, it might be faster or more efficient to show the change in Photoshop or even in HTML and CSS.

Tool 8: Create Interactive Prototypes

Artifact: prototype or dev branch, continuous deployment

A full-scale, working prototype that allows users to explore and feel like they’re accomplishing tasks.

This is why we use Drupal. In fact, Drupal could be used as a prototyping tool even if it does not form part of the final architecture. Drupal is a wonderful prototyping tool, and Drupal based products should be prototype themselves.

Continuous deployment, at a minimum, should enable almost immediate staging of prototype delivery and fixes.

When Is It Safe to Skip This?

If you’re designing something very simple, quick, and not highly interactive, by all means, skip the interactive prototype. I will always skip the prototypes on things like landing pages with a single call-to-action; messaging changes; and small, new features with very little interactivity. Deciding whether or not to make an interactive prototype is essentially an ROI question. If an engineer can build and release a feature for testing in less time than it would take to build a prototype, often it makes no sense to bother with one. However, if you stand to lose significant time, revenue, or customers by releasing a major change without truly understanding the usability of the feature, building and testing an interactive prototype can be a lifesaver.

**\ Tool 9: Test and Iterate

*Artifacts: Acceptance Test, Change Request, Issue

If the acceptance test fails or there a change request has been approved, then the user story process will be iterated. Otherwise it will be accepted, deployed and the issue will be closed. At a later time, the issue may be reopened.

When Is It Safe to Skip This?

I can’t believe you even asked this question. I’m ashamed of you. Promise me that you will never skip testing or iteration. I mean it.

Product (MVP) Release Cycles

Within the context of traditional agile and scrum process, an initial release will be chosen, and the set of user stories having the highest priority and being capable of constituting the smallest thing capable of determining the validity of their collective hypothesis statements, will constitute its backlog. These user stories will be placed in a milestone, and the deliverable associated with the milestone will be its validated release. Future milestones will be associated with validated releases which are neither more nor less than iterations of that initial MVP. In short, they will always be MVP's themselves. The final product will be a kind of MVP. The concept of MVP is not just the decision of the smallest viable version for alpha release, but is a method for the planification of all releases, including the final product release. Which will itself be iterated as bug fixes and change requests pile in.

At different points in the life of a product, the MVP will serve to answer different questions:

• Is the problem statement really a problem?
• Is there real value in the solution and features I'm offering?
• Is my solution usable?

The first question is probably already answered via design research methods. At most, a sign-up page can be tested for traffic, either as a stand-alone site, or as an additional page if we are enhancing an existing product. The second question may be answered via prototype branches, and the third by either prototype branches or full product releases. Many other technical examples abound in the sources.

But we will always be planning the release cycle not in terms of the features we are building and its architecture, but rather in terms of what business questions need answering and which outcomes need testing via measurable goals. It will always be validation first.

[victorkane]

Minimum Viable Product Planning Guide