More on this book
Community
Kindle Notes & Highlights
That’s the real outcome he’s looking for — and the only outcome that’ll get his company the benefit it really wants. And it’s going to take more than a prototype to learn that.
their first goal isn’t to build a minimum viable product. Actually, it’s to build something less than minimal — just enough that potential users could do something useful with it.
This is a product that wouldn’t impress too many people, and they might even hate it. It’s definitely not a product you’d want your marketing and sales people out there pitching.
less-than-minimum — and definitely not viable — product in front of.
that topmost slice. It’s twice as thick as the slices below it. When Eric and his team finish a slice and deliver it to their development partners — what they call their beta customers — they’ll move the sticky notes up from the slice below. When they do, they’ll have lots more detailed discussion about this next sliced-out release.
he’s purposely built something less than minimal to start with.
If your goal was to leave me delighted, you might feel bad about that. But your real goal was to learn, which you did. So that’s good.
Treat every release as an experiment and be mindful of what you want to learn.
Always keep your target customers, users, and the outcomes you’re hoping for in mind. It’s really tough to get the same great outcome from all types of users. So focus.
the problems he was solving, the customers and users he was solving them for, and the solutions he had in mind were all assumptions.
the smallest thing I could build to learn something.
Our goal isn’t to get something built; rather, it is to learn if we’re building the right thing.
If you’re doing this well, it means that what you build early may not be production ready. In fact, if it is, you’ve likely done too much.
The riskiest part for me was making sure my product was right. So we built early versions of software using simple, in-memory databases.
framing the feature idea they were working with to really understand who it was for and why they were building it.
they were able to build simple electronic prototypes in Axure and test them with customers remotely
After multiple iterations with simple prototypes, they finally felt confident they had something worth building. That may sound like a lot of work, but they did it all in about three days.
this map isn’t about a whole product, it’s just about a feature they’re adding to an existing product.
Map only what you need to support your conversation.
When team members asked why the screen behaves as it does, they had stories to tell about variations they’d tried, and how users behaved.
The best estimates come from developers who really understand what they’re estimating.
the end the entire movie needs to come together and look like one coherent whole.
It wouldn’t work in all the situations it needs to, and
But Mike and his team will be able to see the software running end to end.
I call this first slice a functional walking skeleton — a term I borrowed from Alistair Cockburn.
“unknown unknowns.” Don’t pretend they don’t exist. You know they do.
Each of these slices isn’t a release to customers and users: it’s a milestone the team members will use to stop and take stock of where they are.
Think of these slices as three different buckets with different learning goals for each. Decide which sprints or iterations they’ll go into when the time comes.
initial time estimate. They treat it as a budget. And they actively manage it.
changing software after it’s built is too often seen as a failure. It’s where terms like bad requirements or scope creep get used to reprimand the people who made decisions about what to build.
But we all know that change is a necessary result of learning.
Build just enough to see the product working end-to-end.
Fill in and round out features. Add in stuff that supports optional steps users might take.
Make it sexier, and more efficient to use.
It’s here that you’ll have feedback from users you’ll be able to apply.
got the idea for this simple visualization from John Armitage’s 2004 paper “Are Agile Methods Good for Design?” John describes approaching user experience design this way. I’m suggesting we carry the metaphor into the way we build as well.
User tasks are the basic building blocks of a story map.
altitude metaphor where sea level is in the middle, and everything else is either above or below sea level.
sea-level task is one we’d expect to complete before intentionally stopping to do something else.
Alistair calls these functional-level tasks and annotates them with a little ocean wave. But I’ll just call them tasks.
One lesson I learned, having run this same exercise now for multiple teams in our organization, is to use an icebreaker to prime the mindset of the participants. Start the session by having each person write just one thing he or she did between waking up and getting to work. Then ask each person to answer the question: “Why did you take that action?” I found that this starts a background mental thread that shows up in later planning sessions: “What is the value of this user story? Why would our users do this?”
Six Simple Steps to Story Mapping
If you don’t have a clear solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have.
we typically start with a product vision exercise such as the well-known Elevator Pitch or the Cover Story[8] format where the team describes what they would like to read about their product in a trade journal article a year from now.
Kano model
he noticed that one of the biggest problems in software development sprang from the traditional process approach of using documents to describe precisely what we want — that is, the requirements.
We can both read the same document, but have a different understanding of it.
Those documents often accurately describe the wrong thing.
Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.
What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does.
