Wouldn’t it be great if no one could argue with your decisions? How awesome would it be if you could cut through politics, opinions, and circular arguments and have a clear way to prioritize? In this talk Product guru Bruce McCarthy arms you with his battle-tested approach to prioritizing your most critical initiatives that will increase your organization’s focus by increasing confidence in your prioritization decisions.
Learn the method that Bruce used to focus his team on the few critical things that resulted in the sale of his company for $125 million. He’ll cover:
- Why prioritization is important
- What’s broken about prioritization
- Benefits of clear prioritization
- Methods of prioritization
- Scorecard deep-dive
- Success stories
Learn how great companies are run
At BoS we run events and publish content that is highly valued by anyone trying to build, run, and scale a great software company.
Sign up for a regular dose of actionable and useful content:
Bruce McCarthy: It’s good to be here. I promise not to go on too long before you get to lunch. I will say I think I might have you all beat in terms of how far you came to get here. I came from New Zealand. I live here in Boston but I came from two and a half weeks in New Zealand doing workshops (like the one I’m going to do this afternoon for you) for companies there. I arrived at about 12:30 this morning so bear with me… Anybody come further? Anybody from China? It depends on how you measure it. China’s further in distance I think but it’s actually less far in time zones. 12 hours to China, 16 hours from New Zealand.
So we’re going to talk a little bit about prioritization. I imagine that you’ve been listening very intently to Claire (Suellentrop) and the other speakers and you’ve got lots of great ideas. Well I’m going to talk about how you say no to some of those, in fact probably most of those because realistically we can’t get it all done. I’m going to make the contention that prioritization is really about saying no to good ideas because there’s always too many of them. There’s always more of them than we can handle and we’ve got to focus not just on the good ideas but on the truly great ideas – the ones that are really going to make a difference for us.
Before I get into that let me just bring you up to speed on who I am and why I have some expertise here. My name is Bruce McCarthy. I’m the founder of Product Culture which is an organization dedicated to the idea that there are certain characteristics, certain habits of mind, certain ways of acting that really great innovative companies have that propel them to success with product after product. I’ve been a product guy for a long time, for most of my career. I’ve been in product management roles or engineering management or UX or business development or agile enablement. I’ve done a lot of different things. Maybe I’m a Renaissance man. Maybe I’m just a dilettante but my job I think is seeing how it all comes together and prioritization is one of those key pieces. I’ve worked for as you can see lots of big companies and small ones either as an employee or as a coach. And I think that’s given me given me a lot of perspective. Also I wrote this book on product roadmaps. I wrote it with three other co-authors one of whom is in the audience – C Todd Lombardo say hi if you haven’t. And in it one of the most popular topics is prioritization because if you’re not going to put everything on your roadmap will you need to decide what are you going to put. And even if you are going to put everything on your roadmap which is not uncommon you need to decide what you’re going to work on first. I’m also happy that I arrived home early this morning to discover the book has just been translated into Chinese. So if anybody did come from China see me…
I’m going to start off with a story and then I’ll give you some frameworks that I used to resolve the difficulties I ran into in my first month as V.P. of a company that I didn’t start. I arrived there on the first month and there was a really strong executive team. They had brought a lot of varied experience to the table and we had one solid fairly successful product and the big question of the day and the question I think that I was brought in to try to answer as VP Product was – what do we do next? What’s the encore? Should we improve the current product? Should we go for an adjacent market? Should we have a second product? And there was no shortage of ideas. I went around and just collected a list of ‘what do you believe we are working on now’. What do you believe we should be working on now? And the list in the first couple of days got to be 75 items long. Sound familiar yeah? So I started to ask the question – well which of these things do you think is most important? Obviously we can’t do them all. And I wasn’t getting any consistent answers. The executives all had completely different points of view on what was going to make the most difference. The sales guy obviously wanted short term things that we’re going to make a difference right away. The finance guy wanted to make sure we were investing our investors’ money wisely. The president had some ideas that might take us two or three years for us to get there, big long-term things. And there was just no consensus. The engineering team had a backlog of technical debt that they wanted to retire. I’m seeing you nodding that you’ve heard that one before. So what was I supposed to do?
Well I’ve developed and had at that point developed a methodology over time that I’m going to tell you about to try to make some sense out of that chaos. The guy I’m going to use as my point of view character in this story is the product manager who I was hired to be his boss. He’d been there for two years and he could never get a consistent set of priorities or a consistent set of objectives out of the executive team. It was always the idea of the week and they never could complete anything before the next thing became important. So he was really frustrated and I’m gonna tell you the story of how we how we resolve that. This was his job. This was sort of how he felt – in the middle of a list of too many things to do and a list of stakeholders who all had their own point of view. This cartoon came from Product Management Journal in the UK about the challenges of being a product manager and actually the cartoon comes from a bunch of quotes that I put into a slide deck from Product Camp a few years ago and they gave me permission to reprint the cartoon. As long as they could use my words, I could use their cartoon. This is what it feels like if you’re in charge of the list of things to do. You’re the man in the middle and you’re doomed. You can’t please everyone. You probably can’t please anyone in the end. So how do you resolve it? I asked you guys in Slack – Why is prioritization important and where do you struggle? And obviously you guys had higher priority things on your list because I only got one answer. But it was a good answer. It was an emblematic answer, an answer I’ve heard many times before. My priority list is so long. It’s way too long. I can’t get all of this stuff done. Does this sound representative? Yeah. I’m seeing a lot of nodding and my challenge is to actually finish a task and not just slot something in as a higher priority and start working on the new one. This is something I think I referred to in another presentation as shiny object syndrome which is you know, understandable. We’re all in small companies, we all have way too long a list to do. How do you manage that? So that’s what we’re gonna talk about.
I also want to reinforce though before we talk about how to prioritize, why it’s so important. It’s very tempting to think well we’ll get to it. We’ll get to it all eventually right. But the answer is – even if you could you probably shouldn’t. And here’s why. This is a chart from the product road mapping book and it shows basically what the what the relationship is between the number of features that you ship and the number of tests that you have to run the next time you ship your software, and as you can see there is an exponential relationship. You have 1 feature, you test that 1 feature. You have 2 features, you test individually those 2 individual features and you test them together. You have 3 features. Well now you have a bigger matrix and it goes on exponentially as soon as you have 50/100 features. As you can see even 25 features gets you into the multiple tens of thousands of millions of tests of combinations of features that you need to test. This isn’t technical debt, this is feature debt. You keep expanding your surface area you keep expanding the amount you need to test. We wonder why after a few years of adding new features every new feature seems to take more time. This is why also it’s very common to say well we don’t need to prioritize. We can just do a bunch of things at the same time. Right. We’re great at multitasking right. Well no we’re not. We’ve all been learning over the past few years, human beings are terrible at multitasking and there’s some data from quite a while ago, 25 years ago, showing that. Above 2 simultaneous tasks – 2 is good because if you get a little bit blocked on 1, you can switch to something else – but after 2 the actual throughput of a human being when multitasking begins to go down. It’s actually lower than one at the point of having 3 simultaneous tasks. And the way this study was done, it’s not actually trying to juggle 3 things really simultaneously like driving and listening to a podcast which I did do on the way in here but trying to do things serially like quick switching which is what most of us are doing. That works the same at the team level – you could say well I have a team, I can spread their efforts around, but actually according to studies that also is a false belief that with a small number of simultaneous things somewhere around 2 or 3 your scrum team of 7-ish people can do pretty well. They have the ability to switch back and forth when they’re blocked on certain things or waiting on certain things. But as soon as you start to tip over to 4/5/6 things that you’re asking them to do at the same time you actually get less out of them in the same period of time so if you want to get a lot more done in the course of the year. Prioritize and tell people where to start – with this 1 or maybe 2. And then when those are done maybe two more makes sense.
The other thing to think about is things change. There’s shiny object syndrome. Funding comes and goes. Team members come and go. Opportunity – sales opportunities come and go. And so the number 1 rule I always tell people to remember when you’re prioritizing is essentially: you will not get it all done so you better figure out which 1 thing or 2 things if you get nothing else done you should have accomplished by the end of the week or the month or the sprint or the year. Focus on those exclusively and get them done as quickly as possible because you never know when the resources or the budget or the priorities will shift and you don’t want to get halfway through or even 90 percent of the way through 10 things in a row and have absolutely nothing to show for it. Which is exactly the quote that I just showed you a couple of minutes ago – 9 projects that are 90 percent done is zero value added to the company right, so if you could just get 1 thing done (it seems seems crazy and non-intuitive), but if you could just get 1 thing done that’s better. So we need to learn as humans, as people in business, as people who run small and medium sized companies, we need to learn to cherry pick the 10x ideas out of the big list of lots of good ideas, we need to say no to the rest of them at least temporarily, at least until we get some value out of the first 1. And critically (and this is a main theme in the product roadmaps relaunched book), we need to focus on outcomes, not on outputs. We need to focus on what is the reason why we’re doing these things, and let’s prioritize the things that are going to get us to our goals, to our objectives. I’m going to return to that theme in a minute.
So what are the things that are worth prioritizing. There’s a lot of things we could be prioritizing – we could be prioritizing whether to come to BoS or some other conference or just stay at the office. But I want to talk about it from a product level and a company and a software company level. So things worth prioritizing – customer problems or jobs to be done. Those are a good place to start. Then once you’ve decided all right, let’s nail this job or this problem, this customer need – what are the ideas that allow us to make progress on that? Then we can prioritize them. Or that’s the second item is if you’ve prioritized down to 1 or 2 customer jobs that you’re really trying to focus on solving, let’s prioritize a list of solutions to those problems or features or other things that we think will help get those jobs done for customers or solve those problems. It’s also worth prioritizing entirely new product ideas. Critically the whole lean startup movement is about testing your assumptions right. Some people may say lean startup or agile means we don’t need a roadmap, we don’t need a priority list we just start somewhere and we just go. But if you’re going to test your assumptions, if you’re going to test those risky assumptions about your business model you need to figure out well which ones are the most risky and prioritize those. You can’t start with all of them at once again. Start with one now where if I’ve convinced you that prioritizing is important.
Let’s talk first about how to get some bad ideas off the table. And the worst news I’m gonna give in this presentation is that your gut is probably wrong. Now I know as entrepreneurs and smart technical people and smart product managers and marketers and stuff we’re actually pretty used to trusting our gut where we feel like we’re right more often than we’re wrong, right. Somehow our gut has gotten us where we are. But in fact our gut is really very biased by a lot of things. It’s biased by recency – the guy I talked to yesterday or the magazine article I just read. Even if it’s customers, even if you’re doing a good job of talking to customers. Studies have shown that we tend to remember the most recent conversations – we don’t necessarily have a really great filing index system in our head. Jason Fried of Basecamp and 37 Signals fame said he doesn’t believe in keeping a list. He doesn’t believe in mining the data. He doesn’t believe in prioritizing. He says the things that come up over and over again, those are the things that when you’re thinking about it will float up to the top of your mind. He’s basically saying use your gut and I don’t believe in that. I mean I think yeah you need to use your gut to check your logic but let’s apply a little bit more rigour than that than what was the last thing I heard. Or for that matter, suppose that you talked to a lot of customers. But most of those customers are the ones that are paying you the most money. It’s the two or three really biggest customers. And what about the rest of them? Or maybe it’s the other way around you’re collecting a lot of data through surveys and it’s statistically valid in terms of the number of customers but which of those are really your best customers? We need to apply a little bit of filtering logic here. I don’t really favour analyst opinions too. I’ve spoken to a lot of analysts and I’ve sort of cracked the code. They’re listening to us more than us listening to them. If as a bunch of software vendors we all tell them the same thing, they kind of write that down and tell the world about it. So I would rather drive analyst opinions than then make decisions based on them. And then the flip side of your gut is popularity. Just having it all be a beauty contest which features or problems are the most voted on by customers. Is Richard here? Richard White, CEO of UserVoice, runs a forum product that for years I publicly was actually not that crazy about, because it allows customers to vote on features. But in the last few years Richard has gotten my religion, if I can say, and has added a bunch of capabilities to the tool to allow you to sort and filter through that information by type of customer and segment and to associate that with the ideas for solving the problems. And I think that’s a smart way to do it, combine the signal from the customer with some strategy, with some logic, with some filtering sales requests. Of course those are the most likely to be biased by recency, by I talked to a guy yesterday, or I have a deal in the pipeline right now. And as we all know salespeople can be very persuasive. So again applying a little rigour is helpful and services requests those tend to be a little more data driven. I have a little more respect for “well we get 30 percent of our calls all about this part of the product, so could we fix that” but still you need to apply a strategic lens – is making this type of user, who is unhappy right now, happy actually in our strategic interest? Does that solve the growth needs of the business strategically? Maybe, but maybe not.
So let’s talk about some better ways to rank ideas. First of all we want to be comparing apples to apples not to the orange fruit. We want to be prioritizing jobs to be done against other jobs to be done, needs against needs, features against features, or product ideas against product ideas. If we mix everything up on one list it’s very difficult to compare them. Then you’ll have a small bug next to a major initiative that might take us a year and how do you set a priority between those? You don’t. You use some sort of framework to put those into different buckets so I’m going to talk a little bit about different prioritization methods you can use for different situations. I’m going to get to my favourite sort of all-purpose one but let me talk about a few others first. Jared Spool was here the other day and spoke. He’s a big proponent of what’s called the Kano model – is there anybody familiar with this one? Yeah several people. Good. This one is really great when you’re thinking about something new and you’re gonna get your checklist of what’s minimally going to drive success with my product or if you’re thinking about something over time. Actually it’s also useful at the other end of the spectrum. You’ve got something mature and you need to think through what’s next for this and basically get the concept behind the Kano model is that people have a hierarchy of needs. They have certain basic expectations that kind of must be in it in any product. And then they have things that they might not expect that are what are called delighters. That’s the green arrow up there. And the ideal product covers all of the basic expectations and has at least one delighter, one differentiator. One thing that says “oh this one’s better and different than all of the other ones”. The other critical insight for Kano is that that changes over time – people’s expectations evolve and they always get higher not lower. So let me give you an example: iPhone. When the iPhone came out smartphones were equivalent essentially to BlackBerrys. The BlackBerry was the most common most popular smartphone before the iPhone and it had a bunch of basic expectation type features. When the iPhone came out it was the first popular smartphone with a touch screen and a full-length screen instead of a physical keyboard. And that was a delight. Everyone wanted it, it became THE IT product. And I still have one right here. And the thing is though now touch screens are just basic expectations, every smartphone has a touchscreen and if you don’t have one then why would you buy it? It’s moved from being a delighter down into the basic expectations category. So iPhone has to start thinking (if they want to stay at the leading edge), what are the new dividers? And this year’s Apple event, I don’t about you guys, I could take it or leave it. I didn’t see any real new dividers. Yeah a little bit faster, yeah a little bigger screen, yeah a little better camera. I’ll wait until next year. So this is a useful model in those circumstances where you’re trying to think through the logic of what do we need, have we got all the basic expectations checked off? Hint: if you’ve got exciting enough delighters, sometimes you can even skimp on a few of the basic expectations. This is a good way to prioritize. When iPhone first came out, no 3G support, no cut and paste, no support for exchange email server, and yet it became THE IT product.
So let’s talk about the next method the next method: who’s familiar with MoSCoW? Anybody? A few people. So MoSCoW has nothing to do with a city in Russia. It’s just a way of describing the levels of priority and the expectations it go. It stands for Must have/Should have/Could have/Won’t have – it’s an acronym. So must have is “we will not ship without it”. We will wait to ship until we have it. Won’t have is the other end of the spectrum. We’ve agreed it’s out of scope. Extremely useful in discussing expectations and getting everybody on the same page and then the other two are creating gradations in between. This doesn’t help you do your prioritization but it helps you describe the result of your prioritization.
Then there’s this very popular method. Feasibility desirability and viability (FVD). The concept here is you are looking for ideas that hit strongly on all three of these. So essentially you’re looking for the intersection of all three of these. So feasibility is: we can build it, it is technically feasible. Desirability is: the customers want it, someone will pay for it. And Viability is: we can make money on it, we can build a business around it. And so it’s essentially a mental checklist. If you can say well I’m not sure or probably not on any one of these you should not be doing it. It’s also useful if you wanted to give yourself say a one to three score on various ideas in each of these three categories as a way to do a rough sort on a relatively short list. But I’ve found in practice that if it’s a long list or if there are multiple considerations in the viability area or the desirability area, if there’s a lot of different objectives you’re juggling that this is a little too simple.
So I’m going to tell you about a couple more methods that I’ve used successfully. The first three up here are the same ones I just showed you the Desirability Viability Feasibility is good for a sort of a quick checklist screening as I mentioned. Critical Path is another method we describe in Chapter 7 of the of product roadmaps relaunched and that is extremely useful for MVP. It’s very similar to jobs to be done in that you’re describing what is the critical path the user will take through your application in order to get the most important job to be done done. What are the minimum number of functions and features that are necessary in order for them to extract the value from your application. There are a lot of things you’d like to have in the product but those can all stay out of your must haves in your MoSCoW and the shortest path to MVP is the critical path for the key job to be done of your application.
The other method I want to talk about I call the ROI scorecard. This is the method that I used in that situation where I had a list of way too many things to prioritize and an executive team that was not aligned at all on what the priorities were. And so I’m going to describe that one a little bit more detail. It starts with objectives and in my mind your business objectives help you. In fact they are the best way to boil down your list of too many things to do and say you’re essentially asking the question when I say it when I ask what should I be working on I really should be asking what am I trying to accomplish. What does success look like for me in my business if I can describe that first. Then it becomes much easier to describe well what must be true for me to succeed. So I want to separate those two things. I want to separate means versus ends. What you want to accomplish versus how you want to accomplish it. So when talking to product teams I often hear things like… I ask them know what are your objectives. They say we want to do an HTML5 redesign but that’s not really an objective. That’s a means to an end. So I ask them why do you want to do that. And they say Oh well our site doesn’t work well on mobile. And a bunch of our customers are moving to mobile and so they’ve started to complain and we’re afraid we’re going to lose them. Oh. So what you’re saying is you want to keep your customers happy and you want to keep them longer because the longer they stay the more their lifetime value is to the organization and they go. Yeah that’s it. OK well are there some other ways that we might be able to increase lifetime value? Maybe an HTML5 redesign will help but maybe that’s not the easiest fastest quickest way to increase lifetime value. Maybe we should think about technical solutions – maybe a mobile app is actually better for that, a native app. Or if we’re thinking about keeping the customer, maybe we should start talking to those customers and finding out what’s really bothering them. Maybe the website that doesn’t look good on mobile is only the tip of the iceberg. Let’s get the real objective straight. I’ve also heard “well we need to get more into social”. We need to integrate with Twitter and Facebook and all these things and again I ask the question well why what’s the goal? What are you hoping will be the result? What problem are you trying to solve? Well we want to get the word out. We want customers to be able to share what they’re doing in the application so that their friends find out how great it is. Oh so this is about awareness. This is about growing market share through greater awareness in the market. This is a marketing ploy. Yeah it is. OK. Well let’s say that’s an objective and then let’s look at. Let’s create a list of ideas for ways we can increase awareness. Maybe social integration is one of those, maybe it’s not top on the list. Let’s work it through – customer requests. We have loads of requests for customer features. And as I mentioned, you know one thing you could do is just look at what are the most frequent customer requests and let’s do that. Well that might make sense if the type of customers you have now who are making these requests are your most valuable customers and you just want more like that, or you want to keep them. But let’s suppose that you’re actually pivoting and you’ve decided you’re going to go upmarket to enterprise customers. The requests from your small customers might or might not be leading you in the right direction. So you’ve got to ask yourself what are we trying to do? Well maybe actually we do have a mature product. And the biggest thing we fear is that people will churn and go to a competitor’s product. So we want to be responsive to our biggest customers and their requests to cement the relationship. OK great. Let’s say that the goal is competitive barriers and let’s then figure out what’s the best way to erect those competitive barriers. Now usually at this point the conversation people are saying OK I get it I get it I get it. So how about revenue. That’s an objective right. We want to grow revenue. Well yeah but maybe we could be a little more specific than that. Maybe we could say we want to grow recurring revenue or much earlier in the lifecycle. We want to get new logos. We want to get new deals signed or we want to sell them something else. So we want to increase. We want to bundle things and increase the average sale price. There are a lot of ways that we can be a little bit more specific about what we mean when we say money is an objective that help us prioritize things. Scalability is often something that an engineering team or an operations team will say is an objective. But again I ask why is scalability an objective? What are the underlying assumptions and what do we mean when we say scalability? So there is an objective in my framework that I’m going to share in a moment about fulfilling more demand. If it turns out there’s a big greenfield market out there and the bottleneck to the growth of your business is simply that you can’t service at all. Great let’s say that is the objective. And then let’s look at what it does it all mean.
My favourite one though… so I go through this translation exercise and one of the things that my CEO at that startup where I was VP said to me is: “Bruce I want transformational ideas”. And I said OK, how do I translate that into an objective. And he wasn’t really clear about exactly what he meant by that, but I had my schema about objectives including revenue objectives. And I began to realize when talking to him that what he was saying was we had some very interesting IP. He thought maybe there were other places we could apply that where we could be disruptive in other industries and have a future possible engine of growth after inevitably what we were working on then would mature. So leveraging our assets for future long term revenue growth did actually make some sense. After I sort of chewed on it for a little bit and when I said that back to him he said yay! That’s it, spot on you got it. So how do I do this translation trick? It turns out actually there are a very limited number of possible business objectives when you start peeling back the onion and you start asking why over and over again, it comes down to a few different possible things. And I’ll walk you through them. It’s actually very simple.
So first there’s 3 big buckets. The Value bucket is: I don’t have something yet, I need to build something so I can start to sell it. And within that bucket is: I need to support the core value proposition that is I need at least one job to be done that can be done with my thing so that someone will say “Oh yeah, that’s useful to me I’ll buy it”. So this is your critical path again this is stuff that must be done or you have nothing. And then also in the value bucket in my mind is erecting at least one barrier to the competition some sort of delighter some sort of differentiator. Some reason why people should buy your thing instead of some other solution to that problem. And having established this you at that point can you at that point you’ve essentially hopefully reached a minimum level of product market fit and you can move into a growth phase. That’s really how you know you’ve reached product market fit is your product begins to grow and not every sale is a heroic effort. So within the Growth bucket there are actually only four possible levers: you can improve recurring revenue (more money per customer), Grow market share (more customers), Fulfill more demand (another flavour of more customers), or Develop new markets (open up other other areas where people haven’t been buying your kind of product). Those are really the only ways that you can grow as a product or as a company. One of those one of those things if you’re in the growth phase is going to be one or more of them is going to be a good set of business objectives for you. And then as we all know products eventually mature. At BoS last year I had a conversation with the CEO of a company in Philadelphia who was saying that after the first few years of steady growth their company plateaued and it was a very depressing moment for her and her team until they realized well maybe their product was mature, but it didn’t mean their company had to stop. So they started building new products and I think they’re on their fourth at this point. But how could they fund that? They can fund that with the profits from the first product. So usually at the point that a product reaches some sort of maturity is the time when you can raise prices, or you can improve lifetime value by keeping customers longer. You can leverage those assets as my CEO wanted to do in other areas or you can lower costs to increase that profit margin and find the money to go and fund more things in the green category. So let me give you a little bit more labelling on these.
The value bucket is before you get to product market fit it gets you to product market fit. The growth bucket comes after that. And then there’s the maturity bucket. Generally speaking if you’ve got multiple objectives they will be in one or perhaps in two adjacent. If you’re in the process of transition of these buckets that’s for a single product you might. On the other hand have multiple products in a portfolio at different stages of growth. And that’s normal and OK. This is out. This is from McKinsey this is their 3 Horizons growth framework. It’s a good way of thinking about how you allocate resources across a portfolio of multiple products and critically the business objectives that each one of these phases of growth is are different. Just like I showed on the previous slide and so you’re going to do prioritization within those buckets comparing apples to apples on say a product that’s in the growth phase versus oranges which is a product that’s in the mature phase. So first divide up your world into some buckets of similar things that have common business objectives and then prioritize within those buckets.
Did anybody watch Elon Musk’s Roadmap to Mars presentation video a couple of years ago? Nobody. A couple of people. OK I thought it was fascinating. It’s really a roadmap even though he didn’t really show a lot of PowerPoint it was mostly video and him talking. It was really a roadmap to how he plans for humans to become a multi planet species. He actually has the idea that we can make going to Mars a reality in this lifetime. And when he says in this lifetime he means for average people like us. He means that you ought to be able to sell your house and in the US the median home price is two hundred thousand dollars or was when he made this presentation and use that money to fund a trip to Mars. Where you’re supposed to live when you get there I’m not sure… But details… He’s done a good job though of setting an objective of reducing the cost of space travel lowering costs to the level that an average American family can afford in service of his product vision of a spacecraft that can do that affordably in service of his long term company mission of making going to Mars a reality in this lifetime. So these kind of objectives can be used in quite shall we say lofty endeavours. I want to give you another example though that’s a little more down to earth. This is a local company called Contextually and this is their roadmap from 2016 and this is the real unadulterated roadmap. And what you’ll notice is that it is an internal roadmap but they’ve driven it entirely off of objectives. Every one of the items in this outcome-we’re-seeking column (the far almost far left column) is one of those business objectives or can be traced directly to it. The first three are all about ASP (Average Sales Price), which is one of those measures of revenue. And then the next one down is 15 percent improved long term product usage. That’s going to lead directly to retention of customers over time and better lifetime value and then invest in infrastructure efforts that will allow us to differentiate more because they still feel like they’re needing to maintain that differentiation. And the last one is increased percentage of new trials fully onboard and that’s driving customer acquisition of which there are two possible objectives in my growth phase. Everything on the roadmap that they’re doing in terms of initiatives is driven by these objectives. And a roadmap that’s driven that way is really powerful way to explain why to every stakeholder inside the organization and a really good way to judge. “Oh we have this other idea” – well is it better than these ideas in increasing ASP? Well now we have a way to prioritize, to judge between them.
So my mathematical formula – and I’m gonna do a little bit of math here – is that clear objectives plus simple math plus critically good discussion equal aligned priorities. We’ve been talking about objectives. I want to talk about the simple math and the good discussion part and then we’ll wrap up. So here’s that that fifth method of prioritization that I promised you. I call it the ROI scorecard. Return on Investment scorecard. And it’s really a very simple mathematical formula I promise not too much math. I was an English major so you know I like to keep the math simple. But it’s actually just a simple formula, bang for the buck if you will. Value over Effort equals Priority. So things that deliver value for the least amount of effort, the most value for the least effort, are the things you should do first. Seems self-evident in some ways and yet we struggle with this but let’s talk about how we define our terms because this is it. This is the important part about having a discussion about our Why. Because everybody like all those executives at the company I joined has a different idea of these terms. So effort is the time and resources required to do something to get something done. And usually in a software company the constrained resource is engineering or maybe its design. So it’s about Scrum team time or engineering time or man months or something like that. So that’s the effort side the value side. This is where people when they do a spreadsheet like this often go wrong. Either they have just one measure of value which is revenue and they’re often not specific about the time frame. But as we’ve seen revenue can be broken out into a number of different components or they have 17 different components and it’s just too complicated for anybody to follow. And simplicity I think is useful here. So value is measured in my mind about contribution to those objectives we discussed. If you can define your business objectives then you can rate every idea whether it’s a feature idea or a job to be done or a new product idea on the contribution to those objectives and you can add them up if you have multiple objectives and most of us do. Sweet Spot is somewhere around 3-ish objectives, 2 is OK. 3 is better. At 4 or 5 I start to wonder if they’re really that independent from each other but 3 different objectives and you can add up the scores on 3 different objectives and say All right. Idea Number 42 scores really well on all 3 of our objectives. So we’re moving it up to the top in prioritization. Similarly you can have multiple different types of effort if you want maybe there’s marketing effort as well as engineering effort maybe design is a different constrained resource and you need to take that into account but actually keeping the effort side simple especially when you’re at the idea phase or the way especially if you’re prioritizing things like problems or jobs to be done that have not you don’t yet know what the solution is over complicating the effort side is not not your friend and then there’s one other factor I like to use in this formula and that is confidence all of these scores that you’re going to do in this spreadsheet are guesses. Their attempts to predict the future and they’re inherently unreliable. But you can actually try to guess how good or bad your guesses are and that’s your confidence factor. So this is a bit of a fudge factor and it helps to get separation in your spreadsheet. It’s your confidence that your scores on both the effort side and the value side of the equation are right. And what will tend to happen in this is if you’re confident, if you’ve done this kind of thing before, you know customers will value it. You know how to implement it, your confidence will be high. And if it’s really hitting on all your goals and slow effort well you should do it. If on the other hand even though the scores look good without the confidence you’re it’s actually kind of speculative. It’s a little hairy, you’ve never done this kind of thing before or you haven’t actually spoken to any customers yet about whether this is a useful solution to them. Your confidence is going to be low and it might feel frustrating that the thing is at the bottom of the list when it feels like it could be real successful. But what that’s telling you is you need to do a little bit more homework. You need to do a little bit more research and then you’ll be able to validate those assumptions and you’ll be able to bring it up or not you’ll find out that your assumptions were all wrong and it should just be scuttled altogether.
So that’s the scorecard – let me give you an example going back to SpaceX. These were the 4 things that Musk said in his roadmap presentation he thought were the most important things that would help them reduce the cost and increase the feasibility of a regular round trip to Mars. Reuse – being able to reuse the spacecraft instead of throwing it away every time like we currently do was the thing that he said was number one. And so you could do a simple spreadsheet calculation like I described. Let me walk through the math for you, it’s very simple. If he had three objectives and the full reusability hit strongly on a scale of zero one or two on all three, then all three get a two. And so that adds the that adds up to six for the value. Divided by an effort of one is a raw score of 6 multiplied by 75% confidence is 4½. All the rest of the table works exactly the same way. Confidence levels are dropping as you can see. And that tends to push things down, but also the value side and the effort side are changing and that gives you an order of priority to work from in your spreadsheet. Now you’ll notice how simple the math is here. It’s deliberately simple. It’s deliberately a small scale of numbers that are easy to do in your head. It’s deliberately very few factors. Again so that your stakeholders whether you are the CEO and you’re trying to get your team onboard or you are the product person and you’re trying to get the CEO on board. It’s all meant to support a good discussion to break out the logic of prioritization decisions so that people can see it and understand it. It’s transparent and trustable.
Now I mentioned that the scale that I like to use especially on the value side is 0 1 or 2. And I wanted to just cover why that is. It’s very tempting to try to get very precise in a spreadsheet like this. Oh we can put dollars into the revenue column. Oh we can put person months into the effort column – no we’re not trying to do a revenue forecast yet. We’re not trying to do a project plan with detailed resourcing and so on yet we’re just trying to sort a list of way too many things down to the really promising things back to we need to find the 10x opportunities so detail here is actually fighting against that it causes you to go into analysis paralysis. Well is it $1,000,000 really or is it more like $950,000. I don’t care! What I care about is small medium or large. And that’s essentially what this is – small medium large where I’ve discounted small to zero because I just don’t care about small effects. I have to be really ruthless about my prioritization. So I’d want to keep it simple and I want to avoid fine passing arguments with my with my stakeholders I just want to say look is it small medium or large effect.
And let’s move on from there but let’s imagine that you’ve gone through and you’ve done this scorecard exercise like I did with 75 different items on my on my spreadsheet. That is not the end of the process if you’re gonna get anything done – you need buy in. If you’re a solo entrepreneur I suppose you have buy in as soon as you’re done, but most of us work in some sort of team. And so if the team is involved in funding what you’re gonna do or executing on what you’re gonna do, or picking up the ball afterwards say a marketing or sales effort, you need buy in. And the earlier and the more thorough you get buy in the better again hence the simplicity of the model. So I have this method that I call shuttle diplomacy which is essentially named after our former Secretary of State Henry Kissinger who managed to negotiate a cease fire in 1972 between Egypt and Israel when neither party would speak to each other or recognize each other’s governments. He did that by literally shuttling back and forth on a plane from capital to capital and negotiating between them and as a product manager and as a head of product and as an executive I’ve used this method frequently to try to get buy in on lots of different things. Let me tell you a little bit about how I work at but first as anybody heard the story of the Lost balloonist Rich has do you want to tell it. OK thank you. OK so a man decides that he wants to attend the World Fair and he tells a friend I’m going to meet you there but I’m going to bring my hot air balloon. I’m going to use my hot air balloon to get to the to the fair and so he starts up the fire gets up into the air and he’s on his way to the fair and sooner or later he realizes he’s lost. He can’t figure out which direction is the fare from here. But he spots a man in the field and he lowers the balloon to within shouting distance and says to the guy hey “I’ve told a friend I would meet him at the at the State Fair and now I’m lost. Can you help me?”. The man on the ground thinks for a minute and says “OK you are in a hot air balloon 50 meters above the ground” and he even gives him the longitude and latitude of where he is at that moment. And the guy in the balloon says “you must be an engineer”. And he says “well I am, why? How did you know?”. And he says “because what you’ve told me is factually correct and detailed and completely useless. I’m still lost”. And the engineer on the ground says “he must be in marketing”. And the guy in the balloon says “yes I am. How did you know?”. And he says “because you have made promises you have no idea how to keep. I have answered every one of your questions. And yet somehow the fact that you’re lost is my fault. Oh and and you’re full of hot air too”.
The point of this is that everybody has their own point of view. Everybody speaks their own language. Everybody has their own idea of success. So the first thing you’ve got to do is you’ve got a lot a line on those objectives. And it’s difficult, really difficult to have a conversation with a bunch of people with who are speaking different languages who come to the table with different expectations and objectives all at the same time. Imagine if the Berliners came across a crowd of six different people all with different backgrounds and got six different answers. How might they resolve all of that. It could be quite difficult and you need to sort of recognize that you need to sort of map out your stakeholders when you’re thinking about prioritization to get people on board. In a typical software company these days you’ll have a core team of a of engineers and design and maybe testers and some sort of product person and they are working full time on your behalf trying to get stuff done. They have though they can’t operate. I know we say we want teams to be autonomous but they can’t operate in a vacuum. They need buy in and so they need to consider this whole. I don’t know whether this is a solar system or an onion but all the layers and all the orbits around their effort and who’s going to have input. Who’s going to care who’s going to make use of what we provide and they need to get buy in from this crowd along the way and they need to understand their points of view. I mentioned Henry Kissinger already so the first thing I recommend is that you meet whoever you is whoever the person keeping the priority list is whether you’re a product manager an executive a program manager or a project manager, a Scrum Master it doesn’t matter whoever you are. Figure out who your stakeholders are. Do you create a map and go and speak to them one on one? Do it informally before you have the big meeting with everybody together and all the egos and all the different languages all talking over each other and trying to impress each other rather than trying to make a good decision. I’ll give you a couple of tips for that. It can be hard to get on people’s calendars to get on a lot of calendars before the big meeting and have pre meetings with everybody. So I don’t usually bother with that. I actually find it’s much better to make it a really informal conversation so rather than schedule a meeting I’ll just run into them in the hallway and say I have a draft set of priorities would you help me refine it and then we talk about it a little bit. I can’t usually get them to talk about everything on the list as in in a sort of a by the way hallway conversation but that’s OK I don’t need them to talk about everything on the list. They probably only care about half a dozen things they either think that those are the most important ideas or the stupidest ideas and they want to get them to the top of the list or off the list altogether. So we focus on what’s important to them and then if we if I’ve done a good job of listening and adjusting scores in my prioritization metrics matrix while we’re talking then they feel like they’re heard and they feel like they’ve collaborated with me. They feel like they have co authorship of this thing. Has anybody heard of the IKEA Effect? Why do we love our IKEA furniture. Because we built it ourselves it’s not that it’s great. We get to say I did that right. And so if you’ve done this right then when you get to the big meeting everybody is elbowing everybody else around the table bragging about how this was not just Bruce’s plan. This is our plan so I’ll present our priorities at the leadership meeting on Friday as is the language you want to leave them with so let me tell you how this turned out. I did all the things that I was telling you about. I made a spreadsheet I put in the business objectives. I got a little bit lucky that the CEO and the senior team had just been to a board meeting and had told the board what their business objectives were for the next year. So I was able to slot four things in that they told me right away at the top and they already agreed on that stuff. So then I went from person to person one on one informally. Another tip for people who are it’s difficult to schedule with just hang out by the coffee machine. Sooner or later they all come by except this one guy the CFO didn’t drink coffee didn’t drink tea didn’t drink soda. I think it was a deliberate plot because he was anti-social and didn’t want to run into me or anybody else at the coffee machine. But he did come in at 7:00 a.m. in the morning so I discovered if I just showed up early that nothing would be on his calendar and you couldn’t avoid me. So I did the shuttle diplomacy and I went through the things on the scorecard and I really kept it informal. I actually took my laptop and sat down side by side with the person rather than across a table or in a conference room and said look I’m thinking about this and I need your opinion on this. And what do you think about that. And it really was a collaborative co creation sort of thing. The result of that when we finally did get to the big meeting where we needed to take this list of 75 things and narrow it down to the things we really thought we should be working on right now and the rest of this year. And it took about an hour and a half and we came out of there with green yellow red. We’re going to work on it. We need more information. We’re not going to work on it and the product poor product manager who’d b een there for two years struggling to get that team to align came out of there slack jawed and said that was magic. How did you do that? And I said wasn’t magic. I just I have a little bit of a process. It was it’s just clear objectives simple math and some discussion one on one. That’s how you get there and that those priorities worked out pretty well. We pretty much followed that same set of priorities for the next few years and we sold the company to Dun and Bradstreet for $425 million a couple of years ago based on figuring out what we were gonna do next, based on focusing down not on everything on the list but just on a few key things.
So if this has been useful to you at all that’s pretty much the end of my talk. Two things: One is I have what I call a nano letter it’s one thing it’s meant to be short. You can actually read it in the line at Starbucks – not a newsletter because my list of newsletters is prioritized but I never get even to the first one. So this is meant to be bitesize and it’s basically one thing about product culture and about this way of thinking about things every week. The other thing is I’m going to be doing a workshop in the afternoon between 1 and 4 and I don’t know if there’s still any room but we’ll be going through not just one chapter but all the chapters on this today and we’ll get a chance to practice this method of prioritization as part of it.
Learn how great companies are run
At BoS we run events and publish content that is highly valued by anyone trying to build, run, and scale a great software company.
Sign up for a regular dose of actionable and useful content: