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...