I’ve written a lot lately about the dissonance in the way Scrum defines the “Product Owner” role and responsibilities and the reality of what occurs in many companies, particularly Independent Software Vendors (ISVs).
These posts included:
- The Scrum Title “Product Owner” must die!
- A new (and better) definition of Product Owner
- Goodbye “Product Owner”, Hello “Backlog Manager”
John Peltier, at the Product Owner Vision blog, took note of these posts, and wrote one on topic as well. His post is entitled:
It’s a good post which you should read in it’s entirety. John discusses some differences between Scrum used custom software projects vs. ISVs.
The focus of all my writing on Scrum/Agile has always been on Scrum in ISVs and the organizational structures into which Scrum (a software development methodology) must play. Yes, Scrum is not an island unto itself. It must fit into an existing organization that DOESN’T view the Scrum team as the center of all activities.
John presents the following diagram showing where he sees the “Backlog Manager” as fitting best.
i.e. for custom projects – the use of “Product Owner” fits best, but in ISVs, the Backlog Manager fits best AFTER the first release (i.e. after release 1.0) of a product.
John’s reasons for this split in the ISV column are summarized (and paraphrased) below. Read his post for the full details:
- For and ISV, if a PM also acts as a PO, the PO role can occupy him/her to the point that it takes away from outward, more forward looking market sensing and requirement gathering activities
- Thus the role can be offloaded to someone else (e.g. a Technical PM), but only after the product’s initial release to market
- This is because, for that initial release, the PM will need to spend significant time up front understanding the market, market problems, defining a vision, requirements etc. and then spending many months working with development team to bring that initial release to fruition
- Part of those months with development are spent performing backlog management, but the key for the PM is to have a clear vision of the product and ensure that first release is built correctly. i.e. the Scrum team needs first hand information from the PM vs. second hand information from an intermediary “backlog manager”.
- After version 1.0 of a new product is released, with the vision, business case etc. established, the PM, “looking for additional market segments and business opportunities” etc. and thus a separation of “responsibility between a Product Manager and Product Owner makes sense.”
Why I disagree with John 🙂
Not to pick on John as I think he did a great job in his post in trying to reason through the roles and scenarios, but I do have to disagree with John’s conclusion that the best fit for the Backlog Manager ROLE in ISVs excludes the v1.0 release of products.
1. Research is not a solitary process
First let me say that John’s description of the basic process of researching, defining and building a new product is fundamentally correct.
It doesn’t matter whether the company uses Agile/Scrum/Waterfall or other methodology. A fair bit of up front research and market/customer/prospect validation is needed to identify a new product opportunity. But, in my experience over many new products, and I’d say as a best practice, this work is not, and should not, be done in isolation by a lone PM or even a small PM team. It must include key members of the Development (and ideally Product Marketing) organization.
A major goal of the initial research is developing a common understanding of the market opportunity, and this cannot be done by excluding key team members. Conveying the findings and getting full buy-in on the results of weeks (or months) of external research is very difficult.
By including members of the development team (even 1 or 2 people if your company is small), in a number of customer/prospect/partner meetings and discussions, not only can a joint vision of the problem space be developed early on, but that first hand exposure helps ensure Development buy-in when solutions are being proposed and defined.
2. The first release is not that different from other releases
John’s view of the first (v1.0) release, that it is significantly different from successive releases (e.g. 1.1, 2.0 etc.) and thus requires different focus from the PM (team) does not change the need or scope of “backlog management”.
If a clear vision of the product-to-be is understood by the team, the sprint planning, story definition and backlog prioritization are not different than in any other release. Perhaps there is more oversight needed to get early development efforts right, but that’s true regardless of whether the methodology is Agile or not.
i.e. The “Backlog Manager” is simply a formal definition of the interface role that is needed in a Scrum environment. The vision, business context etc. are still there — provided by Product Management — but the tactical activities specific to Scrum processes are defined in the Backlog Manager role.
3. The tactical vs. strategic balance is always an issue for (understaffed) Product Management teams
This problem that John describes is very real, but is not specific to Agile or Scrum. Understaffed PM teams are rampant across high-technology companies. Far too many companies view “the Product Manager” as the lone individual at the center of the storm. No other team — whether marketing, sales, engineering, finance etc. — is viewed this way. If Product Management is so strategic, staff it for success.
If you believe that Scrum requires a dedicated role to work with the Scrum team to give them business context, then add that headcount to your plan. Don’t over burden a single individual with that responsibility. It’s a recipe for failure — or perhaps mediocrity at best.
In Summary
I agree with John that for custom software development, a “Product Owner” can be the right term to use given the 1:1 relationship between the (solitary) customer (in most cases) and the Scrum team. But for ISVs, even in small startups, the reality is that a very different organizational model exists. They key need that the Scrum processes impose and that must be filled is that of backlog grooming, sprint/backlog management and the communication/facilitation required during the development cycle.
This new, tactical ROLE is not about “Product Ownership” but about facilitating product development over successive releases and ensuring appropriate business context is inserted into that process. It may be part of a larger job description or a dedicated role. But, in short, whether as a v1.0 release, or any subsequent release, that ROLE is “Backlog Manager”.
Saeed
Tweet this: Why the “Backlog Manager” fits best for Scrum focused ISVs http://wp.me/pXBON-2KZ #prodmgmt #agile #scrum