Book Notes #15: Agile Excellence for Product Managers by Greg Cohen

Title: Agile Excellence for Product Managers
Author: Greg Cohen
Year: 2010
Pages: 152

What if product management didn’t have to feel like you were guessing in the dark?

That’s the energy behind Agile Excellence for Product Managers by Greg Cohen—a practical, refreshing guide that shows product managers how to thrive in Agile environments. It’s not a book about theory or frameworks for the sake of it.

It’s about making your job easier, your products better, and your collaboration with developers actually enjoyable.

If you’ve ever felt stuck between vague requirements, shifting priorities, and long delivery cycles, this book offers a way out—with clarity, tools, and a mindset shift that actually works.

As a result, I gave this book a rating of 7.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Agile Excellence for Product Managers

Book Overview

What If Agile Wasn’t Just for Developers?

That’s the question Greg Cohen sets out to answer in Agile Excellence for Product Managers. For many product managers, Agile can feel like something that belongs to the engineering team—a process that happens around them, not with them.

But Cohen flips that script. He argues that Agile isn’t just helpful for product managers—it might be the best thing that ever happened to the role.

The book opens by challenging a familiar frustration: the traditional waterfall approach. Anyone who’s ever written a product spec, handed it off, and then waited six months to see if the team built the right thing knows how broken that system is.

Requirements change. Customers shift. And guessing what users want far in advance leads to bloated, overbuilt features. Cohen’s point is simple—Agile doesn’t just make development faster; it makes product management smarter. It gives you feedback early, shows progress visibly, and lets you adjust as you learn, not just when it’s too late.

Scrum is the framework Cohen uses to bring this to life, but what’s refreshing is how he explains it—not from a textbook point of view, but through the lens of a product manager navigating real-world teams. You start with a backlog, prioritize based on value, and work in short sprints. The team delivers vertical slices of working functionality, not layers that only connect months later.

The product manager (often wearing the Product Owner hat) doesn’t just hand off specs—they’re present, engaged, and steering the direction with the team. Daily standups, sprint reviews, and retrospectives aren’t rituals—they’re how alignment, visibility, and continuous learning happen.

But this isn’t just a how-to manual. The strength of this book lies in how it frames Agile as a mindset shift. Documentation isn’t abandoned, but it becomes lighter and more purposeful. User stories replace bloated specs. Testing is built into development, not tacked on at the end. Planning becomes iterative, not predictive.

Even the way you think about roadmaps changes: you don’t promise everything upfront—you adapt based on learning. Cohen doesn’t pretend Agile is magic. He shows how it works when you start small, build the right team, and align around a clear vision.

One of the most interesting parts of the book is how it explores other Agile methods beyond Scrum—like Extreme Programming (XP) and Lean Software Development. These sections offer valuable perspective. XP, for instance, dials up engineering discipline through practices like pair programming and test-first development.

Lean, on the other hand, is all about eliminating waste and accelerating flow. While different in approach, both share Agile’s core DNA: focus on value, feedback, and teamwork. Cohen doesn’t push one method over another. Instead, he encourages readers to understand the principles, experiment, and adapt to their context.

The final chapters take a thoughtful turn toward what it means to lead in an Agile world. And this might be the heart of the book. Cohen emphasizes that tools, processes, and frameworks matter—but what matters most is leadership. Agile doesn’t reduce the importance of the product manager. If anything, it raises the bar.

You need to set the vision, communicate the why behind the work, protect the team from distractions, and make tough calls when trade-offs emerge. Agile gives you better information and faster feedback—but it’s still your job to lead with clarity and purpose.

Reading this book feels like sitting down with a seasoned product leader who’s been through the Agile trenches and wants to pass on the lessons—minus the fluff. It’s honest, practical, and rooted in experience.

You come away not just understanding how Agile works, but why it matters for product managers—and how to make it work for your own team.

If you’ve ever felt stuck in endless specs, misaligned launches, or the chaos of shifting priorities, this book offers a way out—not through shortcuts, but through smarter collaboration, continuous learning, and intentional leadership.

Agile, as Cohen shows, isn’t a process to follow. It’s a way to build better products by working better with people. And that’s something every product manager should care about.

Chapter by Chapter

Chapter 1 – Why Agile Is Good for Product Management

From Waterfall to Agile: A Shift in Mindset
The chapter opens by addressing a common reaction among product managers when Agile is introduced through development teams—uncertainty. But Greg Cohen quickly reassures us: Agile is not a threat, it’s a powerful ally. He contrasts it with the traditional “waterfall” development model, where teams move through phases—define, design, code, test—in a strict sequence. This model assumes we can predict everything up front, but that rarely reflects reality. Once development starts, any changes are costly, slow, and disruptive. To avoid these issues, product managers often end up guessing future needs and adding speculative features—just in case.

The Problem with Change in Traditional Development
Cohen shares his personal experience with how expensive and stressful it is to make changes late in a waterfall project. Teams face endless documentation updates, rework, and morale hits. Worse, product managers get stuck in the habit of over-engineering early on, fearing that the next chance to release might not come for another year. It’s a vicious cycle of trying to get everything right before the product even hits a customer’s hands.

Agile Brings a Smarter Way to Build Products
Agile breaks this cycle by promoting short, iterative development cycles. Instead of building full systems layer by layer, Agile teams deliver complete vertical slices—working software with UI, logic, and database that provide real value. This means feedback comes early and often, making it easier to adapt and reduce risk. For product managers, the core responsibilities remain the same—prioritizing ideas, defining products, understanding customers—but now they can do all of that with better timing and more accurate data.

Why Product Managers Should Love Agile
Cohen highlights three big reasons why Agile makes life better for product managers: more visibility, more flexibility, and better quality. Rather than relying on reports, you can track real progress through working software. You can adjust priorities before every iteration instead of getting stuck with decisions made months ago. And thanks to things like automated testing and frequent integration, quality goes up while QA time goes down.

The Agile Manifesto and Its Impact
The chapter dives into the Agile Manifesto, the core values behind the movement: individuals over processes, working software over documentation, collaboration over contracts, and responding to change over following a plan. Cohen explains what these really mean for product managers. For instance, he reflects on times he hid behind documentation instead of engaging with the real product. Agile removes those barriers by making working software the center of conversations. It also shifts the focus from rigid plans to meaningful collaboration and learning.

Why Agile Works So Well
Cohen wraps up by explaining why Agile is effective: it supports software as an empirical process—one based on exploration, not prediction. Agile provides daily visibility through standups, spreads knowledge across the team, and uses tight feedback loops to drive learning. Instead of waiting for the perfect plan, teams learn by doing, inspecting, and adjusting frequently. This makes Agile a perfect fit for the unpredictable, creative nature of product development.

The Bottom Line
Agile doesn’t change the core job of product management—it makes it better. Product managers can now move faster, respond smarter, and deliver more value. And while processes will need to adapt, the payoff is worth it: better products, happier teams, and more successful launches.

Chapter 2 – Understanding Scrum

Why Scrum?
Scrum is one of the most widely adopted Agile frameworks, and for good reason—it’s structured, flexible, and practical. Greg Cohen uses Scrum to introduce Agile concepts because it’s familiar and easy to grasp. But he also reminds us: no matter which Agile method your team uses, the core principles remain the same. Try it “by the book” for a few cycles before tailoring it to your team’s culture and needs—you might be surprised how well the basics actually work.

How Scrum Works
At the heart of Scrum is the Product Backlog—a prioritized list of everything the product needs, from features and fixes to enhancements and architectural work. The Product Owner (usually the product manager) owns and manages this backlog. When a Sprint begins, the team pulls top-priority items into a time-boxed iteration (typically two to four weeks) and commits to building them. Once work starts, it’s locked in. The backlog can change between Sprints, but not during one.

Scrum is flexible enough to allow the team to start building with only a few fully defined items. This allows for movement without waiting for perfect clarity. But Cohen cautions: Agile isn’t a shortcut for skipping requirements gathering. It just helps you adapt and refine as you go.

Inside the Sprint
Each Sprint includes four key phases: Planning, Development, Review, and Retrospective. Planning sets the Sprint Goal and decides what to build. Development includes not just coding, but also unit testing and acceptance testing. The team meets daily for a standup to report progress, share plans, and flag roadblocks. At the end, the team presents what they built in a Sprint Review, then reflects and improves in a Retrospective.

The Scrum Team Roles
Scrum has three core roles: Product Owner, Scrum Master, and the Development Team. The Product Owner sets priorities and serves as the voice of the customer. The Scrum Master is the facilitator, making sure the team follows Scrum, stays productive, and overcomes any blockers. The team itself is cross-functional, self-organizing, and committed to the Sprint Goal. There’s no hierarchy—everyone contributes to getting things done.

Planning: What and How
Sprint Planning is broken into two meetings: deciding what to build and then figuring out how to build it. The first meeting focuses on priorities and the Sprint Goal, led by the Product Owner. The second is more tactical, as the team creates a Sprint Backlog—detailed tasks that break down the work, usually in chunks of 4–16 hours. Only the team can change this backlog. If the team hits a wall during the Sprint, they work with the Product Owner to adjust the scope or even the goal.

Daily Standup and Rapid Feedback
The Daily Scrum is a short, focused check-in to keep things moving. Everyone answers three questions: what they did yesterday, what they’ll do today, and any blockers. This keeps communication tight, builds team trust, and prevents surprises. Standups should happen at the same time and place every day—and yes, actually standing helps keep them short.

Testing and Definition of Done
Cohen stresses the importance of unit testing in Agile. These tests are written by engineers to ensure code works and doesn’t break existing functionality. Some teams even use test-driven development (TDD), writing tests before the code. Unit tests must always pass—no exceptions. Acceptance tests, on the other hand, are business-focused, and the Product Manager decides if the feature is “done enough” based on those results.

Review, Retrospective, and Learning
The Sprint Review is where the team demos what they built and gets feedback. It’s informal and focused on understanding, not showmanship—many teams ban slides entirely. Then comes the Retrospective, a team-only meeting to reflect on what went well and what could be improved. While Product Owners traditionally didn’t attend, Cohen encourages product managers to be part of this process—collaboration and continuous improvement depend on open communication.

When a Sprint Needs to End Early
Sometimes, things change dramatically and a Sprint needs to be canceled—this is called a Sprint Termination. It’s rare, but it can happen if the Sprint Goal becomes irrelevant, if progress is blocked, or if stakeholders disrupt the team’s priorities. After termination, a new planning meeting sets the direction again.

Building on the Basics
This chapter lays out the core mechanics of Scrum in a clear and grounded way. With this foundation, Cohen prepares us to go deeper into how product managers can use Agile to improve release management and planning. The key idea here is that Scrum provides the rhythm—but it’s the product manager’s role to make sure that rhythm builds toward a valuable, customer-centered product.

Chapter 3 – Release Management

From Roadmap to Reality
This chapter zooms out from individual Sprints to look at the bigger picture: how product releases are managed in Agile. Greg Cohen starts by reminding us that releases should be mapped to a broader product roadmap, which itself is guided by strategy. Once you’ve divided the roadmap into releases, you can start organizing the work: define the Product Backlog for each release, break it down into Sprints, and get the development team moving.

Sizing Work with Stories
Agile uses user stories—short, plain-language descriptions of features—as the building blocks of the Product Backlog. These are sized by the development team using relative effort, often expressed in story points (or more whimsically, jellybeans or “truffle fish”). The key is that the estimates reflect effort, not time. Sometimes a team can’t estimate a story without exploring it first—this is when they create a time-boxed research task called a spike.

Understanding Velocity
Once stories are sized, teams can start tracking velocity—how much work (in story points) they complete per iteration. By consistently measuring velocity over time, teams get a clear view of their throughput and can plan accordingly. If the team consistently completes 27 story points per Sprint, that becomes a baseline for forecasting future progress. Velocity is a powerful tool, as long as the team stays consistent in how they estimate.

Visualizing Progress: Charts That Matter
Cohen introduces several useful charts that give product managers insight into how things are going:

• The velocity chart compares actual vs. planned performance across iterations. It’s great for spotting trends.
• The cumulative story point view shows how much has been completed over time—useful for tracking overall momentum.
• The release burndown chart, Cohen’s personal favorite, counts down remaining work and clearly shows whether the team is on track.

These visuals help identify whether scope needs to be adjusted or expectations managed—especially when reality doesn’t match the original plan.

Handling Scope Changes with Agility
Unlike traditional methods where scope changes are a nightmare, Agile embraces them. If a new story is more important than something already planned, it can be added to the release—as long as everyone understands the impact. Cohen shows how burndown charts help make scope changes transparent. If the release date can’t change, you cut something else. And since work is only defined right before it starts, it’s easier to remove lower-priority stories without disruption.

Managing the Sprint from the Inside
Agile also provides tools for managing progress within a Sprint. Tasks for each user story are broken into smaller steps, estimated in hours, and tracked on a task board. Each day, developers update the remaining hours for their tasks—not how much time they’ve spent, but what’s left. These updates feed into a daily iteration burndown chart, helping spot issues early. If the team is behind, they might reduce scope mid-Sprint to stay on track.

Task Boards: The Visual Hub of Progress
Whether it’s physical or digital, the task board becomes the team’s dashboard. Stories start on the left (Product Backlog), move through columns like “In Process” and “Verify,” and land in “Completed” when done. It’s simple, visible, and incredibly effective. Many teams also post their burndown chart right in the middle for added transparency.

The Role of the Product Manager
For product managers, these tools are gold. You don’t need long status meetings—just attend the standup, glance at the task board, and watch the burndown. If things are off track, help adjust scope or the Sprint Goal. If things are ahead, maybe another story can be pulled in. And after every Sprint, update your release tracking to reflect reality.

In Summary
Release management in Agile isn’t about rigid timelines and fixed scopes—it’s about flexibility, visibility, and smart trade-offs. Cohen shows how to use simple tools like velocity, burndown charts, and task boards to stay informed and in control. The goal is clear: build the right product, stay aligned with strategy, and keep delivering value.

Chapter 4 – Release Planning

Start with Strategy, Not Just Sprints
Release planning doesn’t begin with tasks or story points—it starts with your company’s business strategy. Greg Cohen reminds us that the product roadmap should reflect the bigger vision, which is shaped by market context, customer needs, competition, and technology. From there, we break the roadmap into releases and define the Product Backlog by identifying features needed for the next 9 to 15 months.

At this stage, perfection isn’t the goal. The top of the backlog should be well-defined, but the lower parts can act as placeholders. The plan will evolve, and that’s okay. Agile expects change.

Two Planning Approaches: Fixed Date or Fixed Scope
When mapping a release, you can go one of two ways. If you have a fixed release date, calculate how many Sprints fit into your timeline and how many story points can fit per Sprint based on the team’s velocity. You then work backward to distribute backlog items across the iterations.

If the date is flexible, you define a minimum marketable feature set (MMF)—the smallest collection of features that delivers real value. Once you know the total effort (in story points), you calculate how many Sprints are needed. The date is set by the work required, not the calendar.

Cohen reminds us that plans rarely survive first contact with reality. Agile gives us the flexibility to re-prioritize and adapt with each Sprint, making plans smarter over time.

Iteration Planning: A Practical Exercise
The chapter includes an example where the team can take on 31 story points in the next iteration. Working from the top of the backlog, the product manager selects stories that fit—until they hit the limit. But what if a high-priority story is too large? That’s a critical moment. Stakeholders might need to reprioritize, or split a large story into smaller parts. Agile lets teams make these calls late in the game, when they have the most information and clarity.

Juggling Multiple Iterations at Once
Agile product managers don’t just think about one Sprint at a time. They’re working across at least four iterations simultaneously:

• Validating just-released features with customers
• Supporting the current Sprint team
• Preparing stories for the next Sprint
• Researching and testing ideas for future Sprints

It might sound like a lot, but with small pieces and regular feedback, it becomes manageable. The key is rhythm and flow.

Don’t Over-Document Too Soon
In Agile, requirements are detailed just in time—as they move up the backlog. Writing everything up front creates “inventory” that can go to waste if plans change. Cohen recommends doing the work at the last responsible moment to avoid rework or wasted effort. He also introduces the concept of evergreen requirements—non-urgent but useful items (like scalability or architecture upgrades) that can be slotted in if more urgent stories aren’t ready in time.

UX Design Belongs in Agile Too
User experience design is critical, and it fits into Agile with a few adjustments. Instead of designing everything upfront, UX teams focus on the highest-priority items first. This often happens in Iteration Zero, where no working software is delivered, but foundational research and setup occur.

Ideally, you have UX specialists. They can either be part of the Product Owner team or embedded in the development team. Either way, they guide decisions on user-facing features and look ahead to what’s coming next—making sure design and development stay in sync.

The Big Picture
This chapter shows that Agile release planning isn’t about locking everything down. It’s about combining direction and flexibility—starting from strategy, planning based on value, and adjusting based on learning. Product managers become orchestrators, constantly balancing short-term priorities with long-term vision, while collaborating across teams and iterations to deliver meaningful results.

Chapter 5 – Documentation

Rethinking Documentation in Agile
Agile values working software over comprehensive documentation, but that doesn’t mean documentation disappears. For product managers, it’s still a key part of the job. What changes is how much you document, when you document, and how you communicate with your team. The shift is toward lighter, more conversational formats—starting with user stories.

User Stories as Living Requirements
User stories are short, plain-language descriptions of what a user wants to do and why. They’re usually written on index cards and kept intentionally brief. The purpose isn’t to spell everything out—it’s to spark a conversation between the product manager and the development team. A story should be small enough to estimate and fit into a single iteration. If it’s too big, it’s considered an epic and needs to be broken down before it’s ready to be developed.

The structure is simple:
As a <user type>, I want to <do something>, so that I can <get some value>.

This format keeps the focus on the user and the value behind the feature. It also helps the team stay creative in how they implement the solution. Instead of saying “the system shall…” you’re inviting collaboration and flexibility.

Writing Good Stories: The INVEST Criteria
A solid user story follows the INVEST model:

• Independent – It can stand alone and be moved freely in the backlog.
• Negotiable – It’s a starting point for discussion, not a strict order.
• Valuable – It must deliver clear value to the user or customer.
• Estimable – It has enough detail to allow rough sizing.
• Small – It’s small enough to be completed in a Sprint.
• Testable – There are clear criteria to know when it’s done.

Acceptance Criteria and Testing
On the back of each story card, the team writes acceptance criteria—functional rules and edge cases that help define “done.” These aren’t bug hunts—they’re clear, testable conditions that the team agrees to. Product managers often facilitate this process, brainstorming with QA and developers to clarify expectations. Acceptance tests help the engineer know when to stop coding and give QA a checklist to verify functionality.

Starting from High-Level Goals
If you’re new to user stories, it helps to begin with high-level goals. For example, “The customer can search for cameras” or “The customer can complete a purchase.” From there, you can drill down into more detailed user stories or even define minimum marketable features (MMFs)—the smallest version of a feature that provides value. MMFs are useful for planning and prioritizing since they ensure the product is always potentially shippable.

Handling Non-Functional Requirements
Not all requirements fit neatly into a user story format. Things like performance, scalability, or browser compatibility often sound awkward when forced into that template. Cohen suggests just writing them clearly as constraints—e.g., “The application must support Firefox, Safari, and Chrome.” Alternatively, use system quality cards, which define how well the system should perform, including metrics like scale, meter, target, and benchmark.

Splitting Stories for Flexibility
Large stories should be split into smaller ones that deliver value incrementally. Cohen gives a great example of a “cross-sell at checkout” feature that was broken into seven smaller stories. The key is to split based on value—delivering what matters most first. This gives flexibility in iteration planning and allows teams to adjust scope without losing the core feature.

Beyond Stories: When More Documentation Helps
While user stories are Agile’s go-to, sometimes product requirement documents (PRDs) are still useful—especially for complex features. They help clarify vision and align stakeholders. In Agile, you might create a PRD for a big feature rather than an entire release. Not everything needs to go into a PRD, but it’s good to know what questions a strong PRD answers: strategy, timeline, constraints, scalability, usability, security, and so on.

Other documentation formats like functional or technical specs, wikis, or code comments can also support the team. The trick is to choose what’s valuable, not what’s habitual. Agile encourages you to cut anything that’s unused or unnecessary and replace it with better communication.

The Big Picture
Documentation in Agile isn’t about removing structure—it’s about making it lean and purposeful. Whether you use user stories, MMFs, constraint cards, or system quality metrics, the goal is always the same: ensure shared understanding while staying adaptable. Great documentation supports conversations, not replaces them.

Chapter 6 – Starting Out

Where to Begin with Agile
If your team is new to Agile, don’t dive in headfirst with your biggest, most complex product. Start small. Greg Cohen recommends choosing a self-contained project, ideally one that doesn’t depend on other teams and involves fewer than nine developers. A brand-new product or a full rewrite of an old one works best—especially since automated testing is key, and legacy code makes that tough. Agile’s strengths show up fast, so projects with visible customer impact or frustrated users are great candidates. Think quick wins and clear demos.

Build the Right Team First
The team you pick can make or break your first Agile project. Cohen’s advice: stack the deck in your favor. Avoid difficult personalities for this early run—Agile makes dysfunction visible, and one bad fit can stall momentum. Look for people who take responsibility, commit to goals, and work well together. In Scrum, the team owns the Sprint commitment, so everyone has to be accountable—not just to their own tasks, but to each other.

Start with a Vision, Not Just Tasks
Agile isn’t just about speeding up development—it’s about aligning everyone around a shared product vision and strategy. Cohen distinguishes between the high-level vision (the customer pain and how you’ll solve it) and the more detailed strategy (the market, features, business model, and positioning). For example, an e-commerce site might focus on “helping photography enthusiasts,” which then drives design choices like offering rich product advice instead of just low prices.

What a Solid Product Strategy Includes
The chapter walks through the components of a strong product strategy: market opportunity, MMF (minimum marketable feature), business model, positioning (the 5 Ps: Product, Pricing, Promotion, Place, Proof), and of course, timeline and budget. From that foundation, you build the release plan—a structured view of what’s being delivered, when, and how success will be measured. While not unique to Agile, the release plan is critical, especially if the product has visibility across the organization.

Creating the Product Backlog Fast
If you’re in a high-pressure situation—tight deadline, no roadmap, and leadership breathing down your neck—call for an Iteration Zero. This short prep phase helps developers set up environments and gives product managers time to write stories and validate designs. Use story-writing workshops with developers and stakeholders to jumpstart the backlog, and don’t forget to gather “evergreen” technical stories that can move ahead while business requirements are being refined.

How to Prioritize: Business Value Comes First
Once you have a backlog, it needs to be prioritized by business value. Easy in theory, tricky in practice. When ROI models are feasible, use them—but many companies don’t have the data to do this reliably. In that case, relative prioritization based on collective team judgment is your best bet. Cohen offers a helpful tool here: the Prioritization Matrix. This simple table lets teams rank features based on weighted criteria like customer pain, revenue potential, and competitive pressure. It brings gut feelings into the open and helps teams align on what matters most.

Set the Right Iteration Cadence
Iteration length defines your team’s rhythm. Cohen suggests two weeks for fast-moving products, thirty days for more traditional software. Weekly iterations can help with urgent fixes or highly volatile projects. The goal is to balance meaningful progress with frequent feedback. Too long, and you lose agility. Too short, and you may not finish anything valuable.

Estimating Work: Keep It Collaborative
For teams new to estimation, Cohen offers two techniques. First, relative sizing—line up stories from smallest to largest, assign the smallest one story point, and estimate the rest accordingly. Second, try Planning Poker®, a team game where everyone reveals their estimate simultaneously, then discusses outliers until consensus is reached. The game encourages conversation, surfaces unknowns, and uses a Fibonacci-like scale to avoid false precision.

Rethinking Testing and Beta
Agile also changes how you think about QA and beta testing. Web products with short release cycles might bake testing right into iterations or run A/B tests on live features. For traditional software, you might need dedicated QA Sprints for more in-depth testing. Bugs found during a Sprint should be fixed immediately; those found later go into the backlog. Cohen advises against keeping a separate bug backlog—it just adds overhead.

Marketing, Sales, and the Agile Flow
Agile doesn’t just affect engineering. Marketing and sales need to adjust too—especially with more frequent releases. Instead of big campaigns, marketing shifts to smaller, ongoing efforts: website updates, collateral refreshes, press snippets, and social buzz. Agile keeps the conversation alive, giving your product a steady voice instead of waiting for a “big launch.” One example Cohen highlights is ReturnPath, where even the marketing team runs on Agile, with standups, iterations, and a project backlog.

Sharing Roadmaps the Agile Way
Finally, Agile encourages more transparency. Make your Product Backlog visible—internally, at least—so teams know what’s coming and why. Cohen advises creating “external” roadmaps for customers when needed, but internally, align around the idea that the backlog and roadmap are intentions, not promises. If someone in sales over-commits to a customer, that’s a training issue—not a reason to lock down visibility.

The Bottom Line
Starting Agile isn’t just about picking a framework—it’s about picking the right project, building the right team, and leading with a clear vision. This chapter lays out practical steps, real-world tactics, and honest advice for getting your first Agile project off the ground successfully—and setting up your organization for long-term agility.

Chapter 7 – Organizing Around Agile

What It Means to Be a Product Owner
In Agile, especially in Scrum, the product manager often takes on the role of Product Owner. Greg Cohen explains this isn’t just a title shift—it comes with added responsibilities. You’ll need to be available to the team for daily questions, write user stories regularly, help with or own acceptance testing, and maintain a steady flow of requirements. Agile doesn’t necessarily increase your workload, but it does spread it more evenly across the development cycle.

No One-Size-Fits-All Structure
There’s no single perfect way to organize product teams in Agile. Cohen emphasizes that individual skills, team dynamics, and the product’s complexity matter more than formal titles or org charts. What works well for one company—or even one team—might not work elsewhere. The key is to start with a setup that feels right, observe how it works, and adjust as needed.

Organizing Teams by Size
For one Scrum team, the product manager usually acts as the Product Owner and handles both strategic and tactical responsibilities.
With two teams, responsibilities are often split: the product manager focuses on backlog and iterations, while a product marketing manager takes on outbound activities like sales enablement and pricing.
When you scale to three or more teams, a Chief Product Owner may be introduced to oversee the strategy and roadmap, while individual Product Owners support each Scrum team. These roles may be held by junior PMs or business analysts, depending on experience and structure.

Handling Distributed Teams
Distributed teams come with extra challenges—time zones, cultural differences, and limited face-to-face interaction make alignment harder. Cohen shares practical tips: have each site run its own standup, followed by a shared daily teleconference; assign Product Owner and Scrum Master proxies at each site; encourage in-person visits; and use digital collaboration tools (like wikis, Jira, or Rally) to create a shared task board. Good tech—like webcams and VoIP—helps keep the team connected and human.

Managing Multiple Projects
Agile scales across multiple products using a Scrum of Scrums, a regular sync among Scrum Masters (or team leads) to manage interdependencies. They discuss progress, blockers, upcoming risks, and anything that might affect another team. This coordination ensures that platforms, tools, and applications stay aligned. A shared, visual roadmap also helps track these dependencies clearly.

Spotting and Fixing Team Dysfunctions
Agile puts teamwork front and center—but teams don’t always perform well. Cohen draws on Patrick Lencioni’s five dysfunctions of a team to diagnose problems:

1. Lack of trust – team members aren’t open about mistakes or weaknesses.
2. Fear of conflict – debates are avoided, and real commitment is missing.
3. Lack of commitment – individuals check out when they don’t agree with team decisions.
4. Avoidance of accountability – no one calls out unproductive behavior.
5. Inattention to results – personal goals trump team goals.

Signs of these issues include short retrospectives with no depth, blame games, duplicated work due to mistrust, skipped standups, and Scrum Masters assigning tasks (instead of teams self-organizing). The product manager can help facilitate conversations, but deeply rooted issues may need a coach or outside support.

When Healthy Teams Still Struggle
Even high-functioning teams can lose their rhythm. Some common issues include:

• Customers not giving feedback early, only reacting later.
• Stories growing too large to fit into a single iteration.
• Cutting corners on testing or documentation to hit velocity targets.
• Passing unit tests but failing functional ones—indicating the need for better automation.
• Overloaded refactoring Sprints due to neglecting cleanup earlier.

Daily retrospectives can help new or struggling teams build good habits and identify issues early. Over time, these can shift to traditional end-of-iteration retrospectives.

Staffing Agile Teams
The Agile engineer is more than technically strong—they need to communicate well and be team players. Not everyone thrives in Agile. Cohen makes a clear distinction between the able, the willing, and the unwilling. While skills can be taught, attitude is harder to change. If someone isn’t a fit, it’s better—for everyone—to help them transition to an individual contributor role or find a better-suited opportunity elsewhere.

The Bottom Line
Organizing for Agile success means thinking beyond roles and structures. It’s about building teams that trust, communicate, and adapt. With the right people, shared goals, and supportive processes, Agile becomes more than a method—it becomes a culture of collaboration and continuous improvement.

Chapter 8 – A Look at Extreme Programming and Lean Software Development

Beyond Scrum: Exploring XP and Lean
So far, the book has focused on Scrum, but Agile isn’t a one-size-fits-all approach. In this chapter, Greg Cohen explores two other Agile methods: Extreme Programming (XP) and Lean Software Development. Both bring different strengths, and understanding them helps product managers pick the right tools for their teams and products.

What Makes XP So “Extreme”
Extreme Programming was created by Kent Beck in the late ’90s to help small, fast-moving teams deliver value even when requirements were vague or kept changing. XP works by turning best practices up to eleven. If code reviews are good, XP does them constantly through pair programming. If testing helps catch bugs, XP insists on automated unit tests that run multiple times a day. If refactoring improves design, do it all the time. XP is all about working in short, fast iterations and keeping things simple.

XP values four core things: communication, simplicity, feedback, and courage. Communication is built into the process through pair programming, estimating together, and involving users. Simplicity means solving today’s problems, not guessing tomorrow’s. Feedback comes from everywhere—tests, estimates, velocity, acceptance testing, and real users. And courage is about moving fast, trying new ideas, refactoring boldly, and staying focused on delivering value, not covering yourself.

The Twelve Practices of XP
Cohen walks through XP’s twelve core practices, starting with the planning game—a collaboration between product managers and developers to decide scope and effort. There’s a strong emphasis on small, frequent releases and keeping the design as simple as possible. Developers write unit tests first and maintain them rigorously. Refactoring is constant, pair programming is the norm, and any developer can touch any part of the code. The team integrates and builds frequently, usually several times a day. XP also encourages sustainable pace—no overtime two weeks in a row—and having a real customer (often the product manager) available to answer questions. Coding standards ensure everyone can understand and work on anyone’s code.

Cohen especially highlights three practices that tie deeply into product management: the planning game, testing, and continuous integration. The planning game keeps business and technical teams aligned in real conversations. Testing, especially unit tests, reduces risk and gives confidence that late changes won’t break the system. And continuous integration makes progress visible, helping product managers confirm that what’s being built matches what they intended.

XP Skips Tasks, and That’s on Purpose
XP teams often don’t break user stories into tasks. They believe the planning meeting is when the team knows the least about how to implement the work, so locking into tasks too early isn’t helpful. Developers are trusted to figure out the best approach as they dive into the code. This cuts down on planning time and gives the team more freedom to work effectively.

Enter Lean Software Development
Next, Cohen turns to Lean Software Development, adapted from Toyota’s manufacturing model. Lean focuses on delivering value fast by reducing waste, limiting work in progress, and keeping the flow smooth. It’s not about time-boxed iterations like Scrum or XP—it’s about continuous flow.

Lean’s seven principles are: eliminate waste, build integrity in, see the whole, decide as late as possible, deliver as fast as possible, amplify learning, and empower the team. Each of these connects directly to the product manager’s role.

Understanding and Eliminating Waste
The chapter goes into detail on waste—any activity that doesn’t create value for the customer. In software, this includes partially done work, unnecessary processes, unused features, task switching, waiting, excess motion (like unnecessary hand-offs), and defects. Cohen shares a tool called Value Stream Mapping to spot these inefficiencies. You map every step of your development process, including wait times, to see how much value is actually being added. He compares two real examples from his experience—one where only 41% of the time added value, and another, more Agile approach that delivered faster with far less waste.

Build Integrity In
Lean talks about two types of integrity: perceived and conceptual. Perceived integrity is about how well the product delights the customer. Conceptual integrity is about how well the system fits together internally. Both depend on good communication—between product managers, users, and developers. Cohen shares personal examples of products with high and low integrity and emphasizes that Agile’s iterative approach naturally supports building integrity by encouraging early and frequent feedback.

See the Whole and Measure the Right Things
Lean encourages teams to optimize the whole system, not just individual parts. That means you might slow down development to help QA catch up or shift measurements from individual performance to team results. The idea is to deliver better outcomes for the customer, not just meet internal metrics.

Other Lean Principles: Delay, Deliver Fast, Learn Fast
Lean also recommends delaying decisions until the last responsible moment—when you have enough information but before delays become costly. Delivering fast reduces risk and keeps feedback loops tight. Learning is constant in Agile, and Lean highlights how rapid iteration helps teams discover the best solutions. Empowerment matters too—product managers should set direction and frame problems, then trust the team to find the best way forward.

Defining Value in Lean Terms
Value is defined by the customer—what they need, when they need it, at a price they’re willing to pay. Product managers lead the effort to uncover that value by staying close to customers, challenging assumptions, and looking for opportunities beyond the product itself. Sometimes value lies not in features but in the services around them. Cohen suggests mapping the customer’s own value stream to find new ways to help.

Lean in Practice
Unlike Scrum, Lean doesn’t use time-boxed iterations. Work flows continuously across a Kanban-style board. Requirements enter the system only when there’s capacity, and tasks are visualized as they move through each stage. Instead of story points or hours, Lean teams may track average throughput and use cumulative flow diagrams to monitor progress. Estimating may be minimized or skipped altogether—but this can limit valuable discussions around cost and trade-offs. Product managers need to keep those conversations alive, even if estimates are light.

In Summary
This chapter opens up Agile’s toolbox by diving into XP and Lean. XP is intense and disciplined, with practices that force collaboration, testing, and simplicity. Lean is broader, more flow-focused, and obsessed with delivering value by cutting waste. Both offer powerful lessons for product managers: communicate constantly, focus on value, measure the right things, and build feedback into every step. With these tools, Agile becomes more than a framework—it becomes a mindset and a path to better products.

Chapter 9 – Conclusion

Laying the Groundwork for Agile Success
This final chapter wraps up the journey by reinforcing the essentials of Agile for product managers. Greg Cohen brings it all together by highlighting what product managers need to understand—not just the mechanics, but the mindset. Agile isn’t just a process tweak; it’s a full shift in how products are planned, built, and delivered.

Where Agile Meets Process Maturity
The chapter starts by addressing a common tension: Agile versus structured process models like CMMI (Capability Maturity Model Integration). Cohen explains that CMMI outlines five levels of process maturity, from chaotic and reactive (Level 1) to fully optimized and continuously improving (Level 5). Many Agile skeptics see it as incompatible with CMMI, but Cohen argues they’re not enemies. Agile methods are not ad hoc—they’re disciplined frameworks designed for uncertainty. In fact, companies like Systematic have successfully blended the two: CMMI for high-level planning and Agile for iterative execution, using tools like Sprint Reviews, risk meetings, and definitions of “Done” and “Ready” to bridge the gap.

Choosing the Right Agile Method for the Job
People often ask Cohen which Agile method is best—but he avoids giving a one-size-fits-all answer. Different methods suit different situations. XP is very developer-focused and prescriptive about how code is written. Scrum, in contrast, is more about managing projects. Adaptive Software Development (ASD) is more of a mindset than a method. While companies have scaled XP and Scrum to hundreds of team members, the right choice depends on product type, company culture, lifecycle stage, and team personalities. There’s no perfect formula—just a rough guide, and even that comes with exceptions.

The Trade-Offs of Organizational Agility
Agile is great for fast-moving projects with short cycles and rapidly changing needs—think web services. But as projects grow in size, complexity, and risk, more structure may be needed. Regulated environments, mission-critical systems, or situations where your product integrates with others often require more documentation, formal approvals, and up-front planning. High command-and-control cultures may demand Gantt charts and extra reporting. If a customer is doing parallel development or trust is low, more detailed specs are often necessary. Cohen stresses the importance of finding your balance on the Agile-to-Traditional spectrum. The right level of agility depends on your context, and your job is to keep questioning how much structure is truly necessary.

Bringing It All Together
Cohen recaps the Agile product management process in a clear, practical way:
Start with a strong product strategy and turn that into a roadmap. Break the roadmap into releases, then populate your Product Backlog with just enough detail for the next 60–90 days. Use velocity and burndown charts to plan and adjust. Map stories to Sprints, and review strategy monthly to stay aligned. Work across multiple iterations: gather feedback, validate designs, support the current team, and assess what was just delivered. Keep a few evergreen stories in the backlog—technically challenging items that require little product input—for when the team has capacity but you’re waiting on details.

What Real Leadership Looks Like
The most important message in this chapter—and maybe the whole book—is about leadership. Product managers need to do more than write good stories. They need to set the vision, lead with conviction, and become the go-to expert on the customer, the product, the market, and the team. That means spending time with users, making tough trade-offs, protecting the team from distractions, and acting with integrity. Cohen encourages product managers to motivate through purpose, not just process. Paint the picture of why the work matters. Step back and give the team room to solve problems. And when things go right, share credit—when they go wrong, take responsibility.

Why Agile Still Matters
Cohen ends by restating why Agile is such a powerful model for product management. It provides visibility through velocity and working software. It enhances quality with continuous testing and early validation. And it delivers unmatched flexibility to respond to new ideas, market shifts, and customer feedback at any point in the release. Agile helps teams build not just faster, but smarter.

This isn’t the end of the journey, though. Best practices are always evolving, and Agile must be adapted to each team’s reality. Cohen encourages readers to keep learning, stay grounded in the principles, and lead the way toward truly excellent product management.

4 Key Ideas from Agile Excellence for Product Managers

6 Main Lessons from Agile Excellence for Product Managers

My Book Highlights & Quotes

The Product Backlog will not motivate your team. You need to paint the picture of why they should be motivated

Leading well is the single most important thing you can do to be a successful product manager with Agile

Each task should be about four to sixteen hours of work. The task list is called the Sprint Backlog

Acquiring satisfied customers who will give good references is the long-term goal, and it means working with the customer to understand what is needed, then working with the development team to understand what is possible

Using the roadmap, define releases if you have not already done this, and create the Product Backlog by listing the key features needed to realize nine to fifteen months of roadmap vision. The backlog should match the release schedule and be prioritized by business value

With the release and Product Backlog defined, we further subdivide it into Sprints. There are two approaches that can be used. The first is setting the release date and the other is setting the minimum marketable feature (MMF) set

Simplicity—It is better to meet only the current need today and pay a little more tomorrow to change it if the requirement grows than to place a bet by developing more complicated functionality that may never be used

The Product Owner manages the creation and prioritization of Product Backlog items. If product management has its ducks in a row, the backlog is well thought-out and maps the product vision and strategic goals of the company

Requirements in the Product Backlog are typically written as user stories, which are one- or two-sentence software requirements written in plain business language. The Product Backlog can therefore be viewed as a prioritized list of user stories

There are three benefits to using more granular stories: 1. They make it easier for the team to accurately estimate the effort involved. Iteration planning is improved because each story is less of the total iteration’s capacity. It becomes more straightforward to reduce the scope (if needed) within an iteration without compromising the Sprint Goal

Conclusion

This book gives you the tools to navigate change, lead with purpose, and build things that actually matter to customers.

Whether you’re launching something new, stuck in a messy process, or just want to get better at your craft, this book meets you where you are—and gives you a smarter way forward.

If you’re a product manager wondering how to lead in an Agile world, this is the book you’ve been waiting for.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: