On the Dangers of Prioritization
So you're running your little software startup, and things are going great. You've got some really happy users who are finding bugs and suggesting new ideas, and more customers are starting to come on board. You've hired some folks to help keep things moving along, and they're excited to help out. You're still stressed out of your mind, but at least there are other people now to help share the load.
When it comes to developing your product, you've got a pretty good idea of what needs to be built when because you're basically talking to every customer and employee on a regular basis. There's a file somewhere that you half-heartedly maintain and call "the roadmap", but if someone asked you "what should we work on next?" there's a 50% chance your response wouldn't be anywhere on that document, things are moving too quickly.
At some point people start talking about your brain as a single point of failure, and you realize they're right. So you use your bug tracker to document new features, and everyone feels a little better knowing as least the general ideas are written down somewhere. You all agree that this is progress, and part of growing into an actual organization.
What happens next could come from a couple different places. Your sales or support groups start wanting to know when new features are coming. They're probably not so much concerned about specific dates as they are a general order of priority. Or your development group wants to start doing research leading up to the development of new features. Or your customers want to inject their perspective into your timeline. Or one of your early hires thinks you're not giving enough attention to the cool new thing you talked about six months ago. However it happens -- and it will happen because it's a healthy part of your company's growth -- the main point is that someone, somewhere, pressures you to create an ordered, prioritized list of things you will build or fix.
There are all sorts of legitimate concerns with roadmaps, from time commitments to public visibility to levels of granularity, and I'm not talking about those concerns right now. I'm talking about the danger of development prioritization. And specifically, prioritization by algorithm or committee.
Don't misunderstand me, priorities are important and valuable. Someone (probably multiple someones) will sit down and label all your bugs and features with tags like "on fire", "must have", "nice to have", "affects everyone", "customer-specific", etc. Then you're going to say, "clearly we need to start with the emergencies affecting everyone, work through the must-haves, and eventually get to the nice-to-haves." It'll be a huge relief knowing that you've defined a heuristic that others can use to make informed decisions, and that you're no longer the blocker on all development everywhere. Plus, it'll sound perfectly rational to prioritize work based on the number of users affected and the degree of impact it will have on affected users.
It'll also be wrong.
Okay, not wrong, but definitely insufficient. Once you give up control of development to that algorithm or committee, you lose something significant. One of the most important characteristics of a founder is that they have the freedom to build something that few if any other people think is important enough to build. And guess what? You just gave that up without even realizing it. Or maybe you did realize it, but you just don't see how there could be any alternative. Obviously you making all the decisions by the seat of your pants won't scale, and you don't really trust anyone else enough to pass that liberty on unrestricted. What else were you supposed to do?
Well, if you think your product has a sufficient level of disruption already baked in, then I guess you're good to go. If not then you've got a problem. Not only will bugs keep creeping in to (rightly) steal priority, but so will deal-breaking features and incremental enhancements. How can you justify wasting time on a moonshot-maybe when you have concrete evidence that the standard features you're missing are a serious customer acquisition impediment or opportunity? Moonshots don't survive prioritization algorithms.
You can argue that you've got a sufficiently innovative team, and everyone will see and recognize the value of innovation. But the ROI on innovation is hard to quantify, and it's inherently higher-risk, which a growing company is (justifiably) getting less and less excited about. I've seen lots of dev priority lists in lots of different styles, and the only time I've seen them not have this problem is when they were the hazy unmaintainable kind owned by a single individual.
There's also a deeper problem. Once you have development priorities, who exactly is going to be out there looking for the innovations? When there was just you, 100% of the company was searching for magic, in a way rather aimlessly. The first couple hires were still after it, but gradually the percentage of energy being put into outside-the-lines ideas will shrink. And the smaller it gets, the more work it is to maintain culturally against the increasingly structured to-do list. You can flex your founder muscles and force some ideas through, but as time goes on that will feel more and more against the grain. Without intervention, at some point you may lift your head and realize you're thinking about this stuff completely differently than the rest of the company.
So what are you supposed to do? This is why 20% time has such a great appeal. Or a separate dev team that works on crazy prototypes. Or the hackathons where developers can spend a couple days on whatever they want. Or a founder that people just leave alone to work on whatever they want. Those are examples of people saying, "our system is flawed but it's not clear how to fix it, so let's just set aside some bandwidth outside of our broken system to try to compensate for its flaws."
And guess what? That's the best I've seen, anyway. We've tried all of those things in one form or another at Instructure, and they've each made their own dent. But if there's a silver bullet for the prioritization-innovation conflict I'd love to hear about it (other than keeping the company small, but that limits your bandwidth for other reasons). Maybe innovation-squashing is just an innate characteristic of prioritization.
The fact is, I don't think truly innovative ideas are the kind that show up on a roadmap. In my experience they've come out of left field when you're working on really important other-stuff, so there's a huge risk of them being brushed off. It's not the kinds of things you find by hunkering down and singularly looking for the next big thing. By the time they show up on a roadmap they probably seem obvious, but they'll never get that way on their own. They start out as little sparks that need some oxygen to become a flame, and then to be identified for what they are and given some attention and kindling to grow. And that just doesn't happen when everyone is busy working on the day-to-day.
You have to figure out a way (that works for your company, because I'm betting it will be unique to your company) to repeatedly jostle your employees out of their routine enough so they think differently, and also feel a desire to bring up their ideas (on-boarding indoctrination is one trick we've used to help calibrate there). Once a quarter won't cut it, it has to be a repeatable thing because it often takes a couple strikes to get lit -- but not too repeatable or it just becomes fake or part of the routine. And it shouldn't be just for developers, ideas come from anyone connected enough to pick up a trend. Then you need product-oriented people who explore these sessions and pull the separate-but-related sparks into the start of a bonfire.
It's not a trivial thing I'm talking about, but it's a big part of why large companies stop innovating, innovation just doesn't get the legitimate air-time it requires. I'm not convinced that scheduling weekly "out-of-the-box time" is the right approach, but I haven't actually seen many other strategies in the wild. I have this hazy vision of monthly "off-kilter pitches" that get approved as incubation projects, but it's not concrete and I've never tried it, so I can't endorse it. You're essentially looking to give everyone both time *and* empowerment, to get the percent of employees working on innovation back up as high as you can get it. So whatever way works best for you. I think that's possible without losing the value of your prioritization, but I also think prioritization will eclipse innovation if you're not actively avoiding that outcome.
 |
| Prioritization is hard. |
At some point people start talking about your brain as a single point of failure, and you realize they're right. So you use your bug tracker to document new features, and everyone feels a little better knowing as least the general ideas are written down somewhere. You all agree that this is progress, and part of growing into an actual organization.
What happens next could come from a couple different places. Your sales or support groups start wanting to know when new features are coming. They're probably not so much concerned about specific dates as they are a general order of priority. Or your development group wants to start doing research leading up to the development of new features. Or your customers want to inject their perspective into your timeline. Or one of your early hires thinks you're not giving enough attention to the cool new thing you talked about six months ago. However it happens -- and it will happen because it's a healthy part of your company's growth -- the main point is that someone, somewhere, pressures you to create an ordered, prioritized list of things you will build or fix.
There are all sorts of legitimate concerns with roadmaps, from time commitments to public visibility to levels of granularity, and I'm not talking about those concerns right now. I'm talking about the danger of development prioritization. And specifically, prioritization by algorithm or committee.
Don't misunderstand me, priorities are important and valuable. Someone (probably multiple someones) will sit down and label all your bugs and features with tags like "on fire", "must have", "nice to have", "affects everyone", "customer-specific", etc. Then you're going to say, "clearly we need to start with the emergencies affecting everyone, work through the must-haves, and eventually get to the nice-to-haves." It'll be a huge relief knowing that you've defined a heuristic that others can use to make informed decisions, and that you're no longer the blocker on all development everywhere. Plus, it'll sound perfectly rational to prioritize work based on the number of users affected and the degree of impact it will have on affected users.
It'll also be wrong.
Okay, not wrong, but definitely insufficient. Once you give up control of development to that algorithm or committee, you lose something significant. One of the most important characteristics of a founder is that they have the freedom to build something that few if any other people think is important enough to build. And guess what? You just gave that up without even realizing it. Or maybe you did realize it, but you just don't see how there could be any alternative. Obviously you making all the decisions by the seat of your pants won't scale, and you don't really trust anyone else enough to pass that liberty on unrestricted. What else were you supposed to do?
Well, if you think your product has a sufficient level of disruption already baked in, then I guess you're good to go. If not then you've got a problem. Not only will bugs keep creeping in to (rightly) steal priority, but so will deal-breaking features and incremental enhancements. How can you justify wasting time on a moonshot-maybe when you have concrete evidence that the standard features you're missing are a serious customer acquisition impediment or opportunity? Moonshots don't survive prioritization algorithms.
You can argue that you've got a sufficiently innovative team, and everyone will see and recognize the value of innovation. But the ROI on innovation is hard to quantify, and it's inherently higher-risk, which a growing company is (justifiably) getting less and less excited about. I've seen lots of dev priority lists in lots of different styles, and the only time I've seen them not have this problem is when they were the hazy unmaintainable kind owned by a single individual.
 |
| George Bailey makes it look so easy. |
So what are you supposed to do? This is why 20% time has such a great appeal. Or a separate dev team that works on crazy prototypes. Or the hackathons where developers can spend a couple days on whatever they want. Or a founder that people just leave alone to work on whatever they want. Those are examples of people saying, "our system is flawed but it's not clear how to fix it, so let's just set aside some bandwidth outside of our broken system to try to compensate for its flaws."
And guess what? That's the best I've seen, anyway. We've tried all of those things in one form or another at Instructure, and they've each made their own dent. But if there's a silver bullet for the prioritization-innovation conflict I'd love to hear about it (other than keeping the company small, but that limits your bandwidth for other reasons). Maybe innovation-squashing is just an innate characteristic of prioritization.
The fact is, I don't think truly innovative ideas are the kind that show up on a roadmap. In my experience they've come out of left field when you're working on really important other-stuff, so there's a huge risk of them being brushed off. It's not the kinds of things you find by hunkering down and singularly looking for the next big thing. By the time they show up on a roadmap they probably seem obvious, but they'll never get that way on their own. They start out as little sparks that need some oxygen to become a flame, and then to be identified for what they are and given some attention and kindling to grow. And that just doesn't happen when everyone is busy working on the day-to-day.
You have to figure out a way (that works for your company, because I'm betting it will be unique to your company) to repeatedly jostle your employees out of their routine enough so they think differently, and also feel a desire to bring up their ideas (on-boarding indoctrination is one trick we've used to help calibrate there). Once a quarter won't cut it, it has to be a repeatable thing because it often takes a couple strikes to get lit -- but not too repeatable or it just becomes fake or part of the routine. And it shouldn't be just for developers, ideas come from anyone connected enough to pick up a trend. Then you need product-oriented people who explore these sessions and pull the separate-but-related sparks into the start of a bonfire.
It's not a trivial thing I'm talking about, but it's a big part of why large companies stop innovating, innovation just doesn't get the legitimate air-time it requires. I'm not convinced that scheduling weekly "out-of-the-box time" is the right approach, but I haven't actually seen many other strategies in the wild. I have this hazy vision of monthly "off-kilter pitches" that get approved as incubation projects, but it's not concrete and I've never tried it, so I can't endorse it. You're essentially looking to give everyone both time *and* empowerment, to get the percent of employees working on innovation back up as high as you can get it. So whatever way works best for you. I think that's possible without losing the value of your prioritization, but I also think prioritization will eclipse innovation if you're not actively avoiding that outcome.
Comments