The goal of the product manager is to maximize business impact and customer outcomes with a minimal amount of developed feature output. However, the team is then quite far removed from strategy and discovery, and there is no-one who can truly connect strategy and discovery with delivery The problem with splitting the title and the role into two people The goal of the PM It must be admitted, that having a PM and a PO is better than just having a PM that is entirely overwhelmed and works only on delivering on the latest request from sales or marketing. And if that is to be done, it makes sense to carve out the PO role on the scrum team to another person.Īfterall, if the work is split among two people, the PM and the PO, then at least someone is working on strategy and discovery. It is understandable to want to introduce a new role to which the burden of working with the team to refine the things that are to be developed. But the next question is then: Delegate to whom? The illusory solution of delegating part of the burden from the PM to a PO It is wholly applicable to the challenge PMs face when trying get out from under urgent work to do refinement of what the team should build, so that they can do the important work of strategy and discovery. The Eisenhower Matrix is a good framework to illustrate the difference between urgent and important. Delegation as the way to escape urgent busy-work and get important work done Trying to avoid this is what Melissa Perri describes in her aptly named book Escaping the Build Trap. When this happens, the team turns into a feature factory. If the PM does not have an own thought-through perspective on this, it is indeed very hard to resist the pull from stakeholder who requests features. If they do this, it means they have very little time to spend on the important work of strategy and discovery, which means they won't have a clear perspective on how feature outputs link with business impact and customer outcomes. PMs risk of spending almost all of their time on preparing delivery, refining things to build.
Under-investing in important strategy and discovery work After all, if the team would "run idle", that would be a huge cost.īecause of this, many PMs that are stressed out by the many different activities they have to do and the messiness of their process, turn to focus on solving the urgent problem of detailing things for the team to build.
There will always be a sense that the PM needs to make sure to spend time to detail things for the team to develop. This is a tendency that causes big problems for PMs. When there is not enough time to do what you have to do, there is a tendency for the most urgent thing pull the hardest, even at the expense of things that might actually be more important. The urgent pull to detail things for the team to build The product management process can be said to consist of the steps Strategy, Prioritization, Discovery, Refinement, Development, and Iteration (when I refer to Delivery, I mean the combination of Refinement and Development).Īcross this process, the PM must handle many different artifacts that live in different and disparate tools, and they have to involve different team members and stakeholders that have different perspectives and preferred ways to interact.Īll-in-all, this means that the many different activities described earlier have to be performed within a messy process. A messy, iterative process with many artefacts and stakeholders It is clear that there are indeed many different activities that they are expected to do, and that it is hard to make time to do them all, not to speak of learning all the wide array of product management skills required. Here is their definition of the two titles: The SAFe framework is maybe the most known proponent of this school. The interface between the two is that the PM hands over high-level requirements that the PO then turns into user stories and details them together with the team. The PM is customer-facing, and the PO is team-facing.
The one-person school believes that the PM and the PO should be the same person, i.e., that it is the PM that should have the PO role on the team. user stories, bugs, improvements) are detailed to the point where they can be developed by the team. The PO is responsible for prioritizing the backlog and for that tickets in the backlog (e.g. The role of the PO in Scrum is essentially to manage the backlog. In the Scrum methodology, there is role called "product owner". The job description of the person is to manage a certain product or area of a product, and their goal is to make that product successful. Initially, trying not to put down any value judgement, I'd like to clarify the stance of the two schools.
0 kommentar(er)
