- Lean, agile, and design thinking all use iterations.
The idea of iterations is to check
the on track at frequent intervals.
The deliverable from the first iteration
of the story map should be as small as it can possibly be
to test whether the idea we're building is good.
This is sometimes called the minimum viable product,
but I prefer the term minimum usable product.
Now that you have all your stickies in place,
it's time to split them up in a way that lets you work out
what the minimum thing is that you could build.
I like to arrange them vertically by importance.
Importance means how necessary are they in order
for your customers to carry out that task.
Create three lines horizontally across the story map,
and then place the absolute critical capabilities
in the top space.
The ones that turn it
into a more commercially acceptable product
in the middle space, and the pretty important ones
that could be built later in the lower space.
Everything else, the nice to have capabilities get stuck
at the very bottom of the story map.
You'll get to those if you have time,
but not at the expense of the other capabilities.
What you've just done,
is defined your minimum usable product.
By building the stuff in the top space
and nothing but that stuff,
you can quickly create a minimum product that allows you
to gather even more user feedback,
and check that you're on the right path.
The minimum usable product doesn't have
to be commercially viable.
It might not have all the bells and whistles
that make it smooth to install.
It might not even have a functioning help system
or pixel perfect interface.
But it should have the core capabilities
that let customers achieve the outcomes they expect.
Once you have the smallest number of features
that let you test your ideas, get the product
in front of some customers.
This doesn't mean you have to package it up and market it.
It just means gathering feedback from usability sessions
or preferably from longer term usage
from a group of early adopters.
From there, it's time to make any course corrections,
build the next needed feature set and test again.
Obviously you won't be adding every capability
from the second or the third horizontal area
of your story map in each subsequent iteration.
There'll be multiple iterations.
And each one might only add a couple of new capabilities.
But the principle of splitting the capabilities
by importance still stands.
We determine which features are needed
and in what order, based on our goals
and list of pin points.
Those are taken directly from our user observation data.
So we're constantly remaining user centric
and basing our development on what our customers need.
Use a testing after each iteration,
let's just see how well we're doing.
It allows to adjust our story map based
on the feedback we get,
or continue with our existing plan.
Either way, we're always checking in
to make sure our customers are happy.
If we're doing things right, we're delivering something
to them with each release, which they find valuable.