Defining MVP Essential Skills: User Story Map Source

Translated

If you're a startup and haven't used user story maps yet, you should try them. Today I'm going to introduce the requirements splitting method from Jeff Patton's User Story Map.

The success of a product is in the fact that we meet user needs better than our competitors, and this is not an easy task. This is because, more or less, you have not done the following three things:

• Understand the demand itself and be able to grasp the core pain points;
• Choose to meet demand in your unique way;
• Split requirement realization into stories of different sizes, and do it faster and more beautifully than competitors.

This article will focus on the third point, especially for multi-demand and composite products.

After mastering the method of the story map, you will find that whether you are an interactive product manager who likes to observe user behavior and extract user behavior patterns, a user operator who pays attention to user experience and finds user high points, or anyone else who will participate in the business The role of collaboration with other departments in the process is a technique to maintain a panoramic perspective in the process of demand splitting and a more effective way of communication when departments collaborate.

I. What is MVP?

A minimum viable product (MVP) is the minimum product launch that can produce the desired outcome. Here we need to clarify which users are "minimum" aimed at. What goals do these users need to achieve with the software?

In addition, very few products are brand new. They are often adding new functions or improving existing functions on existing products. Therefore, we define the minimum feasible solution as the smallest release solution that can produce the expected results.

While focusing on learning and validating the hypotheses of the first MVP release, we also need to set up smaller-scale experiments and prototypes to verify our minimum and feasible guesses, so MVP is not a product at all: A minimum viable product is the smallest experiment to test a hypothesis.

II. How to Find the MVP?

We often quickly become overwhelmed with the amount of work we need to do before we launch a perfect product. Completing all functions seems very important, but when we look back and think about those specific users and the basic functions of users to achieve their goals, we will find that these users and demands can be summarized in one or two refined sentences.

1. First, Create a User Story Map

Everyone is from different teams, and each team specializes in different areas, but they are delivering the same product. Everyone must work together to deliver this product. The release plan cannot be made according to the perspective of their respective teams. Everyone must visually show all dependencies.

Story maps are used to build consensus and help teams visualize dependencies. Creating a story map can help uncover gaps in your design. We often assume that other teams will take care of things when they don't know they need to. Sometimes it can also be found that some designs have missed key links between important features. In building the user story map, the team can discover the missing parts in advance.

Hold a user story map discussion meeting!

What you need to prepare is:

• A relatively undisturbed space;
• A whiteboard (if the product is complex and involves many user actions, you can use the floor, glass wall, etc.);
• A discussion group of about five people (product, business, interaction design, operation, etc., pay attention to not too many people. Otherwise, the information will easily get out of control);
• Several sticky notes (preferably in different colors).

This meeting lets all participants use sticky notes together, one action at a time, from left to right, to describe all user behaviors that occur in the product usage scenario according to the timeline. If it happens at the same time, it will be written below the same position; when different actions in the same scene appear, different branch actions may be formed; until returning to the main line or ending the branch line.

This description process may be very noisy because everyone will argue about the order in which user actions occur. You will also find details you have never thought of when you are in it.

These details have the potential to benefit everyone involved. It needs to be reminded that this is a bottom-up approach that does not create any pre-assumptions for itself; it makes you forget whether you have ever judged a certain behavior as "required" or "not required." When the panorama appears, you can merge simultaneous and irrelevant user behaviors, and you will see which user experiences are very important at key nodes of the route. Starting from the user story picture and looking at your products, you will have a clear sense of the big picture.

Once the story map is complete, we realize that there is so much to do and that there are almost endless project dates to get it all done. At this time, we must ask: "To achieve the xxx effect, do we need to use all the functions?"

We are focusing on expected outcomes outside the system to determine what functionality is needed within the system.

2. Second, Divide the MVP Release Plan

On the user story map, we should divide what needs to be done for the first release, and the rest will be done in later releases. The thought process goes like this: "If xx expectations are achieved, and xx results are achieved, the product will look good when released. Because all the features in the release plan are the basic needs of users, they are amazing and can be eye-catching ."

Focusing on outcomes, that is, what users can use and perceive after release, and dividing the release plan should be result-oriented.

Next, divide the release roadmap.

The story map contains many things, but the time required to complete all the functions is unacceptable. We must focus on the most important goal achievement and identify what the first release should include.

We horizontally divide the sticky notes on the user story map and paste a sticky note on the left side of each division release, with a small amount of text describing the expected results. Cards are then moved between releases, matching the outcome expectations of each release as closely as possible. Thus, on the left side of the map is a list of release names identifying the target outcomes. That's the release roadmap.

Focusing on specific target outcomes is the secret to prioritizing development work.

In the end, we should prioritize outcomes, not functions.

The secret to dividing large outputs is that we focus on small, specific outcomes. Behind the outcome is a change in the specific behavior of a specific user participating in a specific activity. We select users to participate in events by focusing on upcoming events. However, focusing on active users cannot meet the needs of other users simultaneously. These users will continue to meet their needs through the existing system for a relatively long time. You can't please everyone all at once.

III. Conclusion

Your job is not to develop software but to satisfy user needs better than your competitors. Use story maps to output MVP release plans for less development, faster learning, and on-time releases.

And when you are doing user story maps, remember these three things:

• Describe the user story as fully as possible;
• Visualize your user behavior;
• Standing in front of the map and re-examining: what do we want to achieve in the next development stage?