Description
In this model, the Product Manager and the Product Owner are the same person. When you combine these roles into the same person they:
- Set the Roadmap and identifies what needs the product will satisfy in the current, next and future time frames. This also implies Long term planning, and Communication of prioritization to team.
- Establish priorities for the overall product as well as individual teams working on the product.
- Write stories and acceptance criteria to communicate business value and provide a sufficient description of the need and the solution.
- Clarify stories for team members, and communicates across wider audience, such as customer service, marketing, etc
The Product Manager identifies the desired outcome, establishes the relevant metric and keeps everyone focused on that outcome. They also need to build a shared understanding around that outcome, and make all the pertinent product related decisions.
This model fits nicely with the concept that Product Ownership is a subset of the broader Product Management job description.
An Example
I’m following this model in my work as Product Owner for the Agile Alliance Submission System and website, as well as all the work I do on this site KBP.media.
At Agile Alliance while there are stakeholders (Agile Alliance staff, the program teams working on the conferences) and users (subscribers, members, and visitors to the website and users of the submission system), at the end of the day I make decisions about what gets done or not within the identified constraints (primarily budget, but also timeframes). I should note that I don’t decide what the constraints are, those decisions are made by the Agile Alliance Executive Director or the Board depending on the nature of the budget item.
During the initial building of the website, I didn’t spend as much time with the team building the site as I should have. This wasn’t because I was spending too much time talking to customers, it was because I was doing other work. (Product Ownership for Agile Alliance was not my full time job at that moment).
That situation is analogous to when someone from a business unit is expected to be the Product Owner for an Internal Product, but is not relieved from their “day job” responsibilities. You may be able to get away with that if the team has a great deal of domain knowledge. As I found out if you are working with a team from outside the organization or new to that domain, you really do need a constant product ownership presence.
When to Use It
When the product is small enough that one person realistically can handle the full load of the product manager with the outside commitments while still being available to serve the development team on an ongoing basis. It may also work when the team has a clear understanding of the domain so that the Product Manager/Product Owner doesn’t have to spend as much time with the team.
As I hinted above this is often the model that small businesses and start ups use simply because they are not big enough to warrant having separate people focusing on understanding customers and describing the solution.
If you have a fairly complicated product and still want to maintain the product manager as product owner model, you may find that you split the product into small subsets where each subset has someone directly responsible for that part.
Pros of the Model
- There is clear who makes the decisions about the product and priorities.
- There is a direct connection between the customers and market because the same person who is working to understand those factors also works directly with the team producing the product.
- The opportunity for confusion or mixed signals is greatly reduced.
Cons of the Model
- The person filling the product manager/product owner role is likely to become very busy and either their interaction with customers, or the team will suffer. The choice most often depends on which activity the individual in this situation prefers.
- If the product manager also has other responsibilities outside of the product (either other products or responsibilities of a day job) both customer research AND communication with the development team may suffer.
What’s Your Experience?
Have you had experience working in this model? Share your experiences in the comments.