#Build 4: Backlogs Don't Matter
Speaker 2: Hey, it's Maggie. Here to talk about products, my biggest tweet ever, and how backlogs don't matter. So that'd be could go I got off a Friday night phone call with our San Francisco sales team all fired up from hearing about what they're working on, what's going on out there. And while I was on the phone, someone had tweeted at me saying," Hey, jumped on this conversation and tell this person what your favorite tool is for managing a backlog." And, it's Friday night, to be frank, I don't give a shit about backlogs, they just don't matter. And so I fired off something and saying," Stop wasting time talking about tools and backlogs, it doesn't matter. Go talk to your sales team, figure out what hurdles they're running into and solve for them." And I left for dinner and didn't think anything of it. Turns out that tweet got 320 Likes, a bunch of impressions, and I only have 400 followers that felt like a pretty good result. And even more importantly, I got my very first internet troll, which, I think unlocked female product manager on the internet level 10 with that one. But in all seriousness, I think this reaction sort of highlights an interesting nerve that I struck within, the product community on my admittedly hot take on backlogs. And if you step back and try to sort of take a scan through popular articles lists on media or whatever, basically everything that you come across about building software is about the process. It's about what framer to use, what tool is best, how to build relationships with your software team, or how to work through the designers. And, none of it really gets to actually what we're building and why, and why does it matter? And more importantly, what are the results? So, I think the reason why there was such an interesting reaction to this is that, in product we've built up this sort of instinctive reaction to criticism. And, what that means is, if something bad happens, if I could just refine my process, if I could just better estimate when we're going to finish something, if I could figure out how to get that burn down chart all the way down to the ground in Jira, if I could turn the more things into reasonable components, if I could finally ship that style guide, then the results are really going to start to roll in. Really, I think this is just a combination of arrogance and fear talking, because it's really hard to look critically at what you're doing and to really think about whether it's going to generate results for your business. And I don't mean whether or not there's a metric tied to a feature, I mean actually making money. Especially if you're in the middle of a bunch of work, your roadmap was agreed upon a couple of quarters ago, or you've already invested a bunch of time and money on what you're building. All of that sort of builds up and then gets in between you and your customer, and makes it really hard if not impossible to respond to the customer needs. And I think that's exactly why coming back to where we started, product can be so reluctant to talk to sales. Because your sales team doesn't necessarily understand the roadmap and they don't have to. They don't have all the context you have on why you've prioritized the features that you have, or that you made the choices that you've made. And because really they don't have to, all they care about is, do customers actually want what you're building? And can they sell it? And I think at the heart of it, that's what product cares about too, right? What we want to know is can we solve a problem that matters well enough that customers actually want to buy whatever it is that we're building. And so to me as a product person, if you're reluctant or unwilling to enter into that conversation with your sales team, or if you avoid it or you don't do it regularly, or if you're not even really having the same conversation with your customer success team. Then you know, you're hiding a little bit. And even if you are having that conversation, maybe you find yourself saying something like," Yeah, that's really a great point. We just really needed to get through building feature A, B and C, and then we're definitely going to look into that." And so if that's starting to sound familiar, that's a really good example of when your backlog and your process and the stuff that you've already started invested in, sneaks upon you gets in the way and makes it really hard for you to even really hear or process this real- time feedback that you might be getting from other sources outside of what you already have. Your process and backlog and roadmap and whatever in the case may be is sort of a crutch to avoid what might be a really painful realization of a mismatch between what you're building and what your business actually needs to grow. And of course, this kind of feedback and this perspective is gold for the team. This kind of course correcting information is precious, but you have to be open and willing to listen to it, which means you have to be able to let go of your backlog. So, my challenge to you is step back from what you're doing, go talk to your sales team, maybe hop on a demo, maybe even a call with customers about to turn. And then go and think about what about your roadmap is going to directly help your team? How are you solving for those problems as a product team? And if you're not, why not? And I'd love to hear why not, definitely hit me up maggie @ drift. com. Tell me where I'm wrong, tell me why this doesn't matter, tell me why your backlogs are sacred. Thanks very much!