Show Notes
In this episode, Tyler seeks Rick’s advice on how to plan the
Less Annoying CRM product roadmap for the upcoming year. Here are some of the takeaways:
- Product roadmap planning is easier when you are able to align to clear company goals and constraints. In this context:
- Goals = what you really want to accomplish during a time frame. E.g.:
- “Increase signups from word of mouth”
- Constraints = the things you aren’t willing to ignore / don’t want to drop while you’re pursuing your goals. E.g.:
- “Spend 10% of development hours paying down technical debt”
- Take time to make sure employees are bought in to the company goals and constraints prior to planning the product roadmap.
- One way to do this is to include employees in the prioritization and trade-off process.
- Company leaders often go through a number of change cycles and trade-off decisions when setting company goals.
- If you can allow employees to have a voice in these trade off decisions, they are much more likely to buy in to your prioritization decisions
- When you get to product roadmap planning, allocate resources based on your company goals and constraints.
- Once you’ve addressed your constraints, ideally you can put all of your remaining resources toward the company goal(s).
- Common (non-outcome-based) allocation buckets include:
- New feature development
- Improvement to existing features
- Bug fixes
- Paying down technical debt
- (Note: if you can logically bucket roadmap items into specific business outcomes tied to your company goals and constraints, do it)
- It's nice to think, "What's our top priority? We're only going to work on that." But, even at a one-person company, this is likely unrealistic.
- You lose momentum if you ignore parts of the business and this could get you in trouble.
- Setting constraints on goals is one way to address this problem.
What else would you add to this list?
Context
Tyler: What we're going to talk about is basically the... Like any company, there's a lot of different things I want to work on next. We're finally at the point where we have multiple developers so we can do multiple things at once, which is not really something I've been faced with much in the past, and I'm trying to figure out how to prioritize different categories of things. One category is building totally new features. That's the sexy, fun-to-announce type of thing, like, "Here's something the software can do that it couldn't do before," versus improving existing features in a way that customers care about versus improving features in a way that customers won't even notice, but the idea of paying off technical debt or something like that, so, a bit of context here, we're finishing up this redesign, and, in a couple months, we're going to have all four developers plus myself moving on to other things, and basically, while we've been doing this redesign, which took almost all year, we've cut a lot of corners. The goal is to get it done as quickly as possible. There's a lot of stuff we want to go back and fix. This is normally referred to as technical debt. We have a lot of ideas for just minor tweaks to our current products that our customers would love, little one-week, two-week things, but we could do it for a year and not run out of ideas there, and they're just slam dunks, makes the product better, and then there's the go-out-and-really-do-something-new that our product doesn't currently do and maybe have a bigger splash, but it's a little more risky, so, yeah, I'm interested in basically just, A, figuring out what should I be doing, but, B, coming up with a framework for how I should think about this in the future.
Rick: Yeah. What timeframe are you thinking about? Is it over the full course of 2020 starting in January? Is it next month for a couple of months? What are you thinking?
Tyler: Probably, I think, the next six months. January through June, July would probably be a good... planning the most immediate next things, and then I'd like that the framework I was talking about can inform once... In April or May, when we start planning the next six months, I'd like to be able to apply that framework again.
Rick: Makes sense. How have you gone about this in the past?
Tyler: I just haven't. Partially, I've been very undisciplined about it. It's gone fine. It hasn't been a problem exactly, but, normally, there's just an obvious next thing. Having said that, it's not clear that the obvious next thing is actually the right next thing, but, in the moment, it's like what piece of software, what piece of our product is clearly the worst thing, that's normally what's going to get the most attention.
Rick: It sounds like you want to add some discipline to your planning process and then you also, it sounds like, have some capacity to do more than one thing and in terms of you have more developers that are fully up to speed and capable that you can put on different things and get more done.
Tyler: Yeah, absolutely, and so one of the reasons I say I've never had a system for this, we haven't launched a totally new, little features, but like a new major thing in maybe since 2014 or something like that. The last several big projects we've done, we're just redoing things we already had, so we redid the calendar, we redid custom fields, we did a redesign, so, yeah, it's weird having the resources and say, "Should we actually start adding to the functionality?"
What are the company goals?
Rick: This was a big challenge for me. I went through a similar transition from Zane Benefits to
PeopleKeep. At Zane Benefits, it was very much a... I was the dictator of what got done on a monthly to quarterly basis, and there wasn't this engaged planning process that we thought about things over a long period of time. When I got money to fund PeopleKeep and hired a new CTO for that, he brought a whole nother mentality around roadmap planning and thinking through, and the... one thing that was really hard for him to do a good roadmap on... the situation that made it very hard for him to do a roadmap on was a situation in which I hadn't clarified the company goals for the year, so, I guess, what the... where I would start with this is what are the... If we look at the timeframe for a year from a company perspective, at the end of 2020, when you're looking back, what are the things you want to have accomplished and how will you have measured that? That should drive the first six months of the product roadmap.
Tyler: Yeah, so, if I only get to answer one goal, I want 2020 to be the year of the referral. I want it to be word of mouth. We talked about this in a podcast, I don't know, a month ago about how I was thinking, and I had some questions around referrals and word of mouth. From a business standpoint, I want to make that better, but I also think products can have a big role in there. Now, having said that, I've been making a fair number of implicit or explicit promises to the dev team about it's okay to cut this corner, we'll come back and clean that up later, so I have other concerns beyond just this one big goal, but that's the biggest thing.
Rick: Yeah, and are you sure referrals are the right way and it's not one level up like increase leads or sales?
Tyler: I'm pretty sure. I mean, I'd take it any way possible, but we have talked a fair amount about how do we... what do we think the most realistic and sustainable way to do that is, and we think it's referrals.
Rick: Okay. One way to think about goals, and I know this isn't the topic of the podcast, is at the company level, leave yourself a lot of room for trial and error and just say, "Hey, we want to see an increase in signups or the rate signups is growing," or something like that, and then you start getting into your roadmapping on the product side and, "Okay, that's one of our goals for the year is to increase signups. What are some different things we can do that?" and then, on the roadmap, you prioritize a referral program as your first effort, but then you leave yourself on the roadmap, independent of your company goals, some room to try something, to learn and then switch course without having to change your company goal.
Tyler: Yeah. Maybe referrals is too specific, but I want it to be more specific than just increasing sales, so I think word of mouth... Maybe referrals is a subset of word of mouth, I guess, depending on how you define these terms. Word of mouth is what we want, and let me explain why. Last time I brought a topic, so two weeks ago, we talked about pricing, and because of that episode, and I kind of referenced this during my update last week, we've been talking more and more about why do we need to do the pricing increase and all that, and the big reason is I think the business model at our current price and... Sorry. I said price increase. That's oversimplifying adding an extra tier or something like that. Our business would work great at $10 a month if we can get organic word of mouth growth up to the point where it's netting out a churn giving us 15% growth a year, let's say. If it's less than that, probably, our business model at $10, it's not going to fail, but we need to look at pricing more seriously. Sorry. I'm not articulating this well, but if we went out and increased sales from, say, Google AdWords or some specific sales channel, that would not scale with the business, and it wouldn't alleviate any of my concerns about the actual economics of the business itself. Word of mouth growth would give us the information we need to make that pricing decision before the end of the year.
Rick: In other words, you have to figure out a multiplier of one customer, one plus... one customer equals one point, some multiple of that customer, and if you can't figure that out, then you've got to to solve the plateau problem of your business some other way, whether it's a price increase on existing product or adding new products, that sort of thing.
Tyler: That's exactly right, so, yeah, the plateau thing, and it's not so much that I need the growth next year, it's that I want to know the answer to, "Is that growth there or do we need to figure something else out?"
Rick: Is this product that we have right now tapped out or not? The way you're going to know that is if you can create a one-plus-one-equals-three or one-plus-one-equals-two-plus type scenario.
Tyler: Exactly.
Rick: I totally get it, so some sort of multiplication formula of customers. I want to be clear, because a couple of weeks ago we talked about adding a second product, is this... is adding a second... Have you decided adding a second product and, thus, increasing unit economics is secondary to this?
Tyler: Yeah, so this is a huge decision which I feel really good about. I hinted at this in my update last week. Not that we will never think about a second pricing tier or whatever else, but what we decided is we're not going to mix these two decisions together if can we juice word of mouth enough to get to a point where we're happy and do we need to increase prices. What we're going to do is we're going to punt on that. Say, probably around the end of next year, hopefully we can make a decision on if we even need to think about pricing, but, first, we want to give it a good effort at the $10 to make it work, so that's what we're focusing on right now.
Rick: Good. Man, kudos. That is such a disciplined decision that I think, given me being in the same situation as you, I would not be able to make. I've constantly over spread too thin our... my development resources and my company resources on competing goals, and I love it. I think it's brilliant, and if you figure it out earlier, you can always move up the timeline on the pricing question and/or adding additional products, so I think it's brilliant, so 2020 is the year of figuring... learning whether you've tapped out your CRM product, the market of your CRM product, and, if so, expanding it and, if not, moving on to the next thing. I love it.
Tyler: Absolutely, and let me just caveat this, because I don't know if any of my customers listen to this. There's absolutely no consideration of the product is tapped out, let's radically pivot or anything like that. It's just do we want to add something else on or do we want to stay 100% on this one product?
Rick: Is it worth investing additional functionality and features into the existing product above and beyond what the customers need to stay there or not? That is the question.
Tyler: Yeah. Exactly.
Should your product roadmap 100% on company goals?
Rick: That's really clear. I guess, is there any reason that you would have a roadmap? Why not just make the roadmap 100% focused on that outcome?
Tyler: I'll admit, a part of me is tempted to do that in particular, so let me explain. The product improvements that really relate to word of mouth growth in my opinion are bringing, building products that make our customers want to reach out to their customers via our software, so, when we talk about an appointment scheduling product, invoicing would do this. Web forms would do this. It would bring a lot of value. Our customers would love to have these features, but the key for us is they'd be sending links to their customers. When their customer links, clicks that link, they'd get taken to lessannoyingcrm.com. That's really the category of improvement we're talking about here, I think. Why don't we do 100%? Only that it's probably almost entirely... I have two reasons. One is, like I said, I've made promises to people internally that we're going to clean up a lot of the shortcuts we made, and you've dealt with this before, right? If you accumulate too much technical debt, it can become a problem, and it's never the right time to pay off technical debt.
Rick: Yeah. As a nontechnical person, I could probably explain technical debt from a business standpoint for you non-technical people out there like me, so, basically, think of it as when you're in a working... you're really focused and you're getting something done for a specific task and you're... and stuff just starts piling up on your desk all around you, and it doesn't matter right now because you're focused on this one task, but the minute you finish your existing task and you have to go figure out your next task and you've got all this shit all over your desk and you can't find things and there's stuff in your way, that's technical debt for an engineer, and it's basically stuff that accumulates in the code base that gets in the way of producing new features or fixing existing bugs. It just makes writing code harder and progressing the code base harder. That's the best way to explain it, and rarely for the business from a CEO standpoint, from a salesperson standpoint, from a customer standpoint does it make sense in the near term or... Do you receive any benefit as a customer in the near term of technical debt prioritization? Typically, it's a long-term play to allow future development, so it's very... I takes a lot of discipline to prioritize paying it down, and it's basically like taking on credit card debt that you never pay off. You either have a kind of approach of you don't ever let it accumulate for more than a period of time and you pay it down or you have a set balance that accumulates and you say, "Hey, we're not going to go above this threshold," but it takes discipline. I guess, that's the background. Would you add anything to that on technical debt?
Tyler: I think that's a great explanation, which I'm going to steal from now on, but let me give a... to make it a little more specific here, just one version of it we're dealing with, so, back in the day, we wrote our code in normal PHP, which is a pretty standard Web programming language. Then we updated to React and we ported like three quarters of our code base over to React and it's there, but then a new version of React came out and ported like 75% of our React code to that, and then we moved a lot of our code to TypeScript, so we have four different versions of our code right now, and this causes two problems. First of all, now, some new version is going to come out, and we can't update to the new thing until we have everything at least caught up to the last version. Secondly, every time we hire a new person like an intern or something like that, onboarding them and teaching them the code base, they're learning four systems instead of one, and it really, really slows down the velocity of ramping up a new person, so, yeah, it provides no value to the customer in the short term, but it really does slow stuff down if we never pay it off.
How to prioritize paying down technical debt
Rick: How have you approached technical debt in the past from a time allotment standpoint?
Tyler: The thing we've tried is we have what we call dev chores. We haven't been disciplined about actually doing this, but the idea is every developer should spend three weeks a year doing dev chores, and we have a list of what that could be. Each person has their own interests and what they want to work on, but the idea is that that would at least keep us from getting worse than we are now, but maybe not ever fully pay it off. The thing is, during this redesign, we totally suspended dev chores, and so we're behind now.
Rick: Oh, got it. Got it. So you basically have made a decision recently over a period of time to accumulate technical debt without paying any of it down.
Tyler: Mm-hmm (affirmative).
Rick: And now you're in a situation where you've got, engineers are getting a little crabby with you, you're probably feeling a little guilty about it. You know that for the long term you need to focus on this. But the question is how and when do you turn your attention to it?
Tyler: Yeah.
Rick: The best advice I ever got about this was from Ben at
Lucid and he basically said, "Listen, you always just dedicate a percentage of time in a given period to technical debt, and you ramp it up and down based on how important it is." So you never don't do technical debt. It's just a question of what percentage of time. It sounds like you have that mentality. I would ask you, I mean, what's best for the business? Should you be paying 10% down? Well, I think I agree that you should be paying some amount of technical debt down. And I think you do too. So we don't probably need to talk about that, but how much is the question?
Tyler: Right. And yeah, a part of me, I can see both sides of this. A part of me thinks, Less Annoying CRM is a unique business in that we don't have any investor pressure. We're willing to move slow and be patient. A part of me thinks we should be the rare company that basically doesn't have any. I mean you can never not have any, but if we have technical debt that everyone agrees we're going to have to do this at some point, let's just do it. Let's eat our vegetables. A part of me thinks that and another part of me thinks it hasn't really caused a problem thus far, exactly. Let's just keep accumulating, let's keep putting stuff on the credit card.
Rick: Yeah, it feels to me like you have a critical market and product question to answer right now that trumps technical debt in a big way. Honestly, at the end of the day, if you answer this question... Let's just play if, what if, for a second. If the what if after the six months of focusing on creating the multiplying effect, the word of mouth effect, does it pay off? And you come to the conclusion, "Hey, this is the product, this is the market. We're going to have to play with pricing or play with product, new products in order to grow this business." Technical debt, that's when you prioritize technical debt to add scale to what you're currently doing. It's almost like you should be doing, I mean it seems like you have a very clear question to answer that basically makes it so the code base is going to get pretty, for that product in particular, is going to get pretty, either important for future growth, or stable in terms of a recurring revenue stream. And that's going to tell you a lot more about how you should prioritize technical debt than not knowing the answer to the question.
Tyler: I agree. Except the problem is, let's just walk through a hypothetical scenario here. We build appointment scheduling. It doesn't move the needle enough on word of mouth. And we decide, okay, we need to, we have reached the conclusion that something needs to change with pricing. Let's say it's we're going to add another product for an extra $5 a month or something like that. The exact same thing you just said is going to apply then, where it's going to be it's very clear what we need to do right now. We need to add that extra products, technical debt can take a back seat.
Rick: Yeah. I guess where I feel like adding another product is going to require a lot of cleanup of the code based on my experience with PeopleKeep, and so it's probably going to make a lot more sense then. I guess what I'm trying to say is technical debt seems like a very low priority to me as an outsider looking in. And I don't buy that you promised an employee that you would do something, when it's no longer the right decision for the business, is a good reason to do something. Unless they can make an argument and convince you that it's the right thing for the business. I just don't know what that argument is right now. I'd love to hear it.
Tyler: Yeah, the argument I think is just, it's a question of when. If not now, when? Because we said the exact same thing for the last nine months.
Rick: Well, the problem is though you lost some discipline and I think that that's probably where some reflection on is... Should you, if you look, do you regret not putting 10% into technical debt over the last nine months?
Tyler: No, I think it was 100% the right decision.
Rick: Okay, well then play regret minimization.
Tyler: But that assumes that at some point we actually do... The whole time we were saying we're going to spend three months, the whole dev team is going to just do dev chores and we're going to catch up.
Rick: So yeah, at some point that's going to be the right decision, right? Maybe. Maybe never. Maybe it'll be some percentage of the time. But the question is how much time now when you're facing a pretty significant next level up question for your business, should we be focused on cleaning up what we've already done or answering that question? And there's no question to me that we should be focused on answering that question and only doing enough technical debt pay down to make answering that question more efficient.
Tyler: So I actually think there's not as much of a dilemma here as we might be saying, because the reality is we need one or maybe two people to build this... Appointment scheduling is the key thing we need to build. This is not a project the whole team would be working on, either way. So whereas before we were saying the whole team will be doing technical debt for awhile. I think it's easy enough to say let's pull off, I really think it's a one person project, at least the first iteration of it. Let's pull off that one person, put them on it right away, but that doesn't mean nobody else is working on technical debt. So let's say that's the framework, but then we've still got other things in here as well.
Allocating resources across building new features, improving existing features, and paying down technical debt
Rick: So kind of flying up to your original question, which is there's three buckets, right? One bucket is new features. Those are going to be primarily focused on answering this question we just talked about, which is the multiplying effect. Right?
Tyler: Yes. I have a wrinkle. I totally agree with you conceptually. Yes.
Rick: All right.
Tyler: This redesign that we've been working on comes with two... It's not just redesign. It comes with two major functionality changes, new features. One is Outlook Calendar syncing. That one will be done and tied off. That's not a problem. The other one is a dramatic improvement of how custom fields work. Custom fields is a tough one to overhaul because we have all this data, like a hundred million records. We can only do certain things before everyone is migrated into the new system. So we basically split custom fields into phase one and phase two. Phase one we can do with the redesign. It's mostly just UI changes, not much going on in the backend. Phase two we have to wait for everybody to get migrated to the new design before we can do it. So we have been, once again, I don't think necessarily anyone's going to be that upset with us for breaking a promise. But we've been saying we are doing custom fields, both phases, but we can't do phase two until-
Rick: For who? Who's promised?
Tyler: We've told it to customers. This is less employees and more customers I think.
Rick: Oh, that's a different, that's a totally different thing.
Tyler: Yeah. So I don't think anyone would revolt, but we've been saying for a long time, custom fields is going to include these things. And we're largely most of the way towards building them, but we do have to finish that, which is another, I don't know, two, three month project probably.
Rick: And you're a customer first kind of guy, right?
Tyler: Actually, I don't know. I think the output that I want is customer first. I think the input is employee first and that leads to customer first. I think happy, talented employees is the best thing for customers.
Rick: If you broke promises to customers, like not doing this field thing that would upset employees. Yes or no?
Tyler: I'll bring this up in our next weekly meeting. I think they would be less net, everyone has different opinions, net less upset about delaying custom fields versus delaying technical debt, would be my guess.
Rick: Makes sense. Yeah, so this is an interesting kind of a rabbit hole we got into, but coming back up, it feels like there's three categories of things you need to do for different reasons. The big driver stretch goal for the year is figure out this word of mouth thing. That's going to take a lot of the roadmap percentage in the form of new features. Then there's improvement of existing features. It sounds like this promise you've made to customers around the custom fields is part of that piece. And then there's technical debt, which is a discipline thing just because you just gotta do it, just like you've got to take a shower every day and brush your teeth. You've got to do the maintenance. And it's just a question really for you to talk to employees and then allocate a percentage. It feels to me it's really a percentage allocation across those three things and that's going to answer your question. The question is what percentage should you allocate?
Tyler: Yeah. I think that's right. Yeah. We're not going to totally ignore any of these things, but something's getting delayed and the percentage allocation will decide. Yeah. What's getting, maybe custom fields gets done nine months later than people were thinking it would. Or maybe technical debt waits longer or something like that. Something's getting delayed.
Rick: Yeah, I think communication can go a long way in serving both goals, of the word of mouth goal and the custom fields goal, by overly communicating that you're working on that. And keeping people up to date even if it may take longer, it could accomplish, you're doing both.
Tyler: Yeah.
Rick: So.
Tyler: Can I just side note on the custom fields thing?
Rick: Yeah.
Tyler: An important lesson I've learned that I'm going to, I think be a lot more disciplined about in the future, I don't think it will be hard to be disciplined about this. The reason we're in this pickle with custom fields is because we treat it as one big monolithic project versus 10 different things that would happen, like one, we don't do sprints but one sprint at a time. So when I'm looking at 2020 all of the bigger projects including appointment scheduling, I think we're going to break into really small things, where we can say, "Let's do a two week thing." And in two weeks we'll decide are we going to do the next thing or are we going to split off into something else?
Rick: That makes sense to me.
Tyler: Yeah. So I regret doing custom fields the way we did it, I guess.
Rick: Yeah, yeah. Makes total sense. Well, what else? It feels like we haven't really gotten into how to prioritize necessarily, but more how to think about what to prioritize. I don't worry about the... For me, it's like if you can get the right outcome focus at the company level, and then set the right strategy on the roadmap in terms of percentages across those buckets, it feels like a, it turns into really a conversation driven by the team on what to work on. Obviously heavily influenced by you, given you're the design/marketing person.
Tyler: Yeah, I like that. Especially, one benefit to heading a big customer service team who actually has influence over the company, their happiness is almost 100% correlated with customer happiness. So what makes a customer service person happy? It's not getting yelled at on the phone basically. So they're going to advocate for whatever the customers want most and they're going to have the best idea of anyone at the company what that is. And then the developers will be saying, "I want to pay down technical debt." And yeah, we can just balance all that I guess.
Rick: Exactly. And then, set resource allocation. We're going to spend this much development hours on technical debt. This many development hours on customer service debt pay down and this many hours on answering the most important question to our business right now.
Getting employees bought in to new priorities
Tyler: Yeah. Yeah, I'm almost wondering if, because if it's just the question of what is best for the business, I think you're right that that's easier to answer. But the hard thing is there are emotions involved here and trust and morale within the team. I almost wonder if a certain percentage of priorities should be more of a democracy. At the end of the day I decide what stuff is, but we could say, you know what, 25%, so one developer, that's a democracy. I'm saying the priority for the company is appointment scheduling. We're going to devote the resources we need to that. Let's, but the rest of it, you tell me, is it technical debt, is it the next integration? What's the thing you want?
Rick: Sounds like you already know, but you might, it probably would pay off just to start the conversation from a bottom up standpoint. And have this conversation be, it's not a democracy, but definitely be debated heavily before you make a final decision. And then if you can make the decision at a higher level and let people have some freedom in how they implement those that could go a long way too.
Tyler: Yeah, I agree. One challenge with this is I find that I can very easily... So the main way I get this feedback is every week I do a group brainstorming meeting with three randomly selected people. So, it takes about a month, five weeks for everyone to cycle through this. And these are the types of things we talk about. So everyone has had a say and I think they feel heard and stuff. Having said that, this is a hard decision and nobody has more perspective about all the factors that weigh into it than I do. And so what I find is most people are pretty deferential to me. They're like, "You tell me." Which doesn't mean that the outcome doesn't affect their morale or anything, but that they don't necessarily know the answer the way, well, the way I don't know the answer.
Rick: The way I would do this if I were you and I don't know if this is right for your situation, is, I would talk to Bracken and I would come up with a draft set of company goals for 2020 that are very clear. And don't worry about the goal necessarily being 2020, it could be for six months. But come up with a company focus. And then I'd say, "Guys, I'm going to share this with the company. We have until December 31st or whenever to beat the hell out of these and I want you to tell me what you like, you don't like. I want, if you want to add another goal, remove a goal, challenge a goal, do it, and you work through that." And I think you'll find that it's more of a buy in process and you'll probably change something as well. And then you'll have solid goals starting the year that you can then turn into roadmap planning for your development team.
Tyler: Yeah. I like this a lot because I think if I'm examining myself the main uncertainty I have, it's not about what, do we make the right decision? Because the reality is five years from now looking back, am I going to care if custom fields was done in early 2020 or late 2020? I'm probably not going to care. What I care about is people reacting negatively to the decision. And as long as everyone has a voice in what the decision is, no one can really get all that mad about it.
Rick: Yep.
Tyler: Okay.
Rick: One step to consider prior to putting out your and Bracken's draft goals is to do a quick survey of some kind. Maybe it's a drop box, something that lets people formally give their feedback. You may not need that, because you're doing these other sessions that are getting that feedback, but sometimes when I skip that step at PeopleKeep, especially when we had more employees, people didn't feel like they had a chance to say something before the draft was made. But I did ... draft goes a long way anyway.
Tyler: Yeah. So-
Rick: Especially if you say, "Hey, this is not final. I want you to beat it up."
Tyler: Absolutely. And the thing that I'm finding, this is kind of reducing my stress around this is we can pretty easily say ... Like if I said, just in a vacuum, "This feature, how important is it, 1 through 10." Everyone's going to say 10. This feature 10, this feature 10, but if I'm just like, "Here's six things everybody wants. Rank them." That moment everyone's going to have, like, "Oh, yeah. This is tough."
Rick: That's what you need. You need people to go through the trade-off decisions in their head with you versus having to catch them up after you've already made those, because it slows everyone down. That's what you're afraid of. You're afraid of rolling something out and them not understanding all the trade-off decisions that were made, and then having to spend January getting everyone bought in, because they didn't have as much information as you. That is what this exercise is designed to avoid.
Setting constraints against goals to ensure you don’t stop doing the important stuff
Tyler: Yeah. Okay. So I like that a lot. I think that should be layered on top of what we were saying earlier, which is kind of having certain discipline about like, "Well, we're not going below this percent of technical debt payoff, and we're not whatever." Like, to say, "Everyone has a voice, but we can't break these fundamental rules that we have."
Rick: I call them constraints. What are your constraints on this big, audacious goal for the year? If you know these things don't get dropped, they take priority.
Tyler: Yeah, okay. So probably off to ... I think the main constraint is how much time are we going to spend on technical debt, and I think what I'm inclined to do here is say," I think the amount we had before was probably fine. Three weeks a year per developer, but we skipped it intentionally for nine months, and we're going to add that onto the first six months of next year." So the same constraint. Okay. I'll have to do the math and figure out what can we actually get done with that amount of time?
Rick: As you think through this, don't be afraid to think about other constraints that represent other stakeholders. Bugs might be a big one for customer service. I don't know if you have data requests that come in and say, "Hey, changes in the database."
Tyler: Yeah, we just handle all that on the fly. So we have four software engineers. We have two dev ops people who are doing infrastructure. I'm not counting them in this equation. We have four software engineers. At any given time, one of them is on bug fix duty. That doesn't mean they don't have any time to work on their main project, but the rule is anything that comes in from a customer interrupts you.
Rick: Well, I guess what I'm trying to say is that we looked at that as separate from technical depth.
Tyler: Yeah.
Rick: And whether you lump that in with technical depth or keep it out, it's something that if it gets too high, you're going to want to dedicate maybe some root problem solving.
Tyler: Yeah. So sorry to re-litigate something we've already talked about here, but the bug fix thing and the customer data requests, that is what I was saying earlier about what if we just had no technical debt? We do not let that stuff pile up at all. There's a type of bug that's not really a bug. It's like this is a missing feature that the customer wants, but it's not really a bug. If something's really a bug, we fix it 100% of the time. We do not have lingering bugs lying around.
Rick: What you're talking about is the work that requires developer manual work to make the functionality happen, and could be automated with coding, if the developer took the time to do it.
Tyler: Yeah, but the reason I'm bringing this up is because we're already caught up on bugs, it doesn't feel like a sacrifice to stay caught up. But if we had this six month backlog, we might be like, "Well, it's like dev chores. How much time do we devote to it?" So part of me is like if we just caught up on technical debt, would it be this way? We're just never behind ever again.
Rick: I feel like everything I've read about technical debt suggests that it's something that you chip away at, and there are very few situations in which it makes sense to focus entirely on technical debt. A good situation could be upcoming, but it's not right now. It's after you've answered the question, "Hey, this product is tapped out. We need to maximize its efficiency." Then there's an argument for focusing on technical debt. At Zane Benefits, once we made the switch to all new customers going on PeopleKeep, 95% of the work that we had the developers doing on Zane Benefits was paying down technical debt and just increasing the efficiency of how the software ran. No new features.
Tyler: Okay. I buy all that. I guess I'm saying an argument can be made that it's like bug fixes, and that with bug fixes, we have bug fixes paid off and it works. It's a good system, but maybe it doesn't work that way.
Rick: There the only argument would not be based on technical debt, it would be based on an outcome that matters to the business, which paying down technical debt would solve.
Tyler: Except I don't think we ... We don't have that justification with bug fixes. A lot of companies in our position would say, "Well, let's just let the bug fixes pile up."
Rick: I think you should treat bugs the same way.
Tyler: No. No way.
Rick: Yeah, you do, because you're like, if you let bugs get into your place, people are going to lower their NPS score. They're going to be less likely to recommend. There's an outcome there that's driving that that you're just not-
Tyler: I agree.
Rick: ... that's very different. That's very different.
Tyler: But there's a Marie Kondo does this bring you joy thing. I think everyone at the company is less stressed out, more efficient.
Rick: But that's team member NPS. You're prioritizing a business outcome for team member satisfaction in that case, but be clear about why you're doing it.
Tyler: I'm saying dev chores could be the same thing then.
Rick: That's fine. Be clear about that. Like, "Hey, we have dissatisfied employees. The number one thing on our team right now is that we have dissatisfied engineers because there's too much technical debt. We need to prioritize increasing employee satisfaction." You're not talking to me about how dissatisfied your engineers are on these podcasts, so I'm quickly assuming that that is not what's happening here.
Tyler: I agree, but my point here is that exact same argument could apply to bugs, but I like what we're doing with bugs. I think too many companies try to make data driven decisions with everything. They try to quantify it, and I think we're making the right decision with bugs, even though if you're like, "Over the next year, what helps us achieve our goal?" Probably not that.
Rick: And let me be clear. I'm not arguing for quantitative measurement here. I'm arguing for logical decision making based on business outcomes. The bug fixes, you're quickly tying to your key differentiator, which is customer service. Technical debt, I'm just not seeing what you're tying it to logically. It just seems like this kind of thing that we're discussing without it being a logical decision based on the business needs right now. If you're saying like, "Hey, half your engineering team's going to quit if we don't pay down the technical debt," okay, let's do the technical debt.
Tyler: Okay. Yeah. The customer service argument is convincing, I think. That our customers have no clue that there is technical debt, so, okay. Okay. Fair enough. So we'll have some kind of minimum requirement, like a constraint, like you said, about around technical debt. Otherwise, everything else, whether it's building little features or totally new features or improving old ones, they're not different categories. It's just about prioritizing what helps, what we're trying to do with the company right now. What we're trying to do right now is focused on word of mouth, so it makes sense to prioritize that. But we should still probably do a couple things so that we're not ruining morale and all that. We should give employees a voice in what those other things are, but it probably is going to be a tough choice where everyone's going to want everything, and they're not going to get it. So let them have a voice, and they can help decide what are the sacrifices we're going to make in order to prioritize this other thing, which is our main goal.
Rick: I love it. It's basically like ... I haven't really thought about it this way, but it's basically like you've gone through all sorts of change cycles getting to this narrowed list, and you've given yourself time to digest that and get go have a down moment. Get sad, then get excited about the new direction and have it happen again. Letting your employees go through that is the only way you're going to get them bought in to the focus you need to create. You want to create a lot of focus, which is awesome for 2020, but it's so hard.
Tyler: Yeah. Not to further complicate this, because I think this fits into the framework we were just saying, but we've got this list of 50 small things. One's maybe a week or two, and every single one of them would delight our customers. It's so hard not to just be like, "We can make our customers happy literally every week. Let's just go do that," you know?
Rick: Hopefully someone on your team will make the argument. This isn't the right place for it, but that's a good idea and ways to increase word of mouth is to have some sort of release cycle that is remarkable on a weekly basis.
Tyler: Yeah. That'll be one of the ... I'm going to lump them all in one thing. When we're prioritizing, all of those little things versus custom fields versus MailChimp integration versus ... So yeah, we'll see what happens. I guess I'll report back whenever we have that feedback to say what they all said.
Rick: Yeah. I guess would you summarize any takeaways real quick before we sign off?
Takeaways
Tyler: Yeah. My main takeaway is that framework. It's you have to balance things. I think it's nice to think, "What's our top priority? We're only going to work on that," but even at a one person company, I don't think you can really do that, because there is such thing as momentum. You lose ... If you just ignore one part of the business for a long period of time, you're going to be in trouble, but it's about setting constraints so those things can't balloon out of control, and then deciding how much time am I going to allow as flex time. This is going to go after the top priority, and then just go after it, I think.
Rick: I like it. It's kind of very similar to what we talked about with the consulting podcast. Consulting is my constraint, and then it's like I have to go after ... I do that, and then with all my other time, I go after whatever my top goals are, top priorities are for the business.
Tyler: Yeah. I'm trying to think back, because probably most people dealing with this, if they're at a bigger company, they have some kind of system for this already. It's really I think the hard place to deal with this as if you're a single founder or a very, very small team where it's not like you're delegating to other people, but it's like how do you split up your own time? But I think the exact same process applies where you might say, "One day a month I'm doing technical debt payoff, and then two weeks a month I'm working on my top thing, and then that other week," or however you want to do it. But having a system like this, I don't think there's any company too small to benefit from putting a framework like this together.
Rick: My wife and I use something similar actually to plan our family stuff, and it's like, "Listen, there's a few things we have to do every week, and that's our constraint that we do together." One is date night on Fridays. It's the priority every week, and sometimes it gets moved and rescheduled, but we don't ever take that off the calendar.
Tyler: Right. You're not week to week saying, "Well, should we brainstorm if something's going to take priority over date night?"
Rick: Yeah, exactly. It's just set in stone. It's a constraint on our time that we spend in our lives.
Tyler: Yeah, I guess there's a benefit to not making the decision. This is something I often forget about is the time it takes to make a decision is a cost. Even if you're doing something suboptimal, but you can do it with zero decision-making, you still may end up ahead, even if it's the suboptimal path.
Rick: I totally agree. I need to explain that more. Sometimes I do things where it's like I have this weird thing scheduled every Monday at 3:00 PM, and I try to explain to someone why I have it scheduled there. It's like, you just explain it properly. It makes it so I don't have to think about deciding to do it. Deciding to do something is actually so expensive in terms of brain power.
Tyler: Yeah. This is a really douchey example of it, but I know Steve Jobs was famous for always wearing the same outfit. He was like, "When I wake up in the morning, I don't want my first decision to be what I'm going to wear. I want it to be about something important," so it's the same idea.
Rick: Yep. Yep. Yep. I love it. Well, thanks. That was actually a really interesting conversation. I appreciated you being so transparent about that.
Tyler: Yeah, I got a lot out of it. Thanks for that. I always like these conversations where I can bring my kind of developer hat, and then you can wear your business hat and tell me stop thinking like a programmer and start thinking about what the business needs, so I appreciate it.
Rick: You bet. I also ... I would give you some props back. You constantly remind me how important it is to put employees first, and I think that you ... Hopefully your employees appreciate your mindset around that, because it's very hard to do in your position. All right, everyone. Thank you for listening. You can join the conversation on this topic and review past topics by visiting
startuptolast.com. If you have questions, contact us via the website or on Twitter. We'd love to hear your thoughts and ideas that's
startuptolast.com. Also, we'd love, if you liked this podcast, for you to leave a five-star review on the podcast app of your choice. It'll help us get some exposure, and we'll see you next week.
Tyler: All right. See you.