It was the early 2010s. Our team was in charge of SAP support for a large global company gathered in a conference room where a person whom we had never met before was going to show us the new IT support management system. A state-of-the-art Cloud solution was supposed to replace our outdated software and unite the IT teams worldwide in harmony.
This was a product of a multi-month project involving the vendor, key employees from several regions, and a consulting company. After implementation, it would affect the daily work of every single IT support employee. The presenter was very proud to demonstrate it and was clearly expecting some level of excitement from us. However, instead, he got quickly bombarded by some tough questions.
Why is this process more complex and time-consuming than what we have now? Why are all these fields mandatory? And, why is this step needed? What will this information be used for? How is this better than the old system? As more questions and details poured in, the poor presenter started getting paler by the minute.
The Product Owner Song
The presenter in question had an equivalent of product owner (PO) role in the Agile process. What does this role entail? Product Owner is responsible for maximizing the value of the product and ensuring that it is aligned with customer and stakeholder needs. Or, as this PO song puts it succinctly: “What to build? What not to build?”
Let The Right People In
In the story above, the person selected to represent our team was, unfortunately, picked up mostly because they were the only ones available. They turned out to have a very different understanding of desired features from the rest of the team. As a result, the final product included about a dozen fields that no one else cared for and unnecessary steps in several processes.
We see it frequently at the design stage that a person who is available or just “screams the loudest” is not necessarily the most reliable source of information. One of the product owner’s tasks is to listen to different opinions and ask questions, such as “what value would this feature add?”
Demo Early
Another mistake made in the story above was not getting feedback from the team earlier in the project. If only we had seen the prototype before, we could easily point to all the issues. Unfortunately, the team was not considered as a stakeholder and did not receive any communication.
In our projects at Mindset, we advocate for the POs to demo products to the stakeholders and anyone who would listen as soon as possible (“demo early”). Some POs are reluctant to present a half-baked product, but getting feedback before it’s too late is vital in any Agile project.
Prioritization / MVP
Even with the best planning, it’s not unusual to run into technical or organizational challenges that can delay work on certain features. In addition to “What to build? What not to build?” another important PO’s task is prioritizing what to build first so that even in the worst-case scenario, the result is a working product and not just an assorted collection of bells and whistles.
One of my favorite principles is “monkey first,” that is about putting a trained monkey on a pedestal. This principle suggests to focus on the more complex part (training monkey) because, the simpler part (pedestal) is not very valuable without it.
The Product owner is also the one who defines the minimum viable product (MVP). It is important to understand that MVP is about prioritization. Sometimes we hear, “What do you mean MVP? We want ALL of it!” It might be counter-intuitive, but MVP is, in fact, more helpful in delivering more and better features because it allows developers to focus and deliver features to demo early.
* * *
Please reach out to our team for advice on product ownership and Agile product development. We can help you build products that your customers love!
View our LinkedIn, here.
