More on this book
Community
Kindle Notes & Highlights
by
Jeff Patton
Read between
May 9 - July 9, 2020
chunking has some negative consequences. One of these is that it’s easy to lose the big picture of what a software system should do.
stories were supposed to spark conversations.
there is a profound difference between how the very best product companies create technology products, and the rest.
With a grateful nod to Ben Horowitz’s Good Product Manager, Bad Product Manager, here’s a glimpse into some of the important differences between strong product teams and weak teams: Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries. Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales
...more
This highlight has been truncated due to consecutive passage length restrictions.
Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.
Because stories let you focus on building small things, it’s easy to lose sight of the big picture.
When you’re building a product of any significant size, building one small thing after another leaves people wondering when you’ll ever be done, or what exactly you’ll deliver.
Because stories are about conversations, people use that idea to avoid writing anything down.
Because good stories are supposed to have acceptance criteria, we focus on getting acceptance criteria written, but there’s still not a common ...
This highlight has been truncated due to consecutive passage length restrictions.
teams don’t finish the work they plan on in the timefram...
This highlight has been truncated due to consecutive passage length restrictions.
Because good stories are supposed to be written from a user’s perspective, and there are lots of parts that users never see, team members argue that "our product doesn’t...
This highlight has been truncated due to consecutive passage length restrictions.
Product managers and user experience (UX) practitioners in commercial product companies should read this book to help them bridge the gap between thinking about whole products and user experience and thinking about tactical plans and backlog items.
Shared documents aren’t shared understanding.
Shared understanding is when we both understand what the other person is imagining and why.
Stop trying to write the perfect document.
The real goal of using stories is shared understanding.
Good Documents Are Like Vacation Photos
what’s most important isn’t what’s written down—it’s what we remember when we read it.
Every great idea you turn into a product solution changes the world in some small, or not-so-small, way for the people who use it.
requirements are just another name for the ideas we have that would help people.
the truth is that you can’t please everyone all of the time.
Outcome is what happens when things come out—that’s why it’s called that—and it’s difficult because we don’t get to measure outcome until things do come out.
we don’t measure outcome by the number of features delivered, or what people have the capability to now do. We measure what people actually do differently to reach their goals as a consequence of what you’ve built, and most important, whether you’ve made their lives better.[
Good story conversations are about who and why, not just what.
Your company can’t get what it wants unless your customers and users get something they want.
It’s that longer-term stuff that happens as a consequence of good outcomes that’s I’ll label impact.
There’s always more to build than we have time or resources to build—always.
Minimize output, and maximize outcome and impact.
your job is to minimize output, and maximize outcome and impact.
The truth is, if you build a fraction of what’s required you can still make people very happy.[
Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.
Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get fr...
This highlight has been truncated due to consecutive passage length restrictions.
Stories get their name from how they should be used, not what should be written.
Story maps are for breaking down big stories as you tell them.
I’ll say “talk and doc” (short for the verb document), which basically means don’t let your words vaporize.
Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.
Think — Write — Explain — Place
Get in the habit of writing down a little about your idea before explaining it.
write down a few words about your idea immediately after thinking it.
Explain your idea to others as you point to the sticky note or card. Use big gestures. Draw more pictures. Tell stories.
Place the card or sticky into a shared workspace where everyone can see, point to, ad...
This highlight has been truncated due to consecutive passage length restrictions.
Reorganizing cards together allows you to communicate without saying a word.
As we talk and doc, and as I write down our conversation, we’re building something really important. No, it’s not that pile of cards on the floor. The something that’s really important is shared understanding.
Mapping your story helps you find holes in your thinking.
“think mile wide, inch deep”—or
Focus on the breadth of the story before diving into the depth.
There’s always more to build than you have people, time, or money for. Always.
Mapping Helps Big Groups Build Shared Understanding
Map for a product release across multiple teams to visualize dependencies.
