Watch the Video
Listen to the Audio
You want to be respectful and helpful, so you're inclined to say Yes. I get it. As a Product Owner though, the best thing overall is to say No when need be.
If you learn your way around the rationale, you can even learn how to say No without even using the word.
Firstly, let's explore why it's not only good to say No, but a vital and important part of being a Product Owner/Leader/Manager. There's a fruit-named little company that knows a thing or two about creating great products. At least one of their videos mentions that for every Yes they said No a thousand times.
Everything we add to a product creates work and takes up team-time. It also adds further complexity to the product construct, e.g. its code-base and user-interface. This also adds maintenance costs, and usually makes adding new features more challenging (unless top-notch technical practices are upheld).
Even if we just put the request on the backlog without real intention of delivering on it we create a suboptimal situation. Stakeholders tend to remember our acceptance of the feature request and create an expectation of delivery. We're just delaying the inevitable conversation, and believe me, it gets more uncomfortable over time, not less.
So, what to do? In order to be well prepared for feature request conversations with stakeholders you'll want to have the usual product cornerstones in place: product vision, target audience, product strategy, and product roadmap. All of these ought to be informed by user evidence.
How does the feature request relate to the four product cornerstones?
This query opens a rich conversations that allows for a fair evaluation based on evidence. The considerations coming out of the conversation then make way for a potential Yes but also for the various kinds of No.
Check out this episode for the full detail.
Listen on Spotify
- "Hello, and welcome. How often do you, as product owners, say no to new requests? What is holding you back from saying no more often? What could happen if you found different ways of saying no, and maybe you could say no without actually using the word no.
This, and more, in this particular live stream. Stay tuned. We're gonna go right into it now.
Hello, hello. Welcome, welcome, welcome.
My name is Georg.
I am speaking to you today with the greatest of empathy about this particular subject. I served as a product owner. I have actually worked myself up when I started, after I did some work as a call center agent, I became a business analyst and worked myself up to product manager in more and more products and larger, larger international skills, and then ultimately lead product manager, and finally VP of products in an organization. And over those years, I have encountered many, many situations where in some cases I managed to say no, but especially earlier in my time, I have not managed to say no. And afterwards it was always, well, most of the time at least, was quite difficult to overcome it. So I've been on the path. I've experienced what it's like.
And in this video, I would like to share with you what I've learned in an effort to support you in the practice of saying no as a product owner or product manager.
So in summary, if there's one thing that I would like to share with you is the best product owners that I'm encountering today have really practiced the skill of saying no. And in several cases, you can't actually tell whether they're saying no, but they are. So yes, a clear no is certainly useful, but with the right approach, you may not even have to use the word because ultimately it's all about trade offs. It's all about compromise. It's all about give and take.
So before we go into how to practice this particular skill, let's perhaps look at why it can be difficult to say no. And for me, and for those people I've supported on their journey as product owners, it always came down to some sort of concern or fear as to what might happen if they said no. In some cases, it can also be cultural. I come from Austria where I learned the early levels of my craft, of the craft, if you will, and in Austria, it is somewhat hierarchical. You definitely respect your seniors, and you need to be very, well, skilled, let's say, at having that type of conversation with them.
Now, I wasn't particularly great at that and that brought some positives, but it also brought some negatives, as with everything in life. So it can be simply a fear of what might happen, or it might be a perception that you need to do what people who are higher up the food chain, are telling you. And that's not necessarily the case. Over the last few years, I've worked more and more with senior leaders to help them get the most of modern product development practices. And actually several of them have professed that they would love it if people disagreed more with them because they don't know all the details that you know, right? They are not, to use a term from the pre-green energy era, they are not at the coalface as you are, right? You are right there. You are practicing the product craft, day in and day out. You are working with the team. You have exposure to your customer base, your target audience, you know everything about that. And they don't have the access to that detail. And they are in different positions. They should not deal with that level of detail.
So what you have in common is you have product strategy as a level of detail, level of information that is compatible with their level of attention and time that they have available.
So, first of all, I can dispel that perception that you simply need to follow what they say because they are more senior. If people who are more senior say something, they do so based on what they know. There are some types of leaders who want for what they say to be done. And if you, as a product professional, know that that is not in the best interest of the product, and therefore more likely not in the best interest of the overall portfolio, and therefore by extension, perhaps not in the best interest of the company, then I would encourage you to find a way to surface that conversation with them, even when they are the type of manager or the type of senior manager who more or less expects for things to be done, what they say and how they say.
We have a fiduciary responsibility in the product craft to speak about these things and not support decisions or support guidance or directives that actually undermine the success of the product.
And in a little while, we're gonna get onto how you can equip yourself for having those types of conversations. But I really wanted to encourage you and invite you to look inside yourself and figure out from an emotional point of view what is it that is holding you back from saying no more often? What is it that is coming up for you when you feel like, "Oh, actually, no, we shouldn't do this. We should do that instead. Or, no, that doesn't really fit with us." And you find yourself not saying that, but perhaps using workarounds. For example, "Yeah, great idea. Let's put it on the backlog." So that is something that I also did for a period of time, because it was easier, but ultimately it is not a good strategy.
Because when you make a concession like that and agree to putting something on the product backlog, stakeholders remember that is on the backlog, and then they will ask the question, "Okay, great. So when can I have it?" So check the previous video in this playlist, and I talked about that eternal question, when can I have it? So if you agree to put something in a backlog, you ultimately agreed to add it to your list of options. You know that it is a list of options. Stakeholders may not know that. They, perhaps, look at the product backlog more as a list of requirements of the organization to the product team, or they might look at it as a list of obligations. Whereas, you hopefully know that it is a list of options, but it is about expectations. So if you accept something onto the product backlog, you create an expectation that you will work on it in the future. So it is actually short-term optimization, if you will, to say, "Yeah, let's put it on a product backlog." Whereas mid and long term, it does not serve you because you just simply defer having that conversation about, "Well, it's not really a good fit," or "We shouldn't do it this way," or whatever the reason might be.
So it might feel like a shortcut. It's not, it's just a deferral. You're just buying yourself more time to have that conversation later.
And I'm kind of noticing that I'm avoiding referring to it as a difficult conversation. And in the beginning, these types of conversations may be difficult, but once you get practiced, they are not. And yes, it might be a difficult conversation. And in the beginning it might be an uncomfortable situation, but again, the more you practice having a conversation, the more straightforward it will become for you. And the more normal this type of conversation will be for you going forward.
So we covered from an emotional point of view, what might get in the way of responding with what is actually sort of the dutiful and purposeful response as a product owner when something comes your way that doesn't fit. And some perceptions that I hopefully was able to dissolve that some people have when it comes to receiving or being offered requests from senior stakeholders.
Now let's move on to some of the things that you will need to have in your back pocket so that you are well prepared for these types of conversations.
And this comes back to the cornerstones of good product management. You will want to have a product vision. You will want to have a product strategy, and you will want to have a product roadmap. These are all important things to have, not only for the work with the team, but also for the work with the stakeholders and with your perception of where everything is in relation to market developments and target audience. Oh, and, of course, you will also want to have a clear definition of your target audience, not to forget, right? So those are the four cornerstones of good product management. Product vision, target audience, product strategy, and product roadmap. Now let's go into each of those four in a little bit more detail, what they do for you in those conversations with stakeholders and enable you to respond with no or something quite like it.
The product vision is something that out of those four is potentially the easier one to create. And ideally you should have alignment around the product vision together with the team, as well as key stakeholders that have a vested interest into the outcome of the product endeavor and the product engagement, and, of course, developed in alignment also with the needs of the target audience, right? The target audience are those people who have benefit from the product being created. The target audience, they have the actual need in the world that your product is addressing. So product vision and target audience go very much hand in hand. And the product vision is ideally an inspiring statement that will describe how life will be better for your target audience because of their use of your product. So now let's put that into context of the conversation with those stakeholders. A stakeholder comes to you and they are requesting a feature that, who knows, might seem important to them. And it is remotely related to the product, but it's actually not a strong fit for the product vision.
So for some reason, on a transactional basis, it seems like it might fit with your product, but actually it does not really resonate with the product vision.
So in the conversation, you can retell the story of the product vision, and then bring back up to feature requests of the stakeholder and simply ask to get a playback from the stakeholder of how they see that this particular feature will help to bring about the vision of the product. And because if you don't see it, then it's likely that the target audience representative may not see it either. And then the stakeholder might also find it challenging to bring it in there. So that is one way of having that conversation using this cornerstone of product management.
The second one is that the feature requests from this stakeholder or this senior representative in the organization or wherever that request really might come from, might make sense for the product, but does not support the target audience, the core target audience, but maybe an auxiliary target audience. So yes, it would help, but it's not a great fit for the actual target audience. So if we were to take it onto the product backlog, it would automatically be lower in the packing order than anything else that we really need to get done for the target audience, okay? So that is another way where you can have that conversation with the people coming to you with requests. Number three, the product strategy. So product strategies, something that I don't actually see articulated all that often, but it is actually quite important.
So the product strategy, very brief summary, is a set of high-level goals and approaches to realize those goals, and all of those overarching goals will significantly help to bring about the vision, the world that we're describing in the product vision. And it is not restricted only to your product development work. It is holistic in terms of product strategy. So it includes all the work across the organization, bringing in the work from other teams or departments, such as marketing and legal and whatever it might be that you need, because this is everything that is required to actually help the product thrive and flourish out there in the hands of the target audience. And will take into account everything that you're learning in the market and from the competition and so on and so forth, and is informing the product roadmap.
So if you have your product strategy articulated, and then the product roadmap brings it into a chronological sequence as to what you do relate to which parts of the product strategy over time,
and that leads us to the final cornerstone, right? So the product strategy is there to have a very clear conversation, also with the stakeholders. If the stakeholders are coming to you with requests and you cannot spot how it actually fits into the product strategy, that is a great question to then playback. The product strategy, again, is one of those documents or one of those, yes, it's a document in some shape or form, but it is also created in collaboration and alignment with those key stakeholders.
So they need to know this and should have been involved in the creations. And I when I to talk to key stakeholders, those are the ones that actually have a vested interest in the outcome of the product work. Now, this product strategy then compared to a random feature request, and the stakeholders, these things aren't random. There will always be a reason. And yes, we can get curious about that. And if that does not make sense to us, we can always try to relate back to one of the cornerstones, and the product strategy is a great one because we can always check, "Okay, so which of these things does it fit with?" And if it doesn't fit with any, then we need to consider, is it worthwhile, a new strategic goal, or including it in the strategy, but if not, then no thank you. This does not help. It does not support the product strategy. It is not something that is of priority right now. And the third level is then the product roadmap.
As I said, the product roadmap is a chronological perspective of how to bring about the things that we are articulating in the product strategy. And it's another way where we can then say, "Where does it fit? Does it fit at all?" And if so, when? So if you take these four cornerstones, product vision, product strategy, target audience and product roadmap, all those things taken into account. They also are a handy guide for how to convert the word no into different types of responses, okay? So the product vision is the big why of the product, okay? So if a request comes in and it doesn't fit the why, right? If somebody else, "Well, why not?" Well, it's not actually part of this why that we're having here. There is no fit. So that could be one.
The other one is that it is not for the target audience, and that could be the response.
Another one is, and this is where it might be useful to have knowledge of the overall arching product portfolio, where you can also say, "Well, it's not a great fit for this product because of, you know, we don't see a good fit with any of the aforementioned product cornerstones, but it may be a better fit for another product, okay? And so this is where in your community of practice of product owners, it would be useful to have awareness of where the other products are at, and on a higher level, some knowledge as to what their product vision, target audience and strategy and roadmap might be. So I appreciate if it's a large organization, it will be a lot for you to bear that in mind, but I would suggest that you have at least available product vision and target audience for all of those products and those other products that you are not looking after, right?
For your own, you want to know those four really well, of course, right? So we covered the why it doesn't fit. We covered the who doesn't fit in terms of the target audience, and also to who doesn't fit in terms of us as the product team, it might fit generally for a different product. The other one is the not now, because in terms of the product roadmap, we can show actually we are working on a very important key goal right now that is on the product roadmap. So it doesn't fit there. And the next product milestone is there to realize this chunk of value for the user doesn't fit the reader, and so on and so forth, okay? So there are more ways of slicing and dicing the noes.
So shout out to Laura Powers. I got to attend her, what was it? Seven ways, seven types of no, and turning them into a yeses. Something was the workshop title. It was a great workshop. And it actually included practice, as I said, is also important, so it included the workshop in the practice. A little bit of what I shared today, I also found in there. So Laura Powers has a workshop on there too, but yeah, you don't actually have to say no necessarily, but you want to have eloquent responses that you can back up, right? One thing to bear in mind also is that wherever you have some sort of evidence through user testing, testing with your target audience, then that is a wonderful thing to do, right? Everything that you're coming up with as yourself or with the team, are assumptions. I continually covered that particular point. So whatever you do, with your key assumptions, you always want to test, and you have evidence based on user feedback and market feedback that you can rely on.
So your four cornerstones should all be backed up by evidence.
And that is all feedback from the target audience and feedback from the wider market. And if it is backed up by evidence, then it's also much easier to have that conversation, say, well, if an idea was there that you already had, and you tested it with users, superb, then you can say, "Yeah, that's a great idea. We thought it would be fantastic to do for users. We tested it with them and actually turned out nobody wanted it." Or, "We would have to do so much extra work, and it's not actually worth the value that this particular feature would return," okay?
So four product cornerstones. Turning the noes into meaningful responses that also help to educate the stakeholders that are coming with the feature requests and ensuring that the four cornerstones and your ability to respond to those requests is supported by evidence. So that is really what I want to include in this particular session. And if you are already particularly skilled at saying no in whichever form you are, it is absolutely fantastic. And I congratulate you on having come that far.
If you could share some of your key techniques that have worked very well for you in the comments down below, that would be much appreciated. And in fact, if you have a story to tell about, or a no where you felt particularly uncomfortable, but it had a huge benefit, I'd actually love to invite you into a conversation on "Team Genius Live" in the future. I am moving into having guests on the show in the future. I invited Kareem Hubbard. He's working on a great book about enterprise, business agility and what leadership is required in enabling that type of transformation, and he kindly agreed. I invited Ben Maynard who's got super-deep experience in a large scale scrum adoptions in a huge, huge organizations. I invited him to come along to talk about enabling teams and product development at scale. And he kind of accepted too. More invitations will go out soon. But if you've got a wonderful story to tell about teams, I'd love to have you here also for a conversation.
So with that, I'd like to close the video for today, and thank you very much for tuning in. I truly hope that some of this was inspirational for you to infuse your practice of saying no in your product development practice. And if you found this useful, please kind of let me know by giving it a like. More of these videos are coming. If you haven't done so yet, consider subscribing. This way, you'll always get the latest videos. And if you want to get notified when something comes up, just hit the bell button.
So thanks again for tuning in. My name is Georg.
See you again in the next "Team Genius Live."
Thanks and goodbye."
==end of transcript==