By Marty Cagan · svpg.com · LinkedIn
Marty Cagan contrasts strong product teams with weak ones, drawing on years of working with both top technology companies and struggling ones. He argues the differences are not minor but span leadership behavior, team empowerment, how funding and staffing are handled, and how product, design and engineering collaborate. Through a series of paired contrasts, he shows that strong teams pursue a mission, discover solutions through experimentation, and measure outcomes, while weak teams take orders, plan roadmaps, and celebrate output. The piece matters because it gives product leaders a concrete checklist for diagnosing their own team's habits and raising the bar.
01Key takeaways
- Measure success by business outcomes achieved, not by features released or dates met.
- Source ideas from customer observation, usage data and OKRs rather than from sales requests alone.
- Test product ideas quickly and cheaply before committing engineering effort to building them.
- Put product, design and engineering together so they co-discover solutions instead of passing documents.
- Instrument every release with analytics so decisions are driven by how customers actually use the product.
- Release small changes continuously and expect that early ideas will need several iterations to work.
02Key sections
- Why this comparison matters
- Cagan explains that he has seen both top product organizations and failing ones, and that the gap between them is profound rather than superficial. He frames the essay as a follow-up to Ben Horowitz's well-known good/bad product manager piece.
- Discovery and inspiration
- Strong teams find ideas by watching customers struggle, analyzing usage data, and applying new technology to real problems, whereas weak teams simply collect requirements from sales and customers. Strong teams also test ideas rapidly rather than debating roadmaps in meetings.
- Collaboration and empowerment
- Good teams keep product, design and engineering side by side and let engineers see discovery prototypes early, while bad teams hand off documents and only show prototypes at estimation time. Good teams also welcome outside input and get permission through protecting revenue and brand rather than waiting for approval.
- Customers, speed and quality
- Strong teams talk to customers every week, expect many ideas to fail, and treat speed as a product of good technique rather than overwork. They release continuously in small increments instead of batching testing and launch at the end.
- Measuring success
- The essay closes by contrasting teams that instrument their work and celebrate business outcomes with those that obsess over competitors and celebrate shipping output. Cagan ends by urging readers to raise the bar for their own teams.
03From the post
“A partnership dedicated to teaching best practices to product teams and product leaders”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.