Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about a prioritization framework to deal with task overload. Based on a blog post by Anthony Eden, they discuss business problems and the purpose of creating a framework.
Items mentioned in this episode:
Transcript
Mike [00:00]: In this episode of ‘Startups for the Rest of Us’ Rob and I are going to be talking about a prioritization framework to deal with task overload. This is ‘Startups for the Rest of Us’ episode 332.
Welcome to ‘Startups for the Rest of Us,’ the podcast that helps developers, designers and entrepreneurs be awesome at building, launching and growing software products. Whether you’ve build your first product or you’re just thinking about it. I’m Mike.
Rob [00:25]: And I’m Rob.
Mike [00:26]: And we’re here to share experiences to help you avoid the same mistakes we’ve made. What’s going on this week Rob?
Rob [00:30]: You know you reminded me that I haven’t mentioned the conference that Drip is putting on. You know, it’s via Leadpages but it’s called Automated. And it’s the first marketing automation conference that we know about. So, we have Automatedconference.com and it’s virtual marketing automation conference April 12th through 13th. So, it’s during, I think is that MicroConf starter addition?
Mike [00:52]: Yes. It’s during MicroConf Starter Addition.
Rob [00:53]: Right. So, obviously, I will be prerecording my thing since it’s virtual. It’s nice to be able to do that. But if you’re interested at all it’s free and there’s a recording available after but I think that actually costs money. If you watch it live it’s free. And a really good speaker line up – Ezra Firestone, Laura Rotter, obviously, Clay Collins and Brennan Dunn, Anna from my team. There’s a lot of folks that are going to be dropping some mad knowledge on email marketing, marketing automation and that kind of stuff. So, check it out if you haven’t. It’s automatedconference.com.
Mike [01:23]: I almost feel bad because I think I feel like I have to correct you here. But the website says that the recordings are free if you register by the 13th.
Rob [01:30]: Oh, sorry. Thank you. I misread it. Yeah, it’s funny you know. It’s a trip – I mean I’m not putting it on myself, right. We have a conference organizer so I haven’t even been heavily involved in the planning of it. But that’s good. That’s a good way to do it. Is to give it away.
I know. Thank you for correcting that Mike. I appreciate it.
Mike [01:46]: It almost feels awkward.
Rob [01:49]: I know. Don’t worry about it. I’m glad you did so that everyone listening doesn’t feel like they have pay for the recordings.
So, how about you? What’s going on?
Mike [01:56]: Well, I did want to say congratulations over to the guys over at Snappa. They wrote in to us and said, “Hey, Mike and Rob. Huge fans and longtime listener. A lot of the strategies discussed in your show helped us grow our startup to $25,000 in monthly recurring revenue in 16 months without raising any funding. Just wanted to say thanks and looking forward to MicroConf next month in Vegas.”
Rob [02:14]: It’s pretty cool. Snappa.io and their value prop is to create marketing graphics in a snap to whip up graphics for social media ads, blogs and more without photoshop or graphic design skills. So, it’s kind of like an in-browser editor but completely designed to manipulate images and make them kind of marketing and ad worthy.
Mike [02:35]: Yeah. I mean the interesting thing about that – and saw this several months ago – was that they’ve kind of aimed it at the people who are doing advertising on Twitter and Facebook. Because all those things have image requirements that are slightly different from one another and they make it easy to kind of do all the things that you need to do to make the images social media ready or ad ready. And it’s really nice to just have a tool like that that you can just log in and – boom – you just make all those little tweaks and edits and now you’ve got your images. As opposed to having to send them out to a designer and say, “Hey, I need 10 different variations of this.” And figure out what the variations are that you need. It’s like they kind of have it built in.
Rob [03:10]: Seriously. I totally could have used this when I was running Facebook ads. I used to spend so much time in Pixelmator which is what I use on Mac to edit. And it was just redundant work over and over and over. And then I eventually outsourced it but it was always hard to keep a designer.
All the designers I find who are good, they’ll end up taking jobs. They don’t stay freelance. They either get really expensive or they take jobs. So, I was always either trying to find someone for this tiny project or doing it myself. And I really could have used a tool like this. So, congrats to Christopher Gimmer and the folks over at Snappa.io.
So, in terms of Drip updates, we’ve hit our stride. We hired, frankly he’s a UX/designer and he also slices stuff in HTML and he started like – it was several months ago now. Probably four or five months ago – but he’s really hitting stride with just cranking out front end stuff and we’ve always had like a really deep pool of rails developers on our team. And so, kind of our limiting bottleneck has often been for new features has been like front end work. And now that both Derek and – I say he’s the new guy, but he’s been with us like four or five months now – but now that he’s really hitting his stride it just feels like we’re shipping something. I think we’ve shipped like two or three fairly substantial features just last week. And, while we can’t maintain that pace all the time, I do think that we’re really hitting that stride of getting something meaningful out. And by meaningful I don’t just mean like a check box or a little tweak to this, a little tweak to that. But like an entire sequence of screens that does an entirely new flow. Like we added merge subscribers where you can merge Drip subscribers into one. We added global UTM settings so it’s several tabs of doing something that then defaults to all your links any time you put them in an email. Self-serve SPF decam which is the way you can verify your own sending domain and that’s like six or seven screens deep. And deals with the sendgrid api. So, there’s a ton of stuff that we’ve been tripping.
So, that feels good. I mean I realize Derek long ago looked me in the eye and said, “We are product people. Like the dopamine rush is from shipping features.” If you don’t ship features for a while, I start to forget that. And then having feature go out after feature, it reminds me of that’s really why I’m in this. You know? Is to get cool stuff out the door that customers are clamoring for. And then to hand that off to the marketing department and have them market and talk to support about it and have them say, “Oh this is so cool. It’s going to help our customers.” It’s a really good feeling. So, I’m kind of feeling – especially the last few weeks – just feeling up and optimistic about things.
Mike [05:31]: That’s cool. I stumbled across the merge and the UTM thing on my own when I was in there. Because I was automating my inbound lead fall for Bluetick and found those settings. I was like, “Oh, awesome.” And then I just sort of used them already. I haven’t seen the other one in terms of the DKIM stuff but I did use the other ones when I stumbled across them.
Speaking of that. I started automating my inbound lead funnel for Bluetick so I changed my homepage to have this ‘Request an Invite’ right on the homepage. That’s kind of the main call-to-action. And once you submit that, it sends the email address over into Drip and then there’s a workflow there that will wait for about 10 minutes or so because the next page after they do that is it takes them to a survey. And if they don’t fill out the survey, then Drip will start sending them a couple of reminders to say, “Hey, you haven’t filled this out. It would really help us out.” And, really, that’s essentially a prequalification mechanism for me. So, I look at that and, when the submit it, the form will remove them from that campaign in Drip and kind of put them into this sort of a holding area where when the form gets submitted it goes to a Google spreadsheet and I look at it and I can just mark it as either qualified or unqualified. And if it’s qualified then it sends it over into Bluetick and Bluetick invites them to a demo and then it creates a task and I can modify the text of the email that it gets sent to them based on what it is that they said to me inside of that survey.
I’ve started using this a couple of weeks ago and, so far, it’s working really, well because I can show people who’ve gone through that and they get to a demo exactly how they got there. And it’s just dog fooding it like a second level where I get to not only dog food it and use the product in a way that my customers would but I show them how I use it and I can show them their contact information and all the different touch points that they hit and why certain things happened.
There was one guy who replied to an email and he signed up for a demo. It was like from an email that was sent at like 7:00 in the morning. And I surely did not send that email. But he saw it and said, “Oh, yeah. I signed up for this and I filled out the survey and I didn’t respond to that first email. I should do this because you, basically, reminded me.” But it wasn’t me that sent it. It was Bluetick.
Rob [07:37]: That’s super cool, man. I mean, the dog fooding stuff we talked about a few weeks ago. But it’s a big deal. A: to get this automated to save you time. But B: to be using your own product and to be able to demo it during that process. So, you kind of have the luxury of having a product that is demo able during the sales process to the people who’ll be using it. Congratulations. It sounds cool.
Mike [07:58]: Yeah. It’s nice to be able to do that. And it’s just interesting to see the different reactions. Somebody had asked me about whether people frown upon seeing how the automation behind it is working and the fact that I’m not actually sending the emails. So far I haven’t gotten any push back. In fact, a lot of the people I’ve talked to have said, “I like that you do this because it shows me what my customers are going to see and, even though I have in the back of my mind, I know that it is probably automated. It doesn’t matter because it solves my problem.”
Rob [08:27]: Oh, I totally agree. If you were showing me that and I was your prospect, I would think that’s genius. Like the moment it pulled the curtain back and showed the ‘Wizard of Oz’ scene back there, I’d be like, “Dang, that’s it. I’m sold.” I think it’s a cool way to demo it.
So, before we dive into our main topic for the day. I wanted to revisit our goals. Kind of do a quick status update on the goals that we set back in December of 2016 because we’re almost through the first quarter of 2017. We haven’t in the past revisited them until a complete year later. And so, this time I figured we’d just take like a couple of minutes and quickly go through the goals and see how we’re making progress on those.
So, your first goal for 2017 was to log at least 100 days of exercise this coming year. And if you’re on track to do that then you would be approaching 25 days of exercise.
Mike [09:23]: Approaching 25. Yeah.
Rob [09:24]: Right.
Mike [09:24]: I’m probably at 15. Something like that. So, I’m definitely behind. It’s just not something I’ve been able to get to every single week. But there’s definitely those times where it’s not too hard to get to at least two or three a week. But then there’s other times where stuff comes up and I have to deal with it and I just kind of fall off the rails for like a week or so at a time. But I’m a little behind. It’s not outside of the realm of possibility for me to get it back up there though. So, I’m hoping to kind of play catch up a little bit.
How about you? I think you had a similar goal of two days of exercise a week. How are you doing?
Rob [09:55]: Yep. I would say I am exactly on pace. There were weeks like when we went to Cancun in late January for seven days. And I exercised every day. So, I had seven straight days because you just have a lot more time and it was gorgeous there so it was easy to get out and run. And then I’ve had a few weeks where I don’t do anything – which is a bummer. I wanted to be more consistent like two days a week. But recently, when we moved here we have an elliptical. I ran track for nine years. I ran the hurdles and my right knee is a little messed up. So, when I run on asphalt it’s actually kind of hard. I can do it but I kind of pay the price for it. So, we have an elliptical which is like a glider so you don’t have the impact. And that was busted for a while. And then I finally figured out how to fix it within the last month. And since then I’ve been at least two days a week. Between two and three. I am currently feeling quite good about that. And, frankly, I kind of need it to work off the old winter weight. And just walking around and riding my bike to work and all that. I can tell it’s starting to take a toll on me. So, I want to definitely keep up the two days a week. And, hopefully, it should be warm here in the next month or so to be able to start riding to work again.
How about you on your next one?
Mike [11:07]: So, my second one was blogging publicly at least every two weeks. And that’s a complete fail at this point. I’ve blogged once and I should be at least four I think. Is that about right?
Rob [11:17]: No. Six.
Mike [11:17]: No. Six. I should be at six by the end of this month.
Rob [11:21]: So, to me this feels like a distraction. To me your number one goal should be Bluetick getting 25 customers, getting to launch, all that stuff.
Mike [11:30]: It is.
Rob [11:30]: I know that this is a nice to have but even when you said it in December, if you go listen to the episode, I was kind of like, “Why do you want to do this?” I get why but do you really want to do this? Is this something that you think you’re actually going to do or is this kind of a punt and it’s basically replaced with your third goal that you’re about to go into?
Mike [11:50]: I think you’re right. I think it should just kind of be replaced and – If I’m going to do any sort of blogging, it would be more content articles and things like that for Bluetick. It wouldn’t really be on my personal blog. So, there’s really not much point to me doing that stuff. Maybe it could lead to book sales or something like that but that’s really not like a major priority for me at this point. Really it’s the third thing on the list which was making Bluetick profitable and that’s sucking up almost all of my time at this point.
Rob [12:15]: Cool. And we might as well just do your last one now. What’s your third goal that’s probably going to take precedent over this one?
Mike [12:20]: Well that is that. It’s making Bluetick profitable. And I think that’s going in the right direction. If people are signing on and demos are going well, I’ve got to start putting together my launch sequences and going out to my email list. But one of the things that I’ve been much more focused on lately is getting the product to the point where people can kind of self-onboard and without having me to sit there and say this is what you need to do or walk them through it.
I had a meeting yesterday with somebody who I kind of brought on on a temporary basis as a UI and UX consultant. I walked him through an onboarding process and he looked at it and he said, “There’s very obvious ways for you to improve this.” So, he’s going to sit down and work out what the priorities of those things are because it’s kind of difficult for me to understand what those priorities are because I’ve been so close to it for too long so I really want that external opinion to say, “This is what doesn’t make sense. This is what is easy to understand without any additional explanation. And here’s how we can go about approaching and tackling those problems. And this is the order that they should be done in.”
Rob [13:19]: Very cool. So, my second goal was to have one to three new angel investments. I have done zero so far. But there is one company that is doing kind of follow on round and I think I’m going to put more money into them. Given the pace that I’m likely going to do these and that it is such a sidebar for me, I would kind of include that under the umbrella. If I do follow on rounds, I know there’s less due diligence and less work to be done. But I think putting more money to work in startups is my intent here. I would say I’m on track to do one here in the next month or so and then we’ll see what the rest of the year brings.
And then my third goal was to not start any new projects. Just to run the three MicroConfs we’re running; the two podcasts; continue driving Drip forward; and take a break from kind of the chaos of always starting new stuff. One exception to that was if Sherry decides to write a Zenfounder book that I would be second author on that. And so far, this year due to health issues in her extended family, she has not begun that. But I have hopes that in the latter half of the year that might get going. So, so far, on track for that as well. I mean, it’s kind of a nongoal. We discussed in December it’s to not take on any new ambitious stuff and just kind of let things settle.
So, I think that’s about it. Do you want to dive into what we’re chatting about today?
Mike [14:33]: Sure. So, today’s episode what we’re going to be doing is we’re going to go through, essentially, a prioritization framework to help deal with task overload. I’ve started using this framework. This is based on Anthony Eden’s blog post called ‘Aligning Projects with Business Goals.” We’ll link that up in the show notes.
Anthony is from DNSimple. He had sketched this out inside of our private founder café community a couple of months ago. But he’s refined it since then and he put out a blog post on it. In this blog post he talks about the fact that he’s running this large team and it’s got a bunch of different people and they were able to kind of keep track of all the different things that needed to happen and what they’re priorities were. But as the team grew and as different people’s responsibilities changed it became more difficult to prioritize things across the entire business. So, he essentially developed this framework to figure out, “What should we be working on? What’s the most important? What’s really going to drive the bottom line for the business and help it stay in business and make them grown?”
Some of the basic problems that you’re trying to really solve with a framework like this is the fact that there’s always more to do. If you look in any given bug tracker, for example, or any task management system. It feels to me like anything I’ve ever used, the number of tasks that are in there go up over time rather than down. You think about these burndown charts and those are great if you have a sprint where the number of task is defined for a particular time frame. And it’s going to go down. But in the background, there’s always new things that are being added. So, those things are just being added faster than you can clear them out. And it almost doesn’t matter the size of your team because as you add people there’s more that you want to accomplish and there’s bigger things. But some of those things are not worth doing. And this helps you prioritize those things and really help clearly see what is and isn’t worth doing.
Rob [16:12]: Yeah. I agree with you on the to do list. That’s there’s always more work to do. That’s where I think sprints can be helpful because they do give you a sense of actually accomplishing something. You kind of limit the scope; you go for two weeks or a week – however long your sprints are – and then when you’re done, you do cross this big thing off the list. And then you’re able to reprioritize and attack new ones.
I think the other thing that I do with both my to do lists and with our issue tracker in terms of Drip is we are pretty guarded. I guess me personally I am very guarded about what actually goes on that to do list. I don’t just throw everything I think of on there. If I’m just brainstorming and thinking of notes of like, “Yeah, maybe I should do that.” I put it in a notebook. Or I put it in a separate Trello board. Typically, it’s in a notebook, to be honest. Because unless, I revisit it – unless it comes up again – unless I stumble upon it when I kind of flip through my notebook every now and again. And if I see it again and I’m like, “That’s genius. I have to do it.” Then that goes on the to do list.
But I see peoples to do lists sometimes and I’ll ask them, “Why is that on there?” And it’s like, “Well, it was an idea I had.” And it’s like, “Well, then it’s not a ‘to do.’ It’s just an idea. Figure out a different place to put it.” And the same thing with feature requests. You don’t want customer feature requests. You’re getting five of them a day. You do not go into your issue tracker. That’s not the place for them unless they’re completely cordoned off. Because otherwise it just fills it up with all this noise and you’re just going to have hundreds and hundreds and then thousands of feature requests or ideas or whatever. And you really want to have them in their own repo. What should be in your issue tracker is stuff that is actually at least in the realm of possibility that it’s going to be built.
Mike [17:44]: It’s interesting you say that because I put customer requests in there and then I put the customer’s name as a tag on it and then, once it gets to what I look at as kind of a critical mass – like if I see enough people are asking for that particular thing – then I reprioritize it to say to, “Hey, this is something that we’re actually going to look at.” But there’s a lot of things in there that one person asked for. There was a question that came up it and it just kind of gets into this – I think we categorized it with a special category that just basically says that it’s a customer request that we’re probably not going to do anytime in the near future unless we get a lot more people asking for it.
Rob [18:15]: Yeah. That makes sense. Here’s where that may start to break down. As an example, Drip gets more than 100 feature requests a month from external people. And we get about 25 requests per month from internal. So, we literally get – no joke – 125, at least, feature requests per month. And how many of those can you build. Five, maybe. So, after six months you’re going to have 720 things and you don’t want those in your main issue tracker. You want them off. They can still be in the same repository but they should be off on a separate view that you’d never have to look through if you’re actually trying to – I shouldn’t say never have to look through. You don’t have to look through every time you’re trying to pull stuff up in the development queue. You do want to review this queue, obviously, every month or every three months and kind of look through because certain ones are just going to come up over and over.
I found that trying to keep absolute exact count of these things is not helpful. The ones that bubble up to the top are the ones that you just know it. Like gut feeling you hear the requests over and over or you know that it’s a really good idea and it’s something that a lot of people will use.
Mike [19:15]: Yeah. At my scale, I don’t have that problem yet.
Rob [19:19]: Totally. Yeah.
Mike [19:20]: Kind of more to the point here is like there’s never enough resources to do everything. And even as you add resources, it almost doesn’t matter because the things that you want to do, you’re still just not going to have enough resources to do them. And there’s always these little things that get added which somebodies got to look at it and evaluate it and, even if you decide to do it, it just gets added onto the list. So, you need a way to prioritize these things. That can be really challenging to identify what is the most important thing when there are so many things to get done. And even if you have this shorter list, it almost doesn’t matter if you split it up into these are the critical things and these are the noncritical things.
I remember seeing a Dilbert cartoon about that. It’s like here’s how to get everything done. Create two lists, put all your critical stuff on one list, create all your noncritical stuff on the other list. Do them both and if you don’t, you’re a loser. It’s not possible to do everything. So, having this framework allows you to establish some objectivity and remove your personal, mental perceptions of the situation about what is important and what’s really not because it removes your own biases towards certain things. Let’s say you just talked to a customer and they say, “Well this is a problem.” Your natural inclination is to weight that more importantly because of the fact that you literally just talked to that customer versus using a framework that allows you to create it as – to take a step back from that and objectively evaluate it.
Rob [20:38]: Yeah. This is hard. Especially as, basically, a product owner or a product manager. Even if you don’t call yourself that, if you’re the founder for the first while – definitely through product market fit and probably after – you’re going to be a point person, a key player involved in deciding what gets done. And there’s always 10 times more or 20 times more that needs to get done or that could get done then you can actually get done. It’s like the 100 feature requests but you can build five. So, that’s always going to be there. So, then you have to figure out what is it that actually needs to get done. And there’s a bunch of different approaches to this and what we’re talking about today, of course, is the framework that Anthony Eden laid out in his posts.
Mike [21:19]: So, let’s start digging into this framework a little bit. The idea of this framework is that you classify the different things that you’re doing based on different criteria. What this does is it gives you a basis for measurement that can be applied uniformly across all of the different tasks. There’s some things that he recommends – it’s really just a spreadsheet and you have the title and description of the things that you’re working on. Then you put in different factors.
The first one is effort. Effort is essentially a broad measurement of how difficult or how time consuming it’s going to be to implement that. With this framework, you can use it either on a feature by feature basis or on a project by project basis. You can have, basically, subtasks in there and add them up and say this project this project is more important than that one. Maybe you’d do some averages in there. I think that might be a little bit more difficult just because there’s 50 tasks for one project and only 10 tasks for another. It might be difficult to add them up as raw numbers but you can see between those two projects if one comes up with a score of 25 and the other one the highest task comes out with a score of 10, the one that’s 25 is clearly more important to do.
Again, going back to that first one, effort is something you would put in as a column. And this rated one through three. It’s small, medium or large. The thing I really like about this is that it removes timings and time estimates associated with it. Small, medium and large – you can look at that and ballpark any particular task. You don’t have to be good it either. That’s the best part. Because we’re terrible at doing really good estimates. If you say something’s going to take you two hours, it might take three, it might take four. Is that considered small, medium or large? I would probably say small because it’s not a lot of effort. Medium, to me, would be like a couple of days. Maybe a day or two. And then larger would be at least a week if not two or three.
What about you? How would you kind of classify small, medium and large?
Rob [23:07]: I really like his approach here. I think in the old days as a consultant we had to give quotes that were basically down to the hour. We would have to say, “This is going to take six hours to build that feature.” And you just don’t need to do that when you’re building a product like this. So, I like the idea of effort; one, two and three; and whether you make your small, medium and large match exactly what Anthony’s saying in this post. Or whether, given your time frames, those are different durations of time. I think it’s really nice to keep it simple so that you’re not – you don’t want to put in so much time in analysis that this becomes cumbersome. You’re taking your best guess at it and having a one, two or a three, it’s a five second decision. With almost all features you’re going to be able to slam it in the bucket pretty easily.
Mike [23:50]: The next one Anthony lays out is urgency. And this is essentially a raw estimate of the time sensitivity for something. This is rated between zero and two. Zero is no deadline; one is a deadline within the next six months; and, then, two is a deadline within the next three months. What I found a little bit odd about this was that the deadline within the next three months, there’s nothing there that says, “This needs to be done right now.” I think that that’s both helpful and not helpful at that same time. Because if you’re trying to onboard a customer and they need it right this second, then it kind of puts a cap on how much the urgency impacts the total score. And we’ll get through the other three factors here but, once you go through these, there’s a calculation that you put on these based on the numbers that you assign and that comes out to a score for this particular task. It makes it easy to relate it to the other tasks.
Do you think it’s important to have a score in there for urgency with a deadline that’s less than three months?
Rob [24:43]: I do. So, here’s the thing. It depends on what time horizons you look out at. I think in your early days like where Bluetick is, I think you should probably have no deadline, two months and one month. Or no deadline, one month and two weeks. Because your timelines are so much more critical. Because you need to move way faster right now to try to get to product market fit as soon as possible. I think as a product matures and the team grows this could feasibly get longer. Even now with Drip, I’m thinking and looking ahead six months, nine months, but I’m not actually planning. I just have ideas of what we’re going to build. So, to me the zero, three and six month is a little too broad for us. I would probably, for us, have zero, one and two or zero, one and three months.
We typically plan fairly tight. We plan about 60 to 90 days out because I find that so much changes by the time you get there. New priorities come up, new feature ideas come up, competitors do things. And you have performance issues that suddenly you need to turn your head and try to scale. So, there’s a lot that can change in 90 days in the life of a startup so I would just compress this. But the gestalt of what he’s saying here is still the same.
Mike [25:54]: Yeah. And that’s something else to kind of point to as a side note. Even though some of these things are written down in such a way that there are those raw numbers of like six months and three months, feel free to change those things. Make whatever the framework you use fit into what it is that you’re actually doing because Anthony’s business is much further along than Bluetick, for example. Not everything that he has in here is going to directly apply to what I’m doing. That doesn’t mean that you can’t make some changes or modifications that will help if fit your situation better. So, if you look at it and it doesn’t quite fit what you’re doing, feel free to make those changes. Especially if it’s going to fit what you’re doing.
The third criteria in here is the impact. And what the impact is that it’s a value that indicates the potential impact on profitability. And this is rated anywhere from negative two to positive two. And negative two is a significant negative impact; zero is little to no impact; and, then, two is a significant impact. I really like this because there are some things that you are going to do which will probably have a negative impact on your profitability. They may make things worse for you. And then there’s other things where, if you do that – let’s say you make a pricing change and you increase prices – that could have a huge impact. And it’s just when you start adding those things, it allows this to adjust the priority up or down based on what those numbers come out to.
Rob [27:07]: Yeah. You know what I like about this? Often times when we’re talking about what features to build, I will ask whoever we’re talking to – typically it’s Derek or someone else on the team – and I’ll say, “Will this help us retain more customers,” – meaning keep them from cancelling – “Or will this get us new customers?” In essence, is it a marketable thing that new people will sign up for? And that’s what Anthony’s encapsulating with this impact score. And I like how simple it is and I like that it combines all of that into a single number.
Mike [27:36]: The fourth one is a risk factor. This is an indication of what is going to happen if this is not implemented. This is a very simple rating: zero to two which zero is little to no risk; one is some risk; and two is a significant risk. This risk factor could be a bunch of different things. For example, if there’s paperwork that you need to file with the government, then if you don’t do it then you could go out of business. Especially if it’s like a lawsuit that you have to respond to. And then there’s other things where it’s a feature that somebody had asked for. Is it really going to make a huge a difference to you if you don’t put hover text over a button, for example? Probably not. Does it help the application? Does it make the user experience better? Yes, but is it risky to not do it. And the answer, in that case, is obviously no.
Rob [28:21]: Yeah. I also think of stuff like scaling. There’s a risk factor of, “Do we need to upgrade the database server? Do we need to optimize the piece of code to make it five times faster?” And it’s like maybe all the other ones before are like the impact will be really kind of zero. Like it’s no impact to customers. The urgency, well, it could be the next three months but as soon as you introduce a risk factor of, “If we don’t do this, we risk slowing down. We risk performance issues. We risk upsetting people.” I think that’s a nice piece that this captures.
Mike [28:53]: Or you risk some sort of security setting. It’s like, “Hey. We need to make some sort of a structural change in the database and if we don’t do this, then there’s a risk that customer data could leak from one customer into another.” So, that’s another way that risk can kind of fall into it.
The last one that he has here is innovation. This is an indicator of what type of influence that the task has on your long-term growth. This is rated from zero to two. Zero is little to none; one is ahead of the curve; and, then, a two is groundbreaking. I’ll be honest. I wasn’t real fond of the term innovation, so – I forget what put it on my spreadsheet – but I had changed that to say how is this going to impact long term growth. I think that’s actually what I called it was long term growth opportunity. This is very nice to be able to relate that back and say, “This is not going to make any difference or it’s going to make a huge difference.” And I think you can also consider this in relation to what your competitors are doing and what your long-term vision for the product looks like. If this is going to open up new doors for you to go into a completely new market, then that would be either a one or two. But if it doesn’t do any of that, then it’s probably a zero.
Rob [30:02]: Yeah. I think a lot of things would be a zero. Kind of day to day of I need to add these settings. I need to add this screen. You think about merging subscribers in Drip, like we talked about earlier. Is that really innovative? To be honest, it is one. It’s ahead of the curve because most apps don’t have it. But it’s not groundbreaking. Like when workflows or something like that really jumped us ahead. So, I can see where this applies.
I don’t necessarily think of it in terms of innovation. I typically think of it in terms of impact. Once we get down and see the multipliers, I want to see how innovation plays against impact because I could see removing innovation altogether because most of the time I don’t want to innovate unless it has a major impact. Does that make sense?
Mike [30:42]: It does. But remember, the third one on this list was impact. So, that’s why I went through and started changing some of these names.
Rob [30:48]: Right. I was going to say; I’m only going to build an innovative thing if the impact is high. So, I’m not sure why I also need to say it’s innovative. Because the impact is going to be high and the innovation is going to be high. It’s almost like, to me, innovation tracks with impact. If all these go together in the same direction, they’re correlated, then there’s no reason to have them. You should just have one number. The only reason that you should have all five of these is if they go in different directions based on what you’re building. That’s what I’m still trying to get my head around is how impact and innovation, I think, are different.
Mike [31:16]: And that’s why I said that I played around with the terms when I put them in my spreadsheet because the difference between impact and innovation was not very clear. I changed impact to say short term profitability impact. And then innovation was long term growth impact.
Rob [31:32]: Oh, nice. Okay. That’s cool. I like that actually.
Mike [31:35]: Yeah. It separates out, “Hey. You need to do this.” And it’s more of the profitability impact is like, “What’s the direct result that’s going to be short term for us in terms of financials?” And then the long-term growth, “What is this going to look like for us six months, 12 months down the road?” We may do something that doesn’t really change anything now but what would be the impact of that in 12 months? And it it’s something small in the UI, very little innovation associated with it. But something like with Drip – workflows – it’s probably going to have a small impact now but 12 months down the road, 18 months down the road, it’s huge because it gives you so many more things to do.
Rob [32:14]: So now that we have a spreadsheet, you put down all of your scores for all of your different feature ideas or even if they’re not features. It’s just development ticket ideas basically. How do we score these things?
Mike [32:26]: The calculation that he has is you take each of these things and you multiply them by different numbers and you add or subtract them based on what they are. So, the impact and urgency you multiply each of them by three and add it to get the score. The risk factor you multiply by four. And then the innovation you multiply by two. You add those numbers together and then you subtract the effort times three. The larger something is – and remember that effort can either be one, two or three so you’re going to be subtracting either three, six or nine from your final score.
So, something might be very risky if you don’t do it now and it could have a huge impact. But if the effort is large, it could really reduce the score associated with that. I went through this a couple of months ago when Anthony had first posted this in Founder Café was that there were things that I felt were much more important and then looking at the score that came out of it – which he calls priority but I like to call it score just because it’s a numerical calculation – it’s very easy to look at those scores and just sort by that score and see relative to each thing what is really important to the business and what’s not. And I found there were things that rated up there as like 15 or 17 and then there were things that I thought were more important and they only rated like nine or 10.
I feel like there was a dividing line between things that were less than a score of 10 and things that were more. Those things that were more than 10 really felt like they were truly important.
Rob [33:48]: Yeah. I think this can be a really nice kind of guide to help you not just make gut feeling decisions and – I don’t know that I would go directly down these in priority order and build in that order – but I think it can give you a really nice framework or guide as the best way. Maybe if something was a five, I might make it more than a seven or a higher priority than a seven because I know of somethings maybe not captured in just these numbers or in the multipliers or whatever. But, that aside, as you look through these it seems like all the bases are covered and, if you put accurate numbers in each of these and you multiply out the score, I think there’s a lot of value in doing that.
Mike [34:25]: Yeah. I actually thought about that because I was looking at the things that scored lower than I thought they should. And I really tried to go back through the different columns and say, “Is this score justified? Should this be more urgent? Should it have a larger impact?” And I could make some variances here and there. But realistically, when I started looking at everything together and scoring them in the same way, I really couldn’t forcibly take that score any higher. And it’s not to say that you can’t prioritize starting something in advance because, obviously, if something is a large-scale project that’s going to take you three or four months to complete, you have to remember it’s going to take three or four months to complete and you may have to start it now in parallel to you doing other things. But you’re not going to be able to start it today and be finished with it tomorrow. That’s just not going to happen. So, you do have to take that into account when planning. But I think that it does help you in terms of deciding objectively what you should start planning to do versus the things that fall much lower on the list that just aren’t as important as you thought they were and maybe you put them on the list and assign them to somebody and they actually don’t need to be done.
Rob [35:30]: Yeah. I think this could be helpful definitely for when you’re getting started as kind of product owner. If you just have so much stuff on your plate that it’s hard to decide and you kind of need a guide. I really think that there’s some value here.
So, if you want to dig into that a little more, we will link that up in that show notes. It’s on blog.dnsimple.com. And thanks to Anthony Eden for sharing that with the Founder Café community and now the Startups for the Rest of Us community.
If you have a question for us, call our voicemail number 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Outta Control” by MoOt. It’s used under creative comments. Subscribe to us in iTunes by searching for “startups” and visit startupsfortherestofus.com for a full transcript of each episode.
Thanks for listening and we’ll see you next time.
Thanks a lot for the shoutout guys!
Mike, Rob,
Thanks for the in depth review of my post and the framework. I was stoked to see it show up in the podcast, you’ve made my day! 🙂
I hope others find it as useful as I have.