I had the opportunity to present on this topic recently at a ScrumIndia Conference organised in NCR, India.
As part of my current role of a Project Manager, I have been playing the role of Product Owner for all the projects I have been managing. I started as the vanilla Product Owner that Scrum outlines; continuing to improvise when hit by an obstacle or looking for opportunities to improve. It has been a tremendous learning experience while working with all kinds of clients and teams of different maturity levels on projects of various complexities. My presentation at the conference talked about such practices / beliefs / views.
My experience has primarily been on client projects rather than on internal projects / products. So, to that extent, my perspective might be skewed. But, in my humble opinion, the points I illustrate are independent of the sponsor of the project (external or internal).
So lets start…
Summarising the literature that is available on Agile, one can define the typical role of PO as follows:
- Responsible for maximizing the value of the work that the Team does
- Owns the vision and overall goals
- Owns the prioritized list of what needs to be produced to achieve maximum value and ROI (the Product Backlog)
- Decides when product is ready to ship
Now, lets see what would separate a PO 2.0 from a PO:
1. PO stands for Proud Owner
PO doesn’t stand for just Product Owner. It also stands for Proud Owner.
PO 2.0 doesn’t consider a project as just one of the many. He is proud to be a part of it. Like Harley owners who consider themselves privileged to own one (I am a Bulleteer myself so I know the feeling), the PO wears the project name on his sleeve and at times even flaunts it (I have done that a couple of times 😉 )
2. Says NO to Feature Requests
A PO is meant to define the product by prioritising the features that would go into a product. While a traditional PO would blindly go forward with a feature request from the sponsor, PO 2.0 would actively say no to features that he feels would not add significant value to the project. So, he wouldn’t go by the sponsor’s whims and fancies but base his decisions on logic and past experience. The above graphic illustrates why its best to say no to some feature requests.
Many a times I have had feature requests that I have found to be frivolous or for one-time use only. I have always preferred simplicity in such scenarios. For example, instead of providing an email editing functionality to the admin for an email that would be sent only once, I preferred taking the content and design from the client and having the devs trigger it themselves.
3. Takes Input from the TEAM
A PO is expected to take his inputs from the client and prioritise that for devs to work on. However, PO 2.0 also takes input from the team. They are where the rubber meets the road. Sometimes, they can provide critical insight into what feature to add and what to remove in order to make the whole product sharper.
On a recent e-commerce project, the team pointed out that we should include the product categories and brands into meta tags for products as that would be helpful on the SEO front. Quite a sensible advise, I would say.
4. Creates for Himself
PO 2.0 doesn’t work for someone else. He works for himself, even when he is the surrogate client. He takes the term “Product Owner” to its literal meaning. It is this belief in his heart that motivates his decisions. When the guys at 37Signals went about creating a project management tool for themselves, they ended up creating one that has now earned the love of millions of people around the globe. Ditto with Blinksale.
When I am envisioning the Information Architecture of a project or ruminating about a feature, I alway keep in mind, “how would I like it; how would I prefer to use it”.
5. Defends the Product
This ties in closely with my points 1 and 4 above. PO 2.0 is as passionate about the product as the sponsor / client. Which is why he considers it his responsibility to defend the product. Its his baby too and he would not let any harm come to it.
Sometime back, we had launched a project that drew a lot of attention, some good and some bad. I came across this blogger who was ranting about the application while knowing zilch about it. I wrote back to him clarifying all his points with links to the relevant sections on the app. Never got a response back from him but further comments from readers were heartening.
6. Is the SCRUM MASTER
I would wait while you get some air ‘cos I know you would have gasped on reading this!
Scrum framework details the roles and responsibilities for a Product Owner and a ScrumMaster. However, I am yet to find a scenario where they contradict each other. It is widely held that the PO and SM should be different persons but I have been performing these 2 roles for so many years now and on so many projects and have been successful all along.
I don’t subscribe to the view that the PO is supposed to be pushy about features and at loggerheads with the SM. I have tried to balance these two roles and successfully so.
I would take your leave now so that you can ponder over that last thought…
You can download the slide deck I had presented here. (size: 3.2MB)