Build Less

Carrying on with Jeff Patton’s “User Story Mapping” for my project, following on from Framing the Big Picture the next step is to plan on building less, because

There’s always more to build than you have people, time and money for

Story mapping helps big groups build shared understanding, if the product has stories that crosses multiple teams’ domains get all the teams together so that you can map for a product release across all of the teams, this will help visualize the dependencies across the teams.

The top of the map, where there is a narrative flow of the big story (or high level feature set of the product) provides the backbone of the map, with the details of the each step stemming out of the backbone. The deliverables need to be mapped in their entirety (spanning the entire backbone) hence the teams must work together to build the map because no single team can release in isolation.

The narrative flow of the backbone of the mapwill usually cut through many different user types and systems’ stories because it tells a story about all the people who use the system and what they do in order to achieve their goals.

Then, since you can never build it all, you need to focus on external factors to decide on how to prioritize features internal to your product. For example think of what is likely to happen in the market your product is targeting and try to priotise features that will make use of those movements in the market.

Minimum Viable Product (MVP)

Jeff advocates this definition of an MVP

The smallest product/solution release that succesfully achieves its desired outcomes

Because when you are slicing out your MVP release you need to focus on the outcomes, what users need to do and see on the product, and slice out releases based on that. On the map create horizontal slices with lines stretching from left to right, then move cards up and down into relevant “lanes” to indicate which feature went into which slice. Those lanes or slices will give you your releases.

You may have a lot of good, innovative ideas on your board, but in reality it will take a long time to achieve them all so you need to think about the market and establish targets to hit with your features built into release slices. It is a good idea to put on a sticky note on the side of each slice that highlights the intended outcome of that release. This is a good practice in prioritizing features (by prioritizing outcomes).

The above shows our board after we went throguh this process, we had two events that we focused on when slicing our releases;

1. When one of our team members visits Tanzania
   • This is a good time to pilot the first MVP, released to a handful of people we personally know
   • One of our own will be on site there and can foresee the manual activities that need to take place to fulfill orders.
   • The target date for this was 2nd of May
   • The purpose of this MVP release is to plant the idea into people’s heads that they can go online and shop for items, pay for them and have them delivered to their relatives or parents back home.
2. Beginning of the Holy month of Ramadhan
   • This is a good time to have a fully functioning service that can be released to the general public
   • A lot of people do bulk shopping to stock up food for this month.
   • The target date for this was 27th of May
   • The purpose of this GA release is to have the first interaction with real world customers

The screenshot below shows our Trello board after we have made our release slices, we used labels to highlight releases, with the first release in amber and the second one in purple.

However Jeff acknowledges that one of the most important thing in developing a product is to get it right, by learning quickly using MVPs as experiments to prove or disprove theories, hence he also advocates Eric Ries’ definition of an MVP;

The smallest thing you could create or do to prove or disprove an assumption

So the next thing is to create a framework of learning quickly