More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Read between
September 13 - October 15, 2019
Good teams obsess over their reference customers. Bad teams obsess over their competitors.
“Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don't yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.”
Stable product teams. One of the prerequisites for consistent innovation is a team that has had a chance to learn the space, technologies, and customer pain. This doesn't happen if the members of the team are constantly shifting.
Engineers in discovery. So often the key to innovation is the engineers on the team, but this means (a) including them from the very beginning, and not just at the end and (b) exposing them directly to the customer pain.
Time to innovate. At scale, it's very possible that your product teams are entirely consumed just doing what we call keep the lights on activities. Fixing bugs, implementing capabilities for different parts of the business, addressing technical debt, and more. If this is your situation, you shouldn't be surprised at the lack of innovation. Some of this is normal and healthy, but be sure that your teams have the room to also pursue harder and more impactful problems.
Lack of delivery management. The most important function of the delivery manager is to remove impediments, and the list of impediments grows non‐linearly as the technology organization grows. Most impediments won't go away quickly without someone actively chasing them down.
Infrequent release cycles. Most teams with slow velocity have release vehicles that are too infrequent. Your team should release no less frequently than every two weeks (very good teams release multiple times per day). Correcting this typically means getting serious about test automation and release automation so the team can move quickly and release with confidence.
Not including engineers early enough during product discovery. The engineers need to participate in product discovery from the start of ideation. They will often contribute alternative approaches that can be significantly faster to implement if you include them early enough in the process for the product manager and designer to adjust. If not, their critical input will come too late in the process.

