This is the third article in our series “CTO asks” addressing real issues, which CTO’s need to tackle in their work. This question was asked by Cornel Studach from Teqable.
Who is a Product Owner and what makes a great Product Owner?
Michał Życiński, Customer Success Manager at XSolve answers his question:
The Internet is awash with the articles explaining why every iPhone user should upgrade his iOS device to the new iPhone X or iPhone 8. There are also bunch of online adverts encouraging consumers to buy Apple’s products if they, by some miracle, still don’t have one. Not to mention the other side of the Internet, telling you why it’s alright to still use your iPhone 7 or iPhone 6S. No matter if you’re an Apple fan or just a regular mobile user, you’ve probably read all about it at least once recently. All this brings us to the ultimate question, which is, “What makes an iPhone a great product?”. I know it’s a lot more than just its features and good design and I want to look behind the marketing curtain in order to focus on the human factor.
Behind Product Ownership
You don’t have to have lived on this planet for very long to know who Steve Jobs was. Besides being a great entrepreneur and a co-founder of Apple, he was a visionary Product Owner first and foremost.
According to the Scrum Guide by Scrum founders Ken Schwaber and Jeff Sutherland, the Product Owner, “is responsible for maximizing the value of the product resulting from the work of the Development Team.” This means that the Product Owner is the sole person responsible for developing the product vision and illuminating the product roadmap. He or she ensures a common understanding of what needs to be done but does not push the development team on how to bring that vision to life.
Back in the day, Steve Jobs had a vision of how he wanted the iPhone to look and feel as well as function, but he focused on only delivering requirements and specifications to his engineering team.
Inspired by Jobs’ exemplary work and my experience working with clients here at XSolve, I would like to dive into five common mistakes most Scrum teams struggle with. Many of them have already been mentioned by Roman Pichler in Agile Product Management with Scrum and by Jacek Wieczorek in Labirynty Scruma (only Polish edition so far). Both are highly recommended reading.
1. No product vision and poor strategy
It’s happened to me many times: customers who approach us have a more or less clear idea of what they want to accomplish with a helping hand from our development teams but they haven’t looked further than their current needs. Do you think Apple aren’t already thinking about the next iPhone?
A Product Owner has to envision the final product and be able to communicate the product roadmap with ease. Everyone involved in the product development process must know what to do, but most importantly why they’re doing it.
If you, as a CTO or CEO are thinking about outsourcing your software development you have to predict the desired outcome and be crystal-clear about the goals mapped out to achieve that outcome, and the outcomes to follow. Otherwise, both the planning and decision-making processes are doomed to fail. What’s more, the team’s creativity is killed and you won’t be tapping into recommendations for further product development, like new features or scalability.
2. Lack of empowerment
Probably the most frustrating Scrum process breakdown I’ve ever experienced is when the Product Owner is dependent on a supervisor or investor and has to consult them on every major decision. As a consequence, the Product Owner struggles to do an effective job and finds it difficult to align with the Scrum team. This, in turn generates waste by causing delays in the development process. When the Product Owner is underpowered, it forces the team to question the decision-making authority, eventually leading to unwanted delays and even burnout. Software engineers will eventually stop trusting the Product Owner’s judgment and start developing functionalities without guidance. No way did that ever happen to Steve Jobs!
One former client of mine actually struggled with this problem from the very beginning of our partnership. First of all, he was from outside the company and thus treated his job of “Product Owner” as a side project. Based on my experience, someone from the outside usually cannot commit fully to the project and does not have legitimate authority to accept or approve major changes to the project. Second of all, the product vision and its requirements were handed over to him long after they were made, impacting on his ownership of the vision and commitment to it. This can be a huge challenge for any agile development company. Last but not least, most of project tasks had to be confirmed with the business owner he worked for beforehand or – even worse – after planning meetings. The conclusion? He wasn’t a Product Owner but a classic Project Manager.
3. No single person responsible
Having a committee of Product Owners can be as harmful as having none at all. You can be sure that at Apple, Steve Jobs had a singular vision and played a singular role.
In the committee scenario, it always turns out there’s no one guiding the team, no one helping to shape a common purpose, and no one facilitating decision making together with the Scrum Master. There has to be a single person responsible for ordering a product backlog in order to maintain focus and high team efficiency. Only then does the team know which user story or bug they need to prioritise and know exactly who can clear up any potential doubts.
4. Technical tyran
Have you ever thought that programming literacy make you stand out from the crowd? In most social interactions and small talks I bet it does but in an agile product management reality it can be a real pain in the neck. A Product Owner with technical expertise can be tempted to make authoritarian decisions regarding architecture and technical aspects, leaving no room for the team’s creativity and expertise. Thus, the self-organizing team presented by the Scrum Guide becomes just an empty wish. This happened to me frequently in one project of mine when the Product Owner had quite an impressive technology background and he not only kept suggesting programming methods to solve particular problems but also had a tendency to disagree with my team of experts. In these cases, the Scrum Master should act as a sort of communication bridge, a liaison between the Product Owner and the development team, explaining and enforcing the importance of independence when it comes to coding practices.
5. No business context
Alongside the poor explanation of the product vision that I mentioned at the very beginning, a lack of business context can lead to a mechanical approach to the project instead of a genuine developmental attitude to the product design. You can bet that Apple’s team never lose sight of the bigger business picture. To keep that focus, I suggest regular feedback to the team about customer views and business needs at weekly or biweekly Scrum meetings.
Excellent Product Ownership
Being a successful Product Owner can be challenging role and most of the time it requires personal and organizational changes. Probably no one taught Steve Jobs his responsibilities and I’m sure he wasn’t the best Product Owner the world has ever seen but he and Apple avoided the above mistakes and the results continue to lead the development of technology. My point is that the role of a Scrum organization is to guide customers and help them to grow and not just to write lines of code for their products. Without a common understanding of each other’s accountabilities, I can guarantee that sooner or later the project will fail. It’s essential to choose the right Product Owner for your project, respect their decisions, and ensure that the role comes with the necessary authority to go with the responsibilities. Without that you cannot expect the development team to follow him. As long as you do this, are confident in your product, and enable the development team to live and breathe your vision, you’re on the right track to success.