More on this book
Community
Kindle Notes & Highlights
by
Jeff Patton
Read between
March 13 - June 7, 2019
Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized
Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality.
Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.”
The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.
Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.
Story conversations are about working together to arrive at a best solution to a problem we both understand.
Ultimately, we need to make some decisions to go forward with building something or not. And it’s tough to make this sort of buying decision without a price tag. For software, that usually means how long it’ll take to write the code.
Handing off all the details about the story to someone else to build doesn’t work. Don’t do that.
“design by community isn’t design by committee.”
Involving lots of folks helps everyone learn faster, but ultimately, the go/no-go decision to proceed with an opportunity falls to the product owner.
Get your solutions in front of the people who will buy or use your product. Don’t expect them to be a success at first. Iterate and improve them.
our goal is to learn something as quickly as possible,
In a Lean Startup approach, failing to learn is frequently the biggest failure.
Break stories down progressively, and just in time.
discovery work. Did you use the time? Did you use more time than you budgeted? Using too little will hurt you later when you don’t have things ready to build that you feel confident in. Using too much may hurt your chances for delivering what you’ve committed to on time.
Keep your work visible to everyone in your company. Help them be excited about what you’re doing and learning.
Spend time with users to observe them using your software doing realistic work.
You’ll need to plan to learn from each release. Please don’t release software and sit around waiting for your customers and users to complain.
Software is never really done.
Improvements made after release are the most valuable. It’s those unpredictable things that you’ll observe when users begin to adopt and use your software frequently that yield the most insight.
Great art is never finished, only abandoned.
