When I think of POs and the team, I think of learning in several loops:
- The PO learns when the team finishes small features or creates a prototype so the PO can see what the team is thinking/delivering.
- The team learns more about its process and what the PO wants.
- If the Product Manager sees the demo, the Product Manager sees the progress against the roadmap and can integrate that learning into thinking about what the product needs now, and later.
Note that no one can learn if they can’t see progress against the backlog and roadmap.
There are two inter-related needs: Small stories so the team can deliver and seeing how those small stories fit into the big picture.
I don’t know how to separate these two needs in agile. If you can’t deliver something small, no one, the team, the PO, the customer, can’t learn from it. If you don’t deliver, you can’t change the big picture (or the small picture) of where the product is headed. If you can’t change, you find yourself not delivering the product you want when you want. It’s a mess.
When you don’t have small stories and you can’t deliver value frequently, you end up with interdependent features. These features don’t have to be interdependent. The interdependencies arise from the organization (who does what) and think they are talking about interdependencies in the features, but a root cause of those interdependencies are the fact that those features are not small and coherent. See my curlicue features post.
That means that the PO needs to learn about the features in depth. BAs can certainly help. Product Managers can help. And, the PO is with the team more often than the Product Manager. The PO needs to help the team realize when they have a structure that does not work for small features. Or, when the PO can’t know how to create feature sets out of a humungous feature. The team and the PO have to work together to get the most value from the team on a regular basis.
This is why I see the learning at several levels:
- The Product Manager works with the customers to understand what customers need when, and when to ignore customers. It is both true that the customer is always right and the customer does not know what she wants. (I won’t tell you how long it took me to get a smart phone. Now, I don’t know how I could live without one. You cannot depend on only customers to guide your product decisions.)
- The PO Value Team discusses the ranking/when the customers need which features. When I see great PO Value teams, they start discussing when to have which features from the feature sets.
- The PO (and BA) work with the team to learn what the team can do when so they can provide small stories. They also learn from the team when the team delivers finished work.
The larger the features the less feedback and the less learning.
So, I’ve written a lot here. Let me summarize.
Part 1 was about the “problem” of only addressing features, not the defects or technical debt. If you have a big picture, you can see the whole product as you want it, over time. For me, the PO “problem” is that the PO cannot be outside-facing and inward-working at the same time. It is not possible for one human to do so.
Part 2 was about how you can think about making smaller stories, so you have feature sets, not one humungous feature.
Part 3 was about ranking. If you think about value, you are on the right track. I particularly like value for learning. That might mean the team spikes, or delivers some quick wins, or several features across many feature sets (breadth-first, not depth-first). Or, it could mean you attack some technical debt or defects. What is most valuable for you now? (If you, as a PO have feature-itis, you are doing yourself and your team a disservice. Think about the entire customer experience.)
Part 4 talked about how you might want to organize a Product Owner value team. Only the PO works with the team on a backlog, and the PO does not have to do “everything” alone.
If you would like to learn how to be a practical, pragmatic Product Owner, please join me at the Practical Product Owner workshop, beginning Aug 23, 2016. You will learn by working on your roadmaps, stories, and your particular challenges. You will learn how to deliver what your customers value and need—all your customers, including your product development team.
| Reference: | Product Owners and Learning, Part 5 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
