Review with the line manager was about to start. Kate was waiting for “End of Year” appraisal meeting and she was quite confident that last 12 months as Agile Product Owner in new company were really successful. She felt deeply connected with delivery team and she considered that all 3 of her products provided significant business value. “A promotion would be spot on. On the other hand, decent pay raise would be good enough too“, she said in her thoughts.
She wasn’t ready for what was about to come.
Jack, from the moment he entered the room, looked quite nervous. “Kate, looking at your results of last year, I’m not sure if we can continue our cooperation“, he explained his attitude really quickly.
The meeting was long and tough but, in the end, Kate was able to prolong her contract for trial period when she conducted detailed retrospective of her ways of working. As a result, she came up with a list of 5 things that nearly cost her job.
I call this list:
5 deadly sins of Agile Product Owner
1. Being focused on wrong things
I have seen two kinds of Agile Product Owners. People from the first group usually have to switch their context between activities including but not limited to presales / sales, marketing and backlog management. On the other hand, second group of Product Owners considered only that last task as their sole responsibility. However, both parties are utterly wrong. Kate was one of them.
Agile Product Owners have only one, key responsibility – to ensure long term success of the product. They need to think strategically and all: plan how to make their users’ problems disappear, guide the team to provide optimal business value in product increments and inspect that all desired results are being achieved. I agree that other, mentioned actions can be temporarily beneficial, but you have to always remember about what is your true responsibility. If any of supplementary activities threat your availability for the core assignment, you need to politely decline. I’m deadly serious now. You have to remember that the success of your product rests on your shoulders.
Please also keep in mind, that Kate was probably overambitious with managing 3 products in parallel, as the optimal ratio is 1 Product Owner for 1 Product – you don’t want to spread yourself to thin.
2. Knowing better than the market
“I’m sure that all users will definitely love new features that we are building for our product” Kate used to say without hesitation. She was often too confident about that but she hasn’t realized that until just recently.
Under this phrase, I put together all cases when you have decided to release a feature without proper due diligence. You have identified potential market / user problem and you rushed to deliver any solution ASAP. I have seen people who didn’t even bother to ask the market about its pain points and just trusted in their “gut feeling”. In such cases, released features are either rarely used or too difficult to use at all. Moreover, they frequently try to address wrong customer problems or not address them at all. So, your product has yet another fancy but unnecessary feature, you have no extra business value from it and you have probably spent hundreds thousands dollars to learn that. And you could have just asked…
Remember – you may even know your market really good, but you are not your market. At least in most cases.
3. Being Feature oriented
Kate had her eureka moment realizing that she needs to conduct better market research before launching new features. But one thing still bothered her. “Despite my previous thoughts, I have spent so many hours speaking with customers and users. Was that in vain too?”. It appeared that for most of that time, yes.
Whenever you conduct an interview with users, they will often provide you ideas for amazing features that they want. This is a pitfall that many fall into. Both, a customer and an Agile Product Owner like to think about specific details of the solution and can quickly drift away from the actual problem to be resolved. This can lead to creating a solution so far from the original problem that did not address the problem at all – I have seen dozens of examples when business representative or IT developers proposed new ‘life changing feature’ that in the end appeared to be a total misunderstanding.
Our responsibility as product experts is to always challenge your business & IT peers to understand why they ask for such new functionalities and discover the problem that they want to resolve. In great number of cases, you can address those problems quicker, cheaper and more efficiently than the original feature idea would do. Remember to be assertive and don’t accept any new backlog items unless you know exactly what problem they are to resolve. Do that regardless of the source of the idea – even if it came from yourself!
4. Not validating product hypotheses
Kate has spotted a pattern – two previous points were connected to each other. “OK, I understand that I could better research problems of my customers. Although, I have released several new features last year. Do I really know which of them properly addressed customer needs? Or which of them did provide the best value? I doubt … How could I build a road map not knowing that?”, said Kate and picked up a pen to write down another point.
Every feature represents a problem to be addressed. Each of them should provide business value. Agile Product Owner should write down predicted business value for all planned features in form of benefit hypothesis. Such statement specifies potential benefit that the organization or users should gain when the feature will be live (it also acts as lighthouse for delivery team so that they know what is the purpose of the feature, but that is a story for another day). When you place new product or feature to the market, you, as Agile Product Owner, should validate if expected benefit has been achieved. This is a source of crucial information that you should use to answer following questions:
- is the feature valid? does it address actual needs? was your research of this particular problem correct?
- how much business value does the feature provide? what is your market’s attitude about the feature?
- is the value provided greater than the cost of development of that feature? should we create more of such features?
- is the value provided greater than the cost of maintenance of that feature? should we keep this feature alive?
To conclude, you need to always remember that deployment and release of a feature is not the final step of feature’s life cycle. The important part starts afterwards.
5. Vanity metrics vs actionable metrics vs ultimate metric
“OK, I admit that I could have spent more time on validating the success on a feature basis but at least I’ve invested a lot in measuring the overall outcome of the product. We have tons of metrics that… I have never actually used. “ said Kate sadly. Plenty of those metrics, even if used, would not provide her any value anyway as she had tracked wrong attributes. “How should I measure quality of my product then?”…
I’m a great fan of validated learning approach described in Eric Rise’s: “The Lean Start up”. In his book, Eric made a very clear point that all metrics that you track should be “actionable”. That means that you should be able to make business decision using metrics you have built in your product. Things like number of visitors on your page, clicks on specific buttons don’t bring enough information. However, if you make them part of bigger context like revenue per customer throughout A/B tests, you know that your new features will be beneficial for your product and it is worth to release them / keep them alive.
It may sound controversial, but I think that we should consider something more that just simple, actionable metrics. If Agile Product Owner knows how her product evolves with addition of new feature, that is good for her. Although, the ultimate metric is one step further – it is to understand how your product impacts the world. This task is hard but if you can get to the point where you measure what benefit (revenue, savings, joy etc.) your product brought to your customers, your success is almost guaranteed.
Epilogue
Kate had her lessons learnt and her next year was much better. Her products grew a lot and she earned her dream promotion. Would you like to achieve great success too? I can help you with that.