I started this series with the question: If we have teams for all other aspects of an agile approach, why wouldn’t we want the product owner to also work as part of a team? Could a team reduce the feedback loop durations?
In Phase Gate or Other Serial Approaches…
When projects use a phase gate approach or an otherwise serial approach to the project, the requirements people spent a bunch of time writing down “all” the requirements, the feedback loops were very long. The requirements people (often a product manager maybe with a BA) rarely collaborated either with the customer or with the team.
Their job was to “hand off” (often, literally!) the PRD (Product Requirements Document) to the team. At the end of the project, they reviewed what the team did.
Many projects suffered from “you gave us what you asked us for but not what we need” and other problems. One of the biggest problem was that the delayed introduction of the product that fulfilled these requirements created demand for more requirements. (That post actually has a slightly different take, but it’s the same cause.)
Iterative, Incremental, and Agile Approaches Reduce the Feedback Loop Durations
Any approach other than a serial life cycle can reduce the feedback loop duration. That’s because we don’t need to address any other requirements than the ones for this project approach, for now. We will revisit the backlog. With any luck, we revisit it once the team completes what’s on its backlog now.
If you use a non-serial life cycle, you are likely collaborating with others to check your assumptions. That’s the key to creating shorter feedback loops.
One Person Cannot Do It “All” for the Product
Especially with long feedback loops, the pressure starts on the POs:
- They need to change the product backlog in the small.
- They need to change the roadmaps (the large perspective).
- They need to create more experiments and they don’t have the time to do so or to show them, so they create large features where we need it “all.”
The longer the duration of the feedback loop, the more difficult the PO role becomes. The less the PO has a shot at a sustainable pace. The more likely they are to make decisions alone, and under pressure.
And, because they’re supposed to do it “all,” the POs either don’t spend enough time with customers or with the (feature/product) team. They don’t know enough to do all of the product-based work.
That’s why I suggested the product value team. Not only do we gain the value of collaboration for managing the strategic and tactical views of the product, we can also reduce the feedback loop durations.
I suggested we need to manage the product’s evolution over time from the strategy to the tactics and back again. The shorter the feedback loops, the easier it is to replan in the small—the tactical work for the next few weeks, and in the large without too many details—the strategic work.
Each team with its PO needs short feedback loops to show progress, decide what the data means, and to replan quickly. That’s the tactical work.
The PO Value team needs shorter feedback loops to see that progress and help the project portfolio team decide if they need to change the corporate or product strategy. The PO Value team can decide “how little” for this product for now and still fulfill the corporate needs.
The product manager and the various POs have the information together. One person does not have all the information by him or herself.
I’ll do one last post to summarize (in brief !!) my thinking.
The series:
- Product Roles, Part 1: Product Managers, Product Owners, Business Analysts
- Product Roles, Part 2: The Product Value Team
- Product Roles, Part 3: Product or Feature Teams
- Product Roles, Part 4: Product Orientation and the Role of Projects
- Product Roles, Part 5: Component Teams to Create Slices
- Product Roles, Part 6: Shorten Feedback Loops
- Product Roles, Part 7: Collaboration for Short Feedback Loops
- Product Roles, Part 8, Summary
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Product Roles, Part 7: Collaboration Can Shorten Feedback Loops Opinions expressed by Java Code Geeks contributors are their own. |
