Product Roles, Part 8: Summary: Collaborate at All Levels for the Product

Johanna RothmanMay 14th, 2019Last Updated: May 13th, 2019

0 24 3 minutes read

Too many teams have overloaded Product Owners. The teams and PO have trouble connecting the organization’s strategy to what the teams deliver. The teams, PO, management, all think they need big planning. Too often, the POs don’t do small-enough replanning.

They’re not living the principles of the agile manifesto.

That insufficient collaboration means the PO doesn’t always connect the strategy to the tactics. Or, the PO can’t decide on changes at the tactical level or the strategic level. And, when the PO has to commit to a lot of work (say a quarter), they commit too early to be able to change.

The PO has too much work to do. The role is not sustainable for one human person.

I first discussed the various roles we often need to define and refine the product as we proceed. That was in Product Roles, Part 1: Product Managers, Product Owners, Business Analysts. We need people to think at the strategic level. And, we need people to think at the tactical level. (No, I have not yet connected the various product strategies to the project portfolio. Later.)

Sometimes, one person can do the strategic and tactical work. If you work in either a small startup or an agency where you deliver work for hire, you might have a PO who interacts with the customer. You might be lucky to have a real customer to work with. In that case, one person can do it all.

Most organizations have larger efforts. That’s when they need a product value team as in Product Roles, Part 2: The Product Value Team. It’s the team’s job to use an agile approach to define the strategy, discover ways to deliver that strategy and replan. The team can have each other’s backs. The team can meet at a cadence and refine/replan/rework whatever they need to “re”. They don’t have to know an entire year or quarter’s worth at a time.

The Product Value Team can create short feedback loops between the various kinds of planning, the team, and the customer.

Then, I veered off to the kinds of teams you need or you might have. That’s in Product Roles, Part 3: Product or Feature Teams. When you organize teams to work through the architecture, you have the shortest possible cycle time. You might have component teams and they will have a longer cycle time.

I wrote about sequencing projects in Product Roles, Part 4: Product Orientation and the Role of Projects. I have only worked in and consulted with organizations that have more products (or ideas) than they have teams to do the work. They sequence the projects by flowing work through teams. Well, the organizations who release often do flow work through the teams. The organizations that try to do it “all” tend to thrash and deliver much less.

I returned to what you can do with component teams in Product Roles, Part 5: Component Teams to Create Slices. Just because I will do almost anything to avoid component teams doesn’t mean your managers will. That’s why I recommend you measure your feature cycle time. Not team cycle time. The addition of all the various component teams’ cycle time for a feature you can release.

I returned to the question of feedback loops in Product Roles, Part 6: Shorten Feedback Loops. What kind of collaboration do you need to create short feedback loops?

I suggested why collaboration works in Product Roles, Part 7: Collaboration Can Shorten Feedback Loops. I mentioned the four various kinds of life cycles and explained how the non-agile lifecycles pressure the PO. The longer your cycle time to release a feature, the longer it takes to replan, and the more pressure your POs have.

I don’t care what you call your life cycle. Here’s a quick assessment to see if your agile approach works for you:

Can you release what you want, when you want?

If not, your agile approach is not working for you. Consider inspecting-and-adapting your approach.

I tried to wrap up here, in this post.

I hope you consider a product value team to shepherd the business value of your product and relieve the PO of an unsustainable role. How can the various teams collaborate inside the team and between teams to shorten cycle time, reduce feedback loops, and deliver what the customer wants?

That’s why we need and have Product Owners.

The series:

Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Product Roles, Part 8: Summary: Collaborate at All Levels for the Product

Opinions expressed by Java Code Geeks contributors are their own.