The Story of a Product Owner
A man of the road, not the road map
9 July 2014
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
I knew a product owner. He was a man who could turn a failing product into a product that kept demanding a huge infrastructure scaling. Let's call him Mr. R. The irony here is that Mr. R never knew that he was a product owner. He never took credit for what he did. Instead, he credited the demand of increasing business for the increased use of the product. I think software products do have a "Law of the Few." Certain persons are able to build and promote a product much better than others. The personality traits that Mr. R possessed directly matched our Scrum values.
I strongly believe that Mr. R's work personality was naturally aligned to our five Scrum values, which made him a great product owner. So I am going to list some of the strong personality traits of Mr. R, those that I noticed during my golden days with him, and I will try mapping them to those five Scrum values. It's an attempt to learn from a naturally evolved product owner. As I already mentioned, he still don't know the term "product owner." Now, a question will arise naturally: "Is it enough to learn from one person?" Obviously the answer is no, it's not enough. But I strongly believe that our learning is best when our "mirror neurons" are at work, especially when we observe another person who helps our evolution as a product owner. Mr. R seems to be a good place to start.
He is not a technology kid . . .
Mr. R started his life as a warehouse employee. He always thought about real business operations and then transferred those thoughts to IT requirements. He never pretended to understand IT. If we asked him to do UAT, he simply would let the team know that he didn't know what UAT was! Then we would have to explain that UAT stands for "user acceptance test," which means that he should test and accept the functionality as fit for use. Similarly, in every aspect of the project Mr. R never pretended that he knew something about IT that he actually didn't know. This made life easier both for the developers and for himself. Developers knew exactly what to expect from him in any given situation. They actually had the pleasure of training him in some of their tools. He simply never thought about things in IT terms; he did everything in business terms. He never asked for any HTML5 features in requirements. And when we offered something like that, he appreciated it but was always focused on the necessary features.
He exemplifies . . .
Whenever we ask about why this is a requirement, he will be able to explain it in perfect business sense. There was a nice story behind everything. There were perfect characters, histories, places, names, amounts, times, and more. For example, once we saw a requirement like this: A product that is produced needs five hours of "rest" before packaging. We asked him why the product needed to "rest" before shipping. He explained, "When the product comes out of the machine it's usually warm, and it needs to cool down for a day or two. But in peak season, five hours will do! Nowadays the quality of plastic is so and so. . . ." He kept going on and on.
Mr. R was not an executive in a suit who had recently graduated from a business school. He was someone who knew the real world. We can also say that he did not know that he was going to end up as a product owner in the early stages of his career. He mentioned that a few times to the team, that he never thought he would be working on an IT project. The developers got enthusiastic when they knew their system was going to fit somewhere in the real world. Mr. R gave requirements that had a "stickiness factor." Developers were able to remember his stories better than other stories. His clarifications and statements were "contagious business information."
He cuts to the chase . . .
Focus, Courage, Commitment
Mr. R wrote stories that were always sticking to a point. He involved stakeholders as much as he could, and in fact most of the requirements he noted were written when he was in a warehouse or a production factory, noted in the real words of the stakeholders. Sometimes his documents were only a few lines. If that's all that was needed, that's all he wrote. He never gave the team extra suggestions or fillers. Even when we met him in a business meeting, he was more of a good listener. He drove meetings toward the product objectives. He was good at paperwork. He carried a file that in fact was his "product backlog." He had a good sense of time. If we asked him to do an acceptance test or a requirement specification, most of the time he was good at estimating how long it would take. He had the habit of doing things right the first time. This is an important quality in a product owner. If the product owner expects to review his work many times, then he quickly becomes a bottleneck, which was simply not the case with Mr. R.
His testing is the acid test . . .
Once we asked Mr. R to do a test of an order registration screen. The guys who deployed it didn't do a smoke test, especially because it was a weekend. And they were not expecting Mr. R to test it so quickly on a Friday evening. But Mr. R sent a panic mail that same evening. Small things like this earn the respect of the development team. They now knew that if you ask Mr. R to test, he will test. And he will not wait to give you feedback -- when he tests, he means business. I personally have seen him stop releases three times due to unsatisfactory tests. Rigor in test and acceptance is an important quality in a product owner. This is where the product owner earns respect from the stakeholder for the work that the developers do for the product. Mr. R always said that the respect a stakeholder has for a product is directly proportional to the sales we make out of the product.
He loves to hang out . . .
Once the development team were in a mood to party, and Mr. R was packing his things for his flight home that evening after a big project go-live. When we asked him to come with us for a beer, he happily accepted. Things like this give the developers a sense of friendship. The team loves to work with him, because he leaves less distance between himself and the team. This easy approachability is a very important quality in a product owner. If your product owner is someone you get to see only in business lunches, the development team is not going to build a world-class product. Mr. R somehow had this wisdom. He had close relationship with most of the developers. Developers enjoyed working with him. His simplicity made developers comfortable approaching him. He was glad to be with the development team. He was as vulnerable as a child when it came to technology matters. This gave him the right to ask for anything he wanted from the candy shop.
He is a Zen sense of priority . . .
Once he had to give us the errors he found in the system. He called us and first talked about the cosmetic bugs that really didn't matter. We agreed to fix most of them; of course they were small, and who would displease a product owner over the matter of a cosmetic bug? We confirmed for him how small they were. Then he mandated fixing a few high-priority bugs. He didn't wait for us to tell him whether we could or could not. He simply said we had to. He had left the choice of fixing the cosmetic bugs to us, and no further words were spoken. Now, by the language and the tone of a product owner, the team should understand the priority of a particular bug. That's how Mr. R worked. Not by priority numbers or colors. He also made sure he gave a "why?" story behind each priority. From the outside this might look like a small difference in communication, but when you have built a Scrum team for six to eight months in this culture, it will have a huge impact on the product, in a very positive way. Everyone on the team will tend to have high-quality knowledge of the product and its users.
He is a complete finisher . . .
When Mr. R says he completed, he really completed. When Mr. R says he finished, he really finished. He is a man of few "ifs" and "buts." Once he didn't finish the testing, but we all knew what he had promised to the stakeholders. He had promised a release on Monday. So we knew he would release it and carry on the last tests on Monday. Because that's what experience with other product owners would say. That's what other product owners have done before. But he did something different. He asked for a release of a version with just the last build minus the untested story. He didn't even ask stakeholders to approve the change in the release. He simply made the decision and released it without the untested story. He informed the stakeholders that there would be an additional release on Wednesday. When a product owner does things like this, it increases his credibility with the team. Now the team knows how important it is to test their work.
His approvals are sacred to us . . .
When Mr. R approves, he means it. Approval is not something that he tested "OK." Approval for Mr. R is a buying moment of the solution. After that point, he owns the solution. Any criticism after that from the stakeholders would be taken by him personally. This gave a great baseline for the development team. The team were longing for his approvals. He respected the development team, he respected his own approvals, and he respected the stakeholder needs. This underlying commitment was the secret sauce of his success, which kept people turning to him again and again with requirements and functional changes. I have seen people from an entirely different department trying to involve him in their product, just to get his opinion. Once the teams see something good in a product owner, they want him/her everywhere.
He knows that pigs don't fly . . .
Sometimes he was not a pleasant person to have in a meeting. If he didn't like a solution, he was absolutely open and direct about it from the start. Of course there would always be the flavor of diplomacy, but still he was direct and clear in his NO. This went for both sides, the stakeholders and the development team. He had a long-term focus on everything he did, and he was ready to take on lengthy discussion for the long-term return on investment. This helped the development team build something stable and gave them a sense of respect and accomplishment. The team always knew that they were working on the hard-earned requirements. The crème de la crème of the priority stack was always in development. This made the team feel special. In this way he was never moved by a fancy GUI or a sugar-coated feature. His focus was always on the revenue. He was not a pleaser. He did not see the stakeholders as his mother. He was diligent in reprioritizing things for the stakeholders. He was not hesitant about questioning and comparing and challenging their priorities.
Current rating: 4.4 (7 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.