Tools and Techniques to Help You Be an Efficient Product Owner
Last week, I had the opportunity to attend the two-day Passionate Product Owner workshop with Jeff Patton. As the name states, this workshop is all about equipping product owners (POs) with tools and techniques to do their jobs efficiently. I made tons of notes during those two days and came away with a lot of new ideas to experiment with. Here are some of the key takeaways.
According to Jeff, the role of a product owner is similar to that of the product manager. The product owner is responsible for building a valuable, usable, and feasible product. It is a shame that most product owners in Scrum projects are treated as domain experts, tasked with handling and prioritizing requirements. Forget about usability; many POs in companies don’t even have the visibility about the budget allocated for the project.
Many companies have dedicated production support or “maintenance” teams, whose duty is to focus on quickly fixing the defects from the production systems. Many companies run like this—like a factory. The green field teams keep churning code, deploy it to production, and then hand it over to the support team for further maintenance.
This separation of the coding and maintenance teams is a highly dysfunctional way to work. The above system absolves the PO from ownership, thus orphaning the product. The real ownership is generated when the team developing the code maintains it as well.
Backlog grooming was discussed in the workshop as well. These grooming sessions are popularly used by product owners and the Scrum team to plan the next sprint. Jeff had some valuable suggestions about improving these grooming meetings. The POs should look at cleaning up the backlog rather than just prioritizing or detailing out the requirements.
Going back to the basics of user stories, Kent Beck introduced the concept of user stories during the days of extreme programming (XP). The intent was to replace the hundred pages of requirement specifications with something that encourages discussion between the users.
However, teams new to agile seem to have forgotten the three Cs of user stories—Card, Conversation, Confirmation. These teams end up writing one liners or lengthy notes. Here are some tips with examples that you might find handy.
I have seen many teams using personas during discovery phases. Employing personas will make your product strategy better because they help us picture different users and understand their likely behaviors. At the end of the day, success of a new product lies in its ability to significantly improve the ways your users do things by satisfying their needs and desires.
Before I conclude, let me ask you this: Does your product owner truly own the product?
