More on this book
Community
Kindle Notes & Highlights
If we give each other time to explain our thoughts with words and pictures, we build shared understanding.
Stop trying to write the perfect document.
Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding.
Stories in Agile development get their name from how they should be used, not what you write down.
your shared understanding is filling in details that aren’t in the document.
If you’re sitting at a conference table while a single person types what you say into a story management system, you’re probably doing it wrong.
what’s most important isn’t what’s written down — it’s what we remember when we read it. That’s the vacation photo factor.
Entirely new products you can build Features to add to an existing product Enhancements to products that you’ve built
what's the difference between new features and enhancements?
requirements are just another name for the ideas we have that would help people.
They’re not happy because they read the release notes, or downloaded the app to their mobile device.
Outcome is what happens when things come out
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.[
how things will change for them later. That positive change later is really why they’d want it.
Minimize output, and maximize outcome and impact.
And my company and team didn’t have infinite time, so I had to work hard to figure out the least I could build to make people happy.
The truth is, if you build a fraction of what’s required you can still make people very happy.[
“talk and doc” (short for the verb document), which basically means don’t let your words vaporize. Write them down on cards so you can refer back to them later.
quickly helps everyone recall the conversation about it.
Get to the end of the story before getting lost in the details. Focus on the breadth of the story before diving into the depth.
Notice how when you put “and then” in between what’s written on each card, you get a nice story.
When it came to prioritizing, it wouldn’t have worked to identify the must-haves, should-haves, and could-haves — it was either in or out. It was very simple: “we cannot go live without this” above the line, and everything else below it.
I personally believe that scope doesn’t creep; understanding grows.
estimating the time to do something we’ve never done before is something we suck at.
Focus on outcomes — what users need to do and see when the system comes out — and slice out releases that will get you those outcomes.
what kinds of web properties and market events should anchor the next releases.
posted sticky notes to the left of each slice with a few words describing their intention for each release slice — their target outcomes.
the list isn’t a bunch of features. It’s a list of real-world benefits — because, remember, your job isn’t to build software, it’s to change the world.
Focusing on specific target outcomes is the secret to prioritizing development work.
if you don’t know what your target outcomes are — the specific benefits you’re trying to get — then prioritization is close to impossible.
The secret to breaking down that really big chunk of output was to focus on a smaller, specific outcome.
you can’t please everyone all the time.
It all seems important. But then we step back and think about the specific people who will use our product, and what they’ll need to accomplish to be successful.
prioritization model: Differentiator A feature that set them apart from their competition Spoiler A feature that is moving in on someone else’s differentiator Cost reducer A feature that reduces the organization costs Table stakes A feature necessary to compete in the marketplace
The minimum viable product is the smallest product release that successfully achieves its desired outcomes.
Minimum is a subjective term. So be specific about who it’s subjective to — because it’s not you.
But the alternative is the “HiPPO” method — the “highest paid person’s opinion.” That one sucks worse.
Most of the things I work with organizations on aren’t whole, new products. They’re new features or capabilities, or improvements on features already out there. So the term solution seems to make more sense.
The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.
Eric makes the important point that we need to create smaller experiments, prototypes that test our hypothesis about what’s minimal and viable.
A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.
One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be.
He had conversations with leadership in his company to understand more. They discussed: What is the big idea? Who are the customers? Who are the companies we think would buy the product? Who are the users? Who are the types of people inside those companies we think would use the product, and what would they be using it for? Why would they want it? What problems would it solve for customers and users that they couldn’t solve today? What benefit would they get from buying and using it? Why are we building it? If we build this product and it’s successful, how does that help us?
Validate that the problems you’re solving really exist.
building up a pool of people he thinks are good candidates to try his new software. Some companies refer to these people as customer development partners.
He moved to envision his solution first as a bunch of simple narrative stories — user scenarios.
Ultimately, he wants to put his solution in front of his users to see what they think. But he knows he first needs to feel confident it solves their problems before he puts it in front of them.
celebrate the bad news, because you could have received the same bad news months later, after you’d built the software. That’s when it really sucks.
his job is to minimize the amount he builds and still keep people happy. How much could he take away and still have a viable solution?
the people who said they’d like it and use it are just guessing, too.
