Carrying on with Jeff Patton’s “User Story Mapping” for my project, after slicing releases it is time to put a framework in place to learn faster
Once you have your product idea and asked yourself who are your customers, how they will use it and why the need it, you need to validate the problem your product will solve really exists. Find a handful of people from your target market and try to engage them. The more feedback you get from the prospective users the more your original idea will evolve into something the users really want.
It is better not to start building the software before engaging with the prospective users and build th minimum thing (MVP) to prototype the ideas and get feedback from. Create user scenarios, sketches and build high fidelity prototypes (software like AxureRP can be useful) and run them with your prospective users.
Collecting feedback this way, especially negative feedback, can help you save a lot of effort in building the product that the users don’t actually want. This is an iterative process, using the feedback to create the backlog of validated stories.
One thing to note about prototypes is that since you can demonstrate a lot of cool features using prototypes people will naturally have their expectations quite high, your actual working MVP would not be able to deliver all the features demonstrated on the prototypes. Also people might say they will use the product when they see the prototype but they are just guessing at that point, they might not necessarily use the actual product - so this needs to be kept in mind.
As the product takes shape from the feedback, features with high priority gets moved up to the first release slice, and then moved to the development task board, so the story map board becomes the back log of the task board. The development task board is where the development sprints are scheduled.
Plan to work with a select group of your prospective users, the become beta customers, where you release a less than minimal release to them and get feedback which drives the development of the next pre-releases. Iterating through this process, adding a bit more functionality based on the feedback from the beta users and releasing it back to them until they start using it routinely and might even recommend it to others (givng your product real reference) that is the point when you have found minimum and viable, at this point you can market the product to the general population.
Henrick Kniberg illustrates this in the diagram below, focus on delivering usable software to the beta users and keep improving it based on their feedback of actually using it
Treat every release as an experiment and be mindful of what you learn
The goal is to learn as fast as possible if we are building the right product, and the validate learning loop that was made famous by Eric Ries of build - measure - learn works very well;
