I’m going to leave this right here: I think being a Product Owner is the most difficult roles in Scrum, and one of the least supported, which adds to the difficulty. I see so many new Product Owners struggling with the role, I started the Tampa Bay Product Owner Meetup – and if you are in the area, we’d love to have you come!
I wanted to write about a great tool I’ve borrowed from a product master, Roman Pichler. It helps with the following scenarios I often see in engagements.
- The Product Owner has an exciting new idea they want to implement, they bring it to the development team, they deliver a passionate description. The team launches right into development – but several sprints deep it feels like a struggle, and someone asks: “So – what exactly are we building – and… why? Another common question when things go awry: “Did anyone think about… (fill in the workaround, risk, issue, here…)”
- Conversely, we have experienced Product Owners who make the mistake of going too deep, designing the solution before they have clarified the ‘what’ and ‘why.’ This reduces the discovery process with the development team who could help innovate and eliminate waste long before they start writing code.
Hopefully we have all experienced the success stories too. Success comes when execution of a new product starts with the foundation of shared understanding within the whole Scrum Team. The product takes flight, development seems to fall into place, morale and creativity flow as easily as the banter in the Scrum events.
We all know these anti-patterns but how do we avoid them?