Product Owner Needs to Master “The Art of Saying No”

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: 

1. Start with understanding your emotions and those of others
2. Analyze your relationship with them and their relationship with your product/service
3. Adopt the process
4. Construct your message
5. 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. 

Stakeholder Mapping – The Lost element / Missing Piece of our Jigsaw puzzle

So much data is written, spoken, taught and available across the industry on Stakeholder mapping and management and the best surprise or part is, that we all are still struggling to get a handle on this concept and engage our stakeholders in the right way.

I personally believe the basic problem is the one size that fits all approach that all of us apply and think it will always work. Stakeholders come in different shape, size and formats along with their own wimps and fancy, they need to be catered to, nourished and for a lack of idea – We need to do literally baby-sitting for them, but the worst possible element is that we doing just the opposite, we are painting the town RED and look and treat all our stakeholders thru the same lens and 100% similar approaches. This strategy is bound to fail and is actually failing, and we are not learning from the same.

Once again … I shall throw some light on elements that have worked for me, will they work for you, not sure but it would worth reading and relating to your own concepts.

As much we do stakeholder mapping in the initial stages of the project, this concept is always ever-going, it is like Risk Management – to be done on a continuous basis, as stakeholders would change, move out of your engagement, new ones would be added, business dynamics could incur changed, environmental conditions will bring different levels of changes, there is no standard recipe here.

Recommend developing a stakeholder mapping document, this is a visualization document that helps clarify positions and interest of each stakeholder category and individually, it helps to identify the supporting factors of the stakeholder including power structures with in the system.

This analysis helps identify all characteristics of the interest group, their relationship among themselves and serve the purpose of effectively communicating with them.

Draw initial observations about the alliances or power structures along with conflicts between stakeholders (we all know that there is a decent amount of politics in all organizations), we do not want our projects to get stuck in this mess and have clear ideas on management of our deliverables.

Steps to develop Stakeholder Maps:

• This would involve a SPOC from the organization, who is has connections internally in the system, who knows the system inside-out.
• 1^st level brainstorming happens with the SPOC and a few select members of the scrum team
• Define and use different symbols for connections. E,g, for more complex elements use broken lines.
• When developing the map, consider the following:
  • Why this project?
  • What are the goals and objectives at Business Level, Department level and Org level?
  • Who will benefit from its success?
  • Who has an interest in the project getting successfully rolled out?
  • Who could be your potential showstoppers?
• This would lead to a draft level stakeholder map, which then needs to be validated
• This entire activity of creating the initial draft of the map would be around 60 – 180 mins which again depends on the complexity of the organization and number of stakeholders.
• Remember: it often takes time before all parties involved speak openly about themselves and their own needs and needs of their Business / department / organization.

This approach would help us obtain valuable information on how and when and what to communicate, what should be the format of communication? How often it should be done? Who all needs to be there, at times we also need to identify the personality profiles of our stakeholders, this would enable us to understand if they are detailed oriented or big picture view, as we do not communicate adequately and sufficiently (even though our information would be true and complete), we shall loose the focus of our stakeholders, if to a detailed oriented person we provide high level information and vice versa, it a just a disaster waiting to happen

The dynamics within the team, department and organization are hugely complex and critical. It is important for the Product Owner along with the Scrum team to understand these interactions, and for doing the same, stakeholder mapping as an activity is essential.

Generally, when defining stakeholders, it is important to move away from being generalist and one should be focused on being as specific as possible.

A good stakeholder map can be instrumental for your project success, Applying these principles would solutions worth its salt over a period.

Remember you need to have different approaches and strategies for dealing with the stakeholders who are interested in the outcome of your deliverables and the others who may not be on the same side of the coin as others or yourself. There is no one size that fits all approach.

A few final thoughts:

If you are involved in managing or leading a project, it is your responsibility to ensure the project is delivered successfully. It is up to you to deliver the project on time, to budget and to quality. Stakeholder mapping and stakeholder engagement is crucial to achieving these goals.

Product Owners should not under-estimate the power and value of stakeholder management and engagement, this could be a potential make/break of your assignment.