One of the key elements of using lean startup methods to develop your sustainability strategy or to design a sustainability program is the use of a minimum viable product generally referred to as your MVP.
Typically an MVP is defined as a product with just enough features to satisfy early customers or users and to provide feedback for future development. However when used effectively an MVP is not just a product, it is a process that you repeat over and over but identifying your riskiest assumptions, find the smallest, fastest, and cheapest experiment to test those assumptions, and use the results to adjust your solution.
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. Eric Ries, author of The Lean Startup
When you develop your sustainability strategy you make many assumptions. You assume you know what the users are looking for, how the design should work, what communications strategy to use, what stakeholders will want to be involved, that senior management will actively support the strategy, what laws and regulations you need to comply with, and how you will measure success. But no matter how good you are, some of your assumptions will be wrong. The problem is, you don’t know which ones.
The only way to find out is to test your assumptions with real users.
Designing your MVP using Story Mapping
Story mapping is a technique derived from the software industry and agile development. It is based on understanding a users journey through your product, how they use the product, and the process they follow. The following is a five step process to develop your MVP using story mapping.
Step 1 – Identify the primary goal of your product
Imagine you are developing a sustainability program that helps employee’s car pool and share the costs of commuting to work whilst also reducing the number or cars on the road and pollution being created.
Your “product” allows staff members to register as either a driver or a passenger, find colleagues that live near each other or along a same route to the office, connect with colleagues to form carpooling groups, and share the cost of commuting such a fuel expenses or road tolls. The end result is that staff members are able to organise themselves into carpooling groups to get to and from work each day.
The first step is to define what primary goal our “product” trying to achieve. What does it do and what problem is it solving?
In this example, our primary goal could be “to allow staff members to connect with colleagues to organise into carpooling groups”.
Step 2 – Define the main process of the product
The next step is to define the process and user would go through in using the product ie what tasks would they need to perform. Next, we need to define the stages this process flow would follow.
In our car-pooling example the process might be something like “create a personal profile – driver or passenger”, “enter location where they would travel to/from”, “identify a car pooling group”, “join group”, and “participate in carpooling”. These various tasks define the process if the user flow through your product.
We then take these process stages and place them on our story map as shown below.
Step 3 – Create a list of features for each stage
In this step, we now go through a brain storming process to identify the features of the product that the user might want to see at each stage of the process. In this step, we are not looking to prioritise the feature but to simply identify features that might help the user solve a problem.
For example, our features list might look something like the following.
Stage – Create profile
Features – Add a photo, include interests in profile, automatically link contact details.
Stage – Find group
Features – Google map interface, user profiles, user reviews, route maps for carpooling groups, vehicle details for car pooling group …
As you come up with ideas they are placed on the story map as shown below.
Step 4 – Prioritise the feature lists
The next step is to organise and prioritise the feature lists. We do this by considering the following questions:
- How important is the feature to completing the task?
- How often will the feature be used?
- How many users will use this feature?
- How much value does the feature deliver to the user?
- How difficult is the feature to implement?
Based on this we organise the features under each task of the process from highest to lowest priority.
Step 5 – Define the MVP
Once we have our list of features in order of priority we can now define the key features necessary for our MVP. The MVP should represent the minimum number of features that are essential to providing the user with the necessary experience of the proposed product, remembering that we are seeking to test our key assumptions with the MVP.
Now we decide on the “must have” features, “nice to have” features and the “do not need” features from our lists. Next, we draw a line across our features list that divides the “must have” features from the other features.
The features above this line (MVP line) represent our MVP and the features below the line captures our larger vision for the product and features that can be added later.
Once you have built your MVP it is time to test it using build, measure, and learn cycle from the lean startup method.