One skill that a Product Owner should master is “The Art of saying No.” One does not have to please everyone and make a mess of the product and the value it provides to your customer.
Saying ‘No’ is an art, and it is not easy when you have management, stakeholders, sponsors, end users, and your Agile team as part of the game. You must engage them for all the right things to be done in the right way and the wrong things to be done in the right manner.
It is important to note that the primary responsibility of the Product Owner is to maximize the value, and to do this effectively, he needs to be empowered.
The Product Owner should be like the CEO of an organization. Consider the product to be an organization and the PO to be its CEO. Remember, a successful product solves/resolves the customer’s pain areas or challenges, enabling the smooth functioning of the business. A good product evolves over a period of time, and features and functionality are not built in from Day 1.
Visualize the current version of iPhone and its earlier versions like iPhone 5 or 6. It has evolved immensely. We cannot think of all the features and functions on Day 1; we learn and grow as we observe, use and get regular feedback.
You need to evaluate competitors’ products and evolving technology, think five years ahead of the current times to identify the needs of the future, and start to put them in our blueprint. You ought to lead the pack, not copy and follow others. Instead of focusing on Best Practice you should work on Next Practice, which would be the new best practice for the world.
There is a famous quote that states, “We should learn to say the slow Yes and quick No.”
To be a good CEO, one should know the needs and requirements of stakeholders and how to handle them. Do we treat all stakeholders equally and have a common communication strategy across the board? Do we consider the information required by our stakeholders, investors, and management when developing a communication plan?
Designing the communication strategy would help you to more effectively say “No” when you understand the ‘Why’ and ‘What’ of your communication game plan. Product Owner should not be thinking about consensus every time. It may not always be a good practice and may hurt the product in the long run.
Saying ‘No’ is an art. You need to know how to phrase a sentence and what would form the most appropriate way to start the sentence when intending to say No. One could respond by:
- That is an interesting idea, however
- I hear what you are saying and
- I understand that this is important to you, however
- If I would say Yes to this, then
Define and identify your approach depending on the stakeholder and current situation. You do not need a cookie-cutter strategy. Learn to understand the psychology of your requestors, and the impact that your response would have on them. Also, understand the product, the requestor’s behavior towards you, your team, funding, and support (it is all politics at the end of the day).
Remember, Product Owner’s thought process is not to say “No” to everything. The goal is to say No to good ideas so that you can say Yes to great ideas.
Different ways of saying “No”
Crystal Clear –This method of saying no is suitable when you have a strong relationship in place and there is enough trust between the stakeholders and the product owner.
Timing Based – This approach would be critically deployed when you are facing issues with deadlines and milestones, as per the statutory & regulatory needs. The ideas which are nice to have and do not meet the timeline criteria should be kept on the back burner.
Impact Management – Evaluate the impact of saying Yes vs. No. One person’s gain would be another’s pain. Before arriving at any decision, analyze the impact of your decision on the stakeholder, considering the product vision, market impact, competition, and so on. Compare the present request with other requests from different stakeholders and perform a CoD (Cost of Delay Concept) for comparison.
If-all-else-fail – Use this approach when all the other techniques have not yielded results or failed for you. This should be your last resort. Use this approach for stakeholders who fall under the category of High Influence and Low Impact. When using this approach, ensure that you have the backing of your key and important stakeholders.
Levels of Communication
When communicating with anybody, it is crucial to consider the following:
- Start with understanding your emotions and those of others
- Analyze your relationship with them and their relationship with your product/service
- Adopt the process
- Construct your message
- Communicate
Speaking about emotions, consider whether you are calm, relaxed, anxious, or upset. This process can make or break your approach. If you are comfortable with your emotions, move forward and answer a few questions.
- Have you spent time building your relationship?
- Has the stakeholder developed a close affinity with you and your product?
- Will they promote your product in all situations?
When speaking about the process:
- Think about how you are constructing your thoughts, phrasing, and developing your sentences,
- What tonality you are adopting?
- What is your body language?
- And how controlled are your facial reactions? Have you used a common vocabulary?
When communicating, have you seen your environment and the people around the place of discussion? How do you start your conversation? Where and how do you pause? Do you provide adequate time for the message to be accepted? Is there any scope for further discussion?
Do remember, this article is not about saying No, but it is about developing approaches to have great value in your product. It’s a guide to prevent the unnecessary stress of developing something that would not add / create value to the outcome and no true ROI would be achieved.
The thought process here is all about understanding how to manage the various types of stakeholders that you would encounter in your product development journey. How do you ensure that all features and functionalities just do not land up in your product? While you should not undermine the importance of any feature or functionality, it is important to identify the source of the highest ROI. Analyze what creates excitement in your product, what features can move to the next release, and so on.
Efficient Product Owners should continuously try to evaluate the direction of the product, how things are shaping up, and what they must do next in the journey. Equally important is that as a Product Owner, you do your retrospective and find approaches to doing things better.
As a Product Owner, if you cannot protect your product and maximize its value, rethink your approaches and strategies and understand whether you are doing justice to the role of the Product Owner or acting as a glorified scribe (Only writing user stories) for the product backlog.
The choice is always yours.
agilescrumworld 