Saying “no” is hard – and is also what makes for good strategy. Saying no is particularly hard when we as product people are expected to build connections, lead through influence, effectively collaborate with teams that we might be saying no to (very) often, and build an amazing product that solves real user problems and achieves concrete business goals.
Product people that always say “yes” end up with monster products that do everything and nothing at the same time. They say “yes” because it is very hard to say no effectively.
If those concerns sound familiar, this talk is for you. Gabrielle will share how you can tame your monster by implementing effective and scalable product strategy. She will send you off with actionable steps so that you can immediately get to work, develop a strategic way to say no, and, most importantly, tame your monster!
1 / 52 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Awesome. Thank you so much. Great. Thank you for Hilda for the introduction. My name is Gabrielle. I'm super excited to be here with you all. And I'll be talking about Taming the Monster, The Art of Say No, while building products. Oh, my slides are not showing here.
If they could, that would be awesome. Once upon a time, there was a greenfield project. We had all the resources in the world, we had all the flexibilities, we had no users to please, and we could do whatever we wanted because there was no tech debt.
How wonderful is that world? We all dream about this place, but that's not what I'm here to tell you because this is easier. Right? Well, I personally dream about this place, but that is a side note. This in our story, the story I'm telling you today, represents Boo.
Boo is a core character in Monsters Inc. She is new, young, excited, and ready to be shaped into this amazing human being. And also very brave, if you've seen the movie. Well, Boo is pretty awesome, but most of us don't live in this greenfields land.
We live here. Here, structures are built for us. Restrictions are in place. It is hard to build new things because other things are already there. And God forbid, we have the so called users that have needs and requests and demands and problems that need solving.
Well, some of us actually live here, where a lot of these structures are kind of burning to the ground, and we as product people are very excited about solving problems and driving outcomes, but we need to be putting out fires. We need to be on support calls.
We need to be on all sorts of answers of requests and crazy things that kind of take over our lives. Well, this is very different than Boo. That reality is fair, especially the one where the city is burning to the ground, reminds me a lot of Randall.
Randall is the mean monster in Monsters Inc, and he is what happens whenever products get out of control, whenever products get too big and potentially do too many things. And you will know if you have a Randle, and I unfortunately inherited one pretty recently.
So I inherited a Monster product, I'm sure a lot of you have as well, And they are hard. Sometimes they make the companies a lot of money, and they have a lot of users. So we need to learn how to tame them. But before learning how to tame the monsters, it's important to know how they're made.
Monsters are made in a variety of different ways, but especially monster products, I found they're made when we say yes all the time, when product teams and product managers, designers, engineers are saying yes to requests every single day. And it feels great to say yes. It feels awesome.
You're like, oh my god, I'm solving a problem, or like this user needs this outcome. I'm going to do it for them. It makes you feel on top of the world in the short term. And then, in the long term, it creates tech debt, bugs, unusable features, features that people are like, this will change my life, and they never use it.
Right? Who here is familiar with these problems? I'm not alone. Come on. Yeah, it's really hard to say yes. But what's the alternative? The alternative, if you say yes all the time, this becomes you, and you stop being a product manager. You stop driving outcomes and having brainstorms and having amazing conversations and solving real issues, and you start just in time monster taming.
That is your new job. You start having to tame the monster all the time. It's sad. It's really sad. But if you can't say yes all the time, if you say no, you drive certain emotions like anger, irritation, frustration, upsetness. And these people have impressive access to you.
They can come to your desk and yell at you. They can Slack yell to you. They can email you. They can call you. They have so many ways to reach you. They can write about you on Twitter. Right? There's so many different ways.
And you don't want to enable that. You don't want to enable irritation and frustration and make people upset. No one does. And I don't want you to remember this talk by being like, oh wow, she told me to enable these things. Please don't. Right?
And on top of that, you don't want to enable that, you don't want to be the jerk. Your job comes with a few responsibilities. One of them is to lead without authority. We are product people, we work with a ton of teams, no one reports to us.
Right? It's a reality. We also need to influence decisions and be collaborators with the people we're saying no to. Adding on to that, we need to work with other teams and build relationships. And I'm sorry to tell you, this is not the entire job description.
There's quite a bit that I left out. So this is only a part of your job, and you need to say no to these people all the time. Well, what if you could just add some strategy pixie dust? Wouldn't the world be much better?
It would. But first, a few disclaimers. Because everything that provokes big change comes with disclaimers, so this talk also does. The first one is that strategy magic is hard work. There's no such thing as wave a magic wand at it, vingardium leviosa, and you're ready to go.
It doesn't just float up and do magic. The second one, there's no cookie cutter answer. So if you came to this talk hoping that I would give you all the answers and make your life that much easier, and you will have to do no work, I'm sorry to disappoint.
That's not going to happen. The next one, it should be where you spend most of your time as a PM. If you're not spending most of your time there, there's something wrong, and please try to change it because it's really, really hard. The next one, it will take commitment and dedication.
And finally, the one that I really hold close to my heart, is that it's a team sport. You shouldn't tell your team, hey, I'm going go do strategy and come back. Please involve them. Involve engineers, involve designers. God forbid, involve marketing and sales even.
Because if you're just building products and no one is selling them, it's kind of a hobby and not a job. So make sure that these people are also a part of the conversation. Now that I told you all the disclaimers, I'll introduce myself. My name is Gabriel.
I'm originally from Brazil. I absolutely love coffee, I love data, I love to travel, I love Edinburgh. It's such a beautiful city, you all are very lucky if you live here. It's pretty awesome. I'd love to connect with you, so reach out to me on Twitter and reach out to me as well for a coffee in the conference.
I told you I love coffee, I'd be happy to grab lattes or any other sort of drinks with any of you. I'm also going be sharing my slides later, so don't worry about like taking pictures and stuff. Cool. You're like, I bought in, we need strategy, don't want to take monsters anymore, I want to go back to doing product stuff, and the things that I always dreamed to do when I decided to become a product manager.
Well, let's set some things straight. The first one is that vision is not strategy. Vision is sexy. It's exciting. Right? You ask a team like, who here wants to go set the vision? People jump off their chairs, they're super excited, they already have Sharpies and like all sorts of different things to go build posters.
They love this stuff. And why wouldn't they? It's awesome. Bumble envisions a world free of misogyny, where all relationships are equal. How awesome is that? Like, I want to work for that. Pixar wants to make great movies, great films with great people. That's also really cool.
And Pivotal wants to transform the way the world builds software. These are really exciting, bold statements that we all are excited to go and run towards. And that's exactly what a vision is supposed to do. It's supposed to tell you where you want to go.
It's supposed to give you that guiding light, that guiding direction. Well, what vision does not do is tell you how to get there. And I lied to you when I put that beautiful straight arrow. It is much more complicated than that. And sometimes, it feels like you're running in a thousand circles before you actually make it.
So this is hard, and this is what strategy is all about. So how do you actually tame the monster and make sure that your new beautiful green fields project, Boo, doesn't become random? The first one is that you need to put in the work.
You don't want to be the people that are carrying the bag when there is a cart that could do the job for you. But in order for you to stop carrying the bag, you actually need to take time and put the bag in the cart.
So what I ask of you is that you're going to hear a lot of things from me, from other speakers across the conference. Take time to actually implement this stuff. Send the talks to your managers and be like, hey, I need a few days, like I need to go sort some things straight because what we're doing is not working a hundred percent.
And make sure that you build in that time for you to be able to actually affect change. Now, the recipe ish for today. Focus on the ish because there is no cookie cutter answer, therefore, is no real recipe. And all the best chefs actually cook without recipe ish.
So we're following that trend. First, we're going to talk about some prerequisites, and those are clear ghosts, OKRs, and jobs should be done. And then afterwards, we're going to move on to the secret sauce, because most beautiful dishes have great sauces. And that is the prioritization framework and the feature requests that don't suck.
Because most of them do, let's be honest. Before kind of diving in, I'll ask you to think about process as you think about product. Whenever we launch a product into the world, we don't just sit in a conference room, decide we're going to build it, do it and forget about it.
Hopefully. If you're doing that, there's a lot more work to do, and we won't cover that in the talk. But we ideally are running experiments. We're creating short feedback loops. We're checking in on the product. So why would we do that with the products that we're building and not do that with the way we are using in order to build products?
So I encourage you to take what you learned today from me and others and run experiments with your team. Also, side note, if you tell your team, hey, this is an experiment, we might not continue doing it, it's much easier to get them to buy in.
They might be like, okay, cool, if we don't like it, we have a way out. And you might just continue running the experiment indefinitely. But that's the secret, and you should tell them that in the beginning. You also want to create short feedback loops so that you can track if you're actually doing well or not.
You want to measure success and failure. Right? If you're failing, you should tweak and do something better. And you should also try to improve the process. And if you improve whatever you learn from me today, I'd love to hear from you and see new things that I can be trying as well.
Cool. So diving into prerequisites, I also put some resources on my left side, so your right side of the screen, so that you can learn from people that I learn from. So whatever I'm just doing at TLDR in, I'm gonna make sure that you have more information or a way to get more information.
Cool. First step. We have the vision, everyone's excited to run towards. If you're not excited about your company's vision, it's probably not gonna change. So, either get excited or find new things that excite you. But, let's say we're all excited about the company vision, we now need to set business goals.
Who here feels like their company has very good, clear business goals? Not a lot. Not a lot of hands. I was not. That doesn't surprise me. Because business goals are very important, but they're hard. And if anyone here is in leadership, this is your job.
Please don't ask your team. Don't tell your teams, you're empowered. Go set your goals. Because it's just as if you were running a marathon with no place to start, no place to finish, no idea how many miles people are running, and you're calling that an organized event.
It's not an organized event, it's like a mess. Right? So you want to make sure if you're in leadership, or if you have direct access to leadership, or if you have indirect access to leadership, that you're asking for this stuff, so that you can actually do your job as product teams.
So goals should be specific, make more money not specific, right? So making sure that they're clear. You should be able to measure the goals that you're setting or that are being set for you to know if you're actually achieving something or not. You should also have inspirational, while attainable goals.
So if you have inspirational goals that you are like, oh, this is impossible to reach, we are never going to do it, that can be pretty demotivating. But if they are inspirational, and you are excited about solving them, and there is a chance you reach them, that is really really powerful.
And they should also have a time frame. Goals should change and they should evolve while the company evolves. So these are the most important parts for setting goals. I won't go too much into it, but they're like smart goals, they're all sorts of things.
But if your leadership is not doing this, please ask them to, because that is gonna be a core part of your success as a product manager. The next one is setting objectives and key results. And those are the famous OKRs. So I'm going to give you my TLDR about OKRs, and I'm going to recommend that you read Radical Focus because it's an awesome book that really puts it into perspective and it's taught me a lot about what objectives and key results are.
So, objectives are inspiring, they are qualitative, and they're supposed to drive your team to want to achieve that. And key results are quantitative and measurable things that you can track in order to know if you're on track to achieving that objective or not.
So, a few disclaimers here. There are a lot of things on OKRs, so if you're not using them yet, they're a really powerful tool. I'm talking specifically about OKRs for teams. Here are things that you as a team want to achieve. Right? So if you are achieving one hundred percent of your OKRs, they are not ambitious enough.
I'm sorry. You should not aim to achieve all of them. And that's why I highly recommend that you don't tie OKRs to performance. Because if you do tie it to performance, people are going to do the safest route in order to achieve that.
And because they want to get promoted, right? Like it's normal. Everyone here wants to get promoted, I hope. So you always want to make sure that you're not tying OKRs, team OKRs to performance. After you've got your OKR set, we're going to move on to jobs should be done.
And jobs should be done are a framework to describe what needs to happen in order for your users to be happy and to have their outcome achieved. So here is the sample jobs should be done. It talks about situation, motivation and expected outcome.
I want to highlight that it talks about expected user situation, user motivation and user expected outcome. I see a lot of teams doing jobs to be done that involve improve the UI, or show this in this page. Your user doesn't care about your UI, Okay?
I'm sorry to tell you. They care about solving their problem. So if your UI solves their problem, they will love it. If it doesn't, they won't, and they won't use it. So make sure that you're always framing your jobs to be done in terms of the users that you're trying to serve.
Intercom has a great free book on jobs to be done that I highly recommend you check out. And the way I use jobs to be done is I have a macro job to be done that encompasses the broader user need, and then I have smaller jobs to be done that need to happen for the broader outcome to be true.
So this is the way I use it, there are of course other ways to use it as well. So, you have a lot of stuff here already, right? And you're like, what? We need to do more? Like, we're only done with the prerequisites?
Yes. Because this is really important and they are kind of like the building blocks for you to do this. It's almost as if you're creating a pasta dish and you made the pasta and it's delicious, but there's no sauce on it. Who wants to eat that alone? Not great.
So, on to the secret sauce, because honestly, nothing that we talked about really matters if you're not prioritizing. And prioritizing means making decisions. I really loved a good friend of mine. He told me recently that decision comes from Latin, and it's from the word decidere.
And that literally means to cut off. So when you're making decisions, you're basically deciding what not to do. Strategy is not about what you decide to do, it's about what you decide to not do. And you should be not doing a lot more than you actually decide to do.
It does not mean that you're lazy, it means that you're being smart about the way you're spending your resources, your time, and the way you're building your products. So, as product people, we make decisions every day. Right? So many decisions, sometimes I just want people that I'm with to decide what I'm going to eat, because I can't decide anymore.
I made hundreds of decisions during the day. I do surround myself with people that I trust on a culinary level, so that works well for me. Now, I'm going to present to you the non version of this. This is like the oasis, like you're running through the desert, you're like, I've been taming monsters for days and weeks, maybe years, and it's been hard, and now we have this oasis.
Well, it's not that. I'm sorry. The framework I'm giving you today is not the oasis of how to solve all of your problems. It also is not about finding the right answer. Here in the slide, you get a simplified, very overwhelming picture of all the things we're expected to think about as product people.
We're exposed to know a little bit about design thinking, lean UX, do that in an agile way, of course, and like sprinkle in some growth hacking. Because why would you not want things to grow? So for each one of these steps, there are maybe thirty, fifty, sixty different frameworks that you can use.
And yes, I'm introducing another one today. But the biggest thing about this, and the reason why people normally hate frameworks, is they go into it with the mindset that this framework will solve all of their problems. Frameworks don't solve all the problems. Frameworks are a template for conversations that need to happen between you and your team.
They are a way to facilitate understanding between your teammates, and they're also a great way for you to ensure that you are giving different ideas, different insights, different requests the same light of day. So, with that being said, we can move on to the framework.
This one involves reach, customer impact, business impact, opportunity costs, confidence, and effort. Those are a lot of variables, and I'm going to break them down for you one by one. So reach is our first one. Reach talks about how many people will be positively impacted by the outcome that you're trying to achieve, or could leverage this outcome.
Right? If you're reaching no users, it should you should wonder, should I really do this? But reach is not enough because reach doesn't tell us how impactful this actually is for the user that we're trying to help. So we then go to customer impact.
And this is how will this impact our customers. And a few things that I think about at Pivotal are speed to value. So let's say this is as simply as how fast can I get this to the user? So as a PM, if my team needs to build something and then we can get it straight to users, that's one speed.
If my team needs to do something, another team needs to do something, and then the user needs to enable that, that's a very different speed. So things that we can get out to users in a faster manner normally score higher in speed to value.
Another thing that we think about deeply is security. We're talking about people's workloads on the cloud. If they're not secure, we're in deep, deep trouble. So anything that is related to security normally gets higher priority when it comes to the things that we are trying to achieve.
After that, we need to think about business impact because customer impact is not enough. We also ideally have the business goals that leadership has already set for us. I know that there is a lot of work to do in this room in terms of that, and I trust you all to go do that and figure this out, but ideally, you will have core business goals that you're trying to achieve.
And this can be as binary as like, does this outcome tie to a business goal? Yes or no? If it does, awesome. If it doesn't, it should strike a conversation. Should we do this? Should we not do this? Why are we even considering something that is not within our core strategy?
The next one is the cost of actually not solving this problem. Right? If we decide to not build this, what happens? This is where opportunity cost comes in. And a few that we think about deeply are: if we don't build this, if we don't solve for this outcome, will we increase support costs?
Will we have to pay more support people? Will we be incurring support issues on our users? Things that we don't want to do. Also, are we at risk of losing any customers? Anyone in enterprise knows that it's really really hard if you are at risk of losing a customer that represents maybe ten percent of your revenue.
After thinking about opportunity costs, the next one is confident. How confident are you that you should actually build this, that you should go solve for this outcome? And a few things to think about here are The first one, well, did you just have this idea with your team when you were all getting coffee and you're like, wow, this will solve all of our user problems?
We've all been there and it's always happened. And that doesn't mean that it's a good idea, right? I've had thousands of ideas that I was like, this is revolutionary. This will change the way the user behaves, it's going be amazing. I put it in front of users, they hate it.
They hate it so much they're like pounding on the table. And I'm like, oh my god, how did I like, how did this even happen? So confidence means validating that the problem you're solving is actually a problem for people. Because you might think it is, and it might not be.
People might be totally fine if you don't do anything. And then validating that the solution that you're thinking about, that you brainstorm with your team, is actually the right solution. It might be a good solution for some people and terrible for others, and there might be way betters out there.
So if you have zero confidence, if you've not validated the problem or the solution, it should be an indicator of how sure you are that this is actually going to work or not. The last one is effort. And effort is one that we are pretty used to thinking about, right?
Because we think about engineering complexity all the time. And it's hard to predict, but it's doable, and we ask engineers to tell us how complex something is, either in Fibonacci or whatever other scale we're using. But we rarely think about how complex it is from a product perspective or from a design perspective.
And those should also matter because if a feature needs the PM to coordinate with twenty different teams, or if it's going to be a huge UX improvement or a huge UX transition, that is really important to consider. And we should give these things the light of day.
So make sure that you're considering effort both for product, engineering, and design. Well, what if any of those are zero? Right? If any of those are zero, my short answer is probably shouldn't do it. But the longer and more complex answer, given there's no cookie cutter here, is that you should talk about it.
You should try to understand why this number is zero and why we should actually do it or not. And you might be like, well zero effort sounds great, like how are we not just like jumping at that? Well, if it's zero effort for your team, it probably means that someone else needs to do a ton of work and that you just signed them up for that without them knowing.
So go coordinate with the teams that might be involved with your team. I know my product right now has around twenty or thirty teams that are somewhat dependent on us. So if I decide this, I'm kind of putting someone else in that fiery city that no one wants to be in.
And the biggest takeaway, your outcome for running this framework should not be a number. You shouldn't be looking for the highest number, the number that will give you all the answers and the most user value and the best user outcomes. You should be looking to have a deep conversation with your team about the things that you should do or not do.
You should be looking to understand why you're doing things or not. So the KPIs that I actually track in order to make sure that this is successful when I'm running it with my team or other teams is if people can tell stories about why we are building something or not.
If people feel more confident in what we are building, given this. And it's been pretty successful, but if we just look at numbers, we are actually missing a lot of the big picture. So the result, or your expected result for a formula, I know this is new, should not be the number.
It should be the ability that you as a team or you as a PM feel like you have to make decisions after going through this process. Now you might be like, this is all great. What about these people? They're like still there. Right?
You're like now prioritizing and you have a framework and you have a way to do it, but these people still find you and they still yell at you through all the mediums that we talked about. And they're not going away. So, how do we do to solve that?
Well, make them do your work for you. Right? A lot of the times when I was a PM, I used to love the idea, when I was like just starting a product, I used to love the idea of feature requests. I thought they were wonderful.
I was like, wow, someone is going to tell me how they can improve my product. Like, someone's going to tell me how I can do my job better. But actually, they are disorganized, they are everywhere, they have an insane range of granularity. Some of them are like, this is the problem, and this is the outcome, and this is how many people I've talked to, and these are all the customers that we would be enabling.
That's like one percent. And then other people are like, fix the UI. I'm like, what? What is even this? And then I need to go and reach out to these people and be on calls and learn more. Or a lot of people are like, oh, this is my idea for how I'm going to solve this.
And I'm like, solve what? What are we trying to solve here? Because there's no problem described anywhere. So what I learned is to not enable that behavior. So if you force people to go through feature requests that don't suck and actually help you as a product manager, it can be super, super helpful.
So the feature requests that don't suck template involves type of requests. Is this a one off feature or is this a multitude of features that's part of a bigger epic or something? Also talked about urgency. Like, is this something that we need to do right away or can this wait?
Is this blocking anything that's super important for us as a company? It also talked about customer reach and impact. We want to know how many people we'd be able to enable and how many people would be able to leverage this and how it would impact them.
It also talked about the business impact that this would have. It asked people to describe the opportunity costs and for this one, I highly encourage you to give them very specific opportunity costs that you care about. Otherwise, it kind of goes all over the place and it's hard to tie it into anything afterwards.
You ask for evidence, like how do you know that this is the problem? Do you have Slack conversations? Do you have emails? Did you do an interview? Who did you talk to? And you also ask for solution idea. And this one is kind of a sneaky one that is really helpful, because these people normally have an idea of how to improve.
And you, as a PM, would be doing yourself a disfavor if you didn't include them in the process. So I asked for their solution idea, sometimes it's great, sometimes it's not, but they feel a part of it. They feel like they're contributing. And sometimes I even invite them to our brainstorms and co creation sessions, and it's awesome because they're there, they feel invested, they will be your biggest advocates.
And who doesn't want to have marketing or sales on their side? It feels so nice when it actually happens. I made one, feel free to use it. It has a Medium post on how to do one, and it also has a sample Google Form that you can do.
It can be as simple as that. Cool. So if you notice, you can make feature requests and prioritization work together because they almost directly map. If your future requests are very different than the way you prioritize, it becomes really hard because it involves a lot of work on your end.
But if they actually map to the way you do prioritization, it can become much easier and super, super helpful. There is one thing here that we do not ask future requesters to do, and that is to describe the effort that it will take.
And that is very deliberate, because if you ask a salesperson how complex something is engineering wise, they won't know and they will make up a number. And you don't want these people to be telling you how complex it is. You want that to be owned by the team.
You want to make sure that the team owns how much effort it is. So you're actually saving yourself a ton of time by collecting a lot of evidence, maybe having to check-in, but always making sure that whatever you're asking people actually feeds into a process that you already have.
Awesome. So the summary for this, either it's your team or angry people, they should have a way to communicate to you. And you should have a consistent way where you are prioritizing things. So that you can say more no's that are actually meaningful and that people don't yell at you about, and less yes's that actually mean that you're creating a great product.
So thank you so much. Please stay in touch. I hope this helps you say no to whoever you need to.
