 Welcome to Agile Roots 2010, sponsored by Version 1, Rally Software, Vario, Amirsis, Agile Alliance, and Xmission Internet. The Product Owner's Guide to Saying No by Alex Pukinski. So, I was actually here last year and I gave another talk on product councils. Was anybody here for that last year at this conference? Okay, cool. Well, at any rate, last year I was talking a bit about stakeholders and sort of the process whereby stakeholders on an Agile project or an Agile company get addicted to the constant availability of change. I talked about sort of getting drunk on Agile and what that means for stakeholders. I also talked about how to form a product council and sort of how to get your stakeholders together in a group to, you know, on a regular basis in one room. Talking about what their needs are and how to put together a Kanban to, you know, help raise visibility of the things you're working on and the things you're exploring and how this would ultimately make your stakeholders happy. But this year I'm actually here to talk about something somewhat different because I've actually decided that stakeholder happiness is really the wrong goal and that in many cases you actually, it's okay for some of your stakeholders to be very upset about what you're doing and this talk is about a little bit of that. I actually was talking to my brother a few days ago and he reminded me of a somewhat famous email from the year 2000. I don't know if any of you have seen this. This is Linus Torvalds is talking about somebody who wanted to put a, build a kernel debugger and he was basically saying, no, I don't want to, you know, my biggest job as a person responsible for Linux is to say no to all kinds of things people are asking for. So, you know, it's kind of a phenomenon that seems to happen to people who are in positions who have to be deciding what to work on for products. So we're going to talk today about how great products come from saying no. This is actually the majority of what I do in my job as a product owner day to day. And as part of that, there's sort of four different parts of this talk. There's actually about 60 slides and if I continue the rate I'm moving, we'll finish with plenty of time left over for questions. So the first part, I'm going to talk a bit about where does quality come from on an agile product. I'm going to talk about why saying no is a really important thing to learn to do. I'm going to turn, talk a little bit about how to know what to say no to, which is kind of a mouthful, and I'll also talk about how to actually go about saying no in a way that doesn't get you in lots of trouble. As a result of this, I'm hoping that some of you, how many people here are product owners or in a product management type role? So I'm hoping that some of you start looking at what I'm going to call painful prioritization. We'll come back to why the dragon's significant later. And you're going to end up with a product that's better and hopefully making you more money in the long run. So that's my goal in the next 30 to 35 minutes. So who owns quality on my agile team? Does anybody want to try to answer this question for me? What's that? Everyone. Any other answers? What's that? He says that would fail an ISO audit. No other, nobody else. It's kind of a loaded question. So yeah, it's interesting. I was talking to my, we have an internal agile coach, Jennifer, on our team, and she said, yeah, it's everyone. It's the team owns quality. So, so here's a picture of some of my team, which doesn't project very well. It's actually in the front. You can see there are a couple of developers in the front. There's a tester in the back. There's the user experience designer talking to a product owner. There's a whole mixture of all different roles. And when, when you say the team owns quality, that means all these different people are responsible for quality on the agile project. And so one of the tools that agile teams often come up with to help with quality is a definition of done. How many people have a definition of done for your team in some form? So, okay, so for maybe some other people will benefit from this. So this is a sample definition of done. This is what our coaches use for coaching people. I don't know if it's actually real or they made it up, but it's similar to what we have. You know, the idea is that for a story to be considered done, all these things need to happen. We need working software that's demo-able. We need unit tests, code review. For this team, they want to do an installer. They want to have functional testing done. They want to have some functional review by the product owner, load testing, regression tests, documentation and review by the PM, user docs, design docs, samples for critical features, release notes and API documentation. So if you do all this stuff, then you're done. So, and what this, this kind of definition of done is really important to have and definitely a very valuable thing. And this is kind of what, you know, the story done part of it. There's a couple other parts of done I want to talk about. One part is the concept of technical done. Here you can see a couple more developers just chatting with each other. But the interesting thing is as a product owner, even though I was technical in the past, I don't have a lot of visibility into sort of the actual technical quality of the system. You know, I could go looking at the code and digging around it, but I try not to do that. Because ultimately the developers bear a lot of, bear the responsibility for maintaining technical quality of the system. So, when we build features, I'm kind of trusting the team to make good decisions about what level of cleanup and what level of refactoring, what level of testing is right behind the scenes. And it's interesting, I often use the example of a kitchen. If you kind of imagine a kitchen where, you know, you cook dinner one night and you decide, you know what, I'm too tired, I'm not going to clean up. Does anybody ever do that in here? Okay, one or two people admit to having left their kitchen unclean. And if you go down the next morning and you're trying to get breakfast together and you want coffee and a bowl of cereal, and the kitchen's a mess, it's pretty easy to, I don't know why this thing keeps going off, hopefully it'll come back in time for my slide change. If you're, sorry, if your kitchen's a mess, you can still get your cereal together and make coffee the next morning. You can actually also cook dinner again the next night. I mean, I know this, I've tried it. If your kitchen is dirty, you can still produce a second substantial meal, but it's going to take you a little bit longer. And if you wait around for the third night without cleaning up for the first two meals, the meal's going to take a little bit longer. And by Friday night, you can barely produce a meal. You're going to, actually, for me, I'd probably be eating out by Thursday. But the point is, there's a mess in the kitchen, it's slowing you down. And the thing is, it's very, very visible. Now, for me as a product owner, I look at the product, and if there's a technical best behind the scenes, I don't see that mess. It's something the developers see. And it's almost as if the mess were invisible in the kitchen. I walk in the kitchen sparkling, and for some reason it takes 16 hours to bruise a peanut butter sandwich. And that's the kind of scenario we're trying to avoid. So I really have to trust the development team to make good decisions about cleaning up after themselves, because I can't see that sort of technical mess. And in a way, the same is true for features. The level of feature dunyus for an executive is obscured. An executive knows, you might know that you shift a feature, but the detailed level of quality of the feature, did you really round out all the corners you should have? Did you satisfy all the groups you should have? That's the same level of security that the technical mess is for developers. So as a PO, it's very important for me to own quality to some extent too. And that's kind of a little bit of the genesis of this talk, is the realization that as a PO, if I'm not paying attention to, are features finished to the right extent? Are they done really to the right degree? It's very easy to end up with a crappy product. So I want to talk a little bit about the whole idea of making everybody happy and why that leads to crappy products. One of the things that's interesting in MySpace, I worked on a software development tool, and there's really an infinite number of good ideas for improvements to the software tool. It's not really infinite, but I have a database of 4,500 feature requests. So there's no shortage of good ideas. Probably five of them are no good, but several thousand of them are really good ideas. And within that space of good ideas, there's a somewhat smaller infinity of great ideas. So really, like I have 30 or 40 big things that I could be building right now that would be awesome, that would really make a bunch of customers extremely happy, that would reduce pain, and that would be a great thing to do. And the challenge is that constantly there are people coming in asking for you to build more features as a product owner, and it feels really good to be able to say yes. If somebody comes to you and says, you know what, I'd really like you to improve your search functionality, which happens to be what I'm working on right now, and you can say yes, you know what, we're going to do that for you. It'll be out in two months. That's a really good feeling and really gratifying. It's very easy to get sort of attached to that feeling. The challenge is that if you say yes to too many things at once, you kind of get in a situation where you have lots of partially completed work. And so saying no is very important to avoid this situation of having too many things going on at once and ending up with a half-finished product. So I want to talk a little bit about how to know what you should say no to. There's one easy rule that I got that I stole, actually, which is just say no to everything. This is what 37 Signals does. They say, you know what, thanks for your feedback. And we probably won't do anything with it. So generally, this is a fairly simple approach. You don't even keep a list of what to work on. But it's interesting. If you're saying no to all your requests, you kind of have this challenge of, well, what do you actually work on? And I kind of want to try to help you sort of think about different ways of sorting through the morass of potential ideas. Jeff Patten alluded to earlier. If we just knew which were the features that people would never use, it'd be easy not to build them. But I think there are some techniques that can help with this. The first one is Moscow prioritization. How many people know what that means? This is sort of the basic Agile 101 kind of approach. It works well for features or projects within a product and also kind of initial product planning. And the idea with Moscow is that if you have a list of things you could work on, you sort them into piles. You know, must have, should have, could have, won't have. When I was coaching, I used to say the must have things are the things that you absolutely can't go out. If you don't have these features, there's absolutely no point to your product whatsoever, and nobody would even look at it. These are the things that are more things. The should have things are the things where if you don't have them, it's pretty embarrassing or really awkward to use the product or just difficult to, you know, for a major segment of your user base. And the, you know, the could have are the things that you, you know, you'd like to get to but realistically don't think you're going to get to and, you know, generally people just skip those. And the won't have are the things that you have already decided are out of scope. The interesting thing is you can ship a product with just the must have and in a lot of cases this is a very, very helpful thing to do because you can get something out in the market and you can get value before there's actually a completed system in place and, you know, it's kind of, it doesn't project very well but in Star Wars we learned that the Death Star functions quite nicely even though it's not complete. But you can get value before you're done and in a lot of cases it's worthwhile to get something out in the market early before you've done the should have. But what that, the challenge is there's a lot of danger in skipping the should have and it's always tempting to skip the should have. It's always tempting to see, you know, if you're comparing a should have or a could have of one feature that's mostly done out in the market and making you money versus the must haves of a new feature that you haven't started yet and you've got lots of people actively complaining about, it's very easy to make the leap towards the framing nails. Let's move on and start building the new structure of the last piece of the trim. Because in fact people can live in houses without trim. Has anybody been in situations where they lived in an unfinished construction project? Nobody's renovated their house? Okay, a couple people. So you can live in a house that's not finished. The challenge is that it's very hard to get it finished once you're living in it and once you've moved on to the next thing. So it's, because of that temptation, you know, you really need to think carefully about, you know, is it really, am I really done enough to move on or was I just done enough to ship? Because they're two very different things. So I want to talk a little bit more about saying no because there are some things that are very easy to say no to. There's sort of a continuum of easiness. The easiest things are the ones that are kind of out there where there's no demand and, you know, occasionally we get a request to integrate with some product that is very rarely used. And so it's fairly easy to say no. It's like, well, you're the only customer who's ever asked for that. We, you know, we appreciate your feedback. We'll pay some attention to whether other people ask for it, but, you know, we're probably not going to do an integration with that product in the short term. So these are the easiest ones to say no to. The next batch that are a little tricky are sort of the popular non-aligned features. This is kind of some dependency graph from something. This is kind of my pet non-aligned feature. We constantly get requests within my company to build tools for task dependency management. We're building an agile tool, so we don't really want to do that and get what you're supposed to do. And we've got story dependencies and we think that should be good enough. It's a popular feature, though, because as people transition from waterfall development to agile, they're interested in dependencies. And so, but it's not aligned. So it's relatively easy for us to say, you know what, we've had some requests for that. It's not really aligned with where we want to go. So, you know, we're probably, you know, we'll bear that in mind, but we're probably not going to do anything about it. So that's, these are not so hard to say no to. But what I mean is, for me, are the personal pet features because, personally, there's a bunch of things that I really want in the product that I think would make it better. I really want to bulk to lead backlog items. You know, it just drives me crazy that I have to click through each one of them. And so I get requests for that. It's something that I'd like to build, but it's not on the roadmap. It's not aligned with what we're focused on right now. So it's an absolutely great idea. It'd be very useful and it's something I care about. So it's really tough for me personally to do that. The real challenge, though, is when you come to the things that are really, really well aligned, but they're not in sort of your top three. They're not at the top of the list. So, you know, they're a great, incredible opportunity. They make you tons of money, but they're not the things you've already decided to focus on. And those are the hardest ones to say no to because there's always this question of, isn't this a great opportunity? Couldn't we make a ton of money with this feature? And the answer is often, you know, maybe we should work on it, but there's a lot of risk for constant shifting of focus. So the question to ask yourself is, is this really not just a great incredible thing to work on, but is it the best possible thing to work on right now? And if it's not the best possible thing to work on right now, is it in the top three such that we should be considering over the next few months? Ultimately, that's one of the difficult judgments to make in a lot of cases. And having alignment with revision is an important part of it. Part of it, too, is looking at, you know, ultimately the economics of the situation. You know, there are features that would be wonderful, that'd be very helpful, but that doesn't materially change the customer situation, but there's still a lot of demand for them and they're very popular. So ultimately, the challenge is finding the features that people are willing to pay you money for and that they're willing to pay you more money for than other features that you're looking at. So it's a really painful process. And I'll talk about a couple of areas that I kind of had to make some difficult trade-offs. I had this photo in this picture at the beginning. Does anybody recognize this dragon? It's kind of a long shot, but I figure with a bunch of a relatively geeky audience there might be someone. So this is actually from the C.S. Lewis's The Voyage of the Dawn Treaders. Anybody read this book when they were younger? Okay, a few people. So the interesting thing about this book is this is the one that starts out there. Once was a boy called Eustace Clarence Scrub, and he almost deserved it. And goes off on a sea voyage with some of his cousins. And ultimately, partway through the story, he ends up sort of getting straying from the pack and wanders off and gets turned into a dragon. I don't remember exactly how that worked, and he's miserable as a dragon. But what's interesting, what's stuck in my head is that there's this point in which there's a lion sort of tearing off his scales to sort of turn him back from a dragon to a boy. And he talks about how painful it was, that sort of deep tearing feeling. And in a lot of ways, this is kind of that deep tearing. It's the sort of thing that you sometimes get when you're making these painful prioritizations. And I want to talk about one example. We have a product at my company that we built a number of years ago, and we built the first increment of it. And it actually did fairly well in the market. I think it made, I don't know, a million and a half dollars in the first year, which was pretty good. And after that, we conducted a number of usability studies and interviews with different customers who were using it. Got some clear feedback about what improvements we had to make to make it better for them. And we had a pretty clear list of, you know, a short backlog of things that need to be done to make it better. And ultimately, we still do have this list, and we've made the strategic prioritization not to work on this because it's not the most important thing for the business. The challenge is that it's the investment that we need to make, and it's relatively small. It's a couple hundred thousand dollars. We think it returned two million dollars in revenue within the first year, so it's a 10x ROI. It's a pretty compelling return on investment. And ultimately, it's something that we have nonetheless decided not to do, and it's very painful. You know, I'm actually going to go talk to a customer tomorrow who's really disappointed that we haven't built these set of features. But ultimately, the challenge is sort of having the fortitude to say no even when there are really strong, compelling reasons to do something, just because you can't do many things at once with a finite capacity team. So with that, I want to talk a little bit about how to say no because how you say it is pretty important in how you get away with it. And after a couple years of doing this, I have a few things that we're doing. So I'm going to give you five basic tips for how to say no more effectively. The first part has to do with listening. One of the interesting things about saying no is that if you listen well to your customers and they're convinced that you understand what they're asking for, and you listen to your stakeholders and they really feel like you get what they're asking for, when you come back and say no to them for the thing they're asking for, they'll accept it. If you don't listen to your customers, because you've heard it a hundred times, if a customer comes and says, I want to give you feedback about X, and you say, yeah, we're not working on X, the customer is going to say, gosh, he must not understand how painful this is for me to not have X. So the listening is one of the major purposes of it is really convincing the customers that in fact you do understand their needs and that you're making this decision with that understanding in mind. The other part of it too is that there is a chance that you'll hear something very, very different than what you expected. But the flip side of this is that you really want to make sure that you don't listen too much because listening too much to the same thing over and over again is ultimately a waste of time. So ultimately, for that product in particular, I have a fairly standard answer for how I deliver the issues with it, and that saves the time of repeatedly listening to the same things over and over again on this. I think the major challenge is that by listening, you set expectations when you listen to a customer and you say, yes, I hear what you're asking for. You want this complicated task dependency management system. I've had a half a dozen other customers ask for that. I understand your legitimate needs. If you say that, it's very easy for the customer to walk away saying, oh, they understand it. They might build this soon. And then you have a customer sort of waiting at this fairly faded bus stop, waiting sort of expecting this feature to come out that never really arrives. So it's very important to be careful with the expectations you're setting when you're listening. It's this sort of delicate balancing act. I think one of the other things that we've encountered a lot of, especially as we've grown to be a bigger company, is that some of you may understand this if you have kids, the two-parent problem. Can I have a cookie when daddy just said no? Mommy might say yes. There's this challenge in a software company of making sure different people are speaking with a consistent voice about what we are and what we aren't doing. And ultimately, having some kind of product council process where people understand what is the focus is very important. And I think one of the things that we've found is quite helpful also is sort of, I call it the redirect. But ultimately, the interesting thing is that when you're building software and you're doing this difficult prioritization, you're ultimately making a choice to work on something and you're hopefully making that choice for a good reason. The fact is you're working on some features that are great that are going to be really valuable and that your customer calling about feature A might be very excited about feature B that you're building and might not have thought of that and might not have realized how much that matters to them. So one of the things we'll often do is say, we've spent, you know, we've heard what you're asking for and let's talk about what we're doing going forward. So one of the common sort of dynamics I do with collecting feedback is this concept of asking the customer to email a list of requests and then getting on a call with them, highlight the top two or three, the things that you really care the most about. And then after I've heard about those things and read your request, then we can talk about what's relevant for the next couple of months. What are the features that we're building that we'd love to get your feedback on and that kind of thing. So ultimately that giving people sort of an opportunity to engage in a different way about the things they are getting that are valuable to them that they didn't know are valuable is pretty important. So any questions at this point before I go on? I think I've actually spoken fairly quickly which is good because it's the end of the day. So one thing I do want to point out too with this, with the concept of the redirect is you're not saying to your customer you're never going to get this feature and in fact, you know, eight years later kernel debugging was added to Linux. So it's not that you're never going to get the feature. It's just that it's not the thing we're working on right now. And that's a much better message than absolutely no, you're not going to get it. So with that I think, you know, again, I feel like great products come from saying no and I think that sort of that focus on really painful prioritization making some sort of tough decisions that involve not doing something that is intensely valuable can make a big difference. So one of the things I'd like you to all do for just a few minutes is talk with the person you're sitting next to about are there two or three things that your team is working on right now that are the things that would be really painful to stop doing but you kind of know you shouldn't be working on them. Let's just take a couple of minutes to do this and see if you can come up with anything. Yeah, so if most teams are working on many things at once and are there a couple of things that are intensely valuable that nonetheless are not the most important things that you should really consider stopping. Let's think about two or three minutes chat and then we'll hear how people do. Any groups have something they want to share around is there a group that has something that they really ought to stop doing despite its intense value? I don't know. Okay, did any groups conclude anything interesting in their short conversation except for... Sure. So what I'm hearing is that you have kind of urgent customer issues around one or two big customers that seem like they need to be handled at least the business is treating them that way. And I think the challenge is that there are some numbers there's some amount of time that we spend on that kind of thing and the challenge is if you're doing six other things if you're building or too many other things at the same time it could be that's not the thing that you need to stop doing so much as some of the other strategic projects. That's been a challenge for me is understanding what's the right level of slack to leave in the roadmap for big issues that come up along the way. And in some cases a lot more than you expect. Well, yeah, it is difficult to turn them down and you see them face to face and saying no to somebody's face is a lot harder than saying it in an email. Yeah, and they're in the same building and who knows what they're going to say about you behind your back. I think that does make it even more challenging. I mean, it's interesting internally our business is at the scale where the value of... because we ship software the value of shipping features is so much greater than any internal tools we could build that we very rarely invest in internal tools. And it's painful because I know there's a provisioning people who have to spend 10 hours a week doing silly workarounds because I'm not focused on their issues. But it is tough. I think the hard thing about being a product manager in a lot of ways is not... you can't be a nice guy. And if you want to be one that's kind of... it's a very difficult job. What other observations do people have? Okay, well, so hopefully, you know, if you're able to do a little bit more of this sort of painful prioritization and turning down more work, your product will ultimately thank you. Great, well, thanks for coming. I finished a little bit early. Hopefully you guys have there.