Exploring the cost side of the Sales Driven Roadmap

This deal is at risk until we can ____________ Are you ranking these requests by the revenue opportunity? They won’t renew unless we _________ Can we schedule a meeting to review the following RFP points?As a product manager in the B2B space you’ll inevitably run into a situation where sales is pressuring you to prioritize work to close a deal or retain a customer. It’s a dance Sales, Product, and Customer Success repeats over and over (picture a clumsy threeway waltz or polka). Cue the conference call feedback, twenty page RFPs, and rushed impromptu cross-team standups.

It’s a challenge. You are customer focused. You have empathy. But somehow the cost vs. reward feels off and you can’t prove it. Don’t give up so soon. Consider the following …

Growth Driver

Before jumping into thinking about costs let’s get one thing out of the way. At the end of the day you might not be too concerned about costs simply because controlling costs isn’t the focus. The underlying assumption for most growing businesses is that costs can eventually be controlled. Revenue and growth is king (see The Single Biggest Determinant Of Startup Valuations At IPO). You’ll read the impacts below and say “that’s all good, but we need to hit a growth goal”. I respect that. But I’d challenge you to consider instead the potential drags on innovation and agility. These are blockers to growth and should be considered. Keep reading …

Bias Petri Dish

It’s easy to rationalize the broad appeal of a feature request. We’d need to do this eventually, right? Other customers and prospects will need this if Acme needs this, right? There are a bunch of cognitive biases at play here including the availability heuristic, base rate fallacy, clustering illusion, sunk cost bias, confirmation bias, and conjunction fallacy. These manifest as follows:

• The prospect is representative of other prospects and customers
• The prospect’s needs are not specif. They are general
• The prospect request is equally valued by other customers and prospects
• Meeting the prospect request will actually result in a satisfied customer
• We’ve invested a lot of time and money in cultivating this prospect so …
• This run of requests represents a trend We’ve all been victims to these biases in our personal and work lives. You can’t escape. As a species these instincts have served us well for the most part. However, the prospect request is straight out of an MIT behavioral economics study. It hits so many pressure points that most of us are basically screwed. It’s as if you combined the lottery, your love life, and probability in a petri dish. What’s the point here? You’re not seeing things clearly and your intuition is suspect.

Net Loss

Off the bat you’re at a net-loss if you invest $50,000 in engineering and product resources to deliver a feature which will increase your revenue by $100,000. Why? Isn’t that a profit? No. Not even close. The code will need to be maintained and will add to the complexity of the overall codebase hindering future velocity and innovation. Features need documentation, sales training, marketing, and support. And we’re not even talking about the other costs associated with that $100k of revenue (acquisition, on ramping, etc.) No one “accounts” for these costs. They rarely exist on a balance sheet. But they’re real and will bite you.

User Experience Impact

Imagine an aging hotel. Hallways disappear into nowhere. The light switches are never in the right place. It takes ten minutes to get to the pool. The Internet is spotty. Countless new additions create a sprawl that is difficult to navigate.

Welcome to the world of most enterprise software. You can get by for a while … heck, the “user” didn’t even cut the check … but you can never truly escape. This costs is extremely difficult to quantify but we’ve all, at some point, been on the receiving end of enterprise software that truly sucks usability-wise. And when a disruptor pops up that shifts the script we’re all the more willing to embrace the alternative.

Customer Need

The prospect has a list of requirements. Lists of requirements feel comfortable. They’re relatively easy to write — heck, just add a couple points for good measure. Someone owns this decision and by golly they’re going to own it. As someone involved in buying tools I can say without doubt that the requirements process is simply broken. It’s aspirational. Big and heavy RFPs are a recipe for failed implementations and software detritus. They may close deals, but they are not a leading indicator of long term adoption. In the heat of the moment it’s tempting to treat the RFP as gospel and the byproduct of careful research. It rarely is. The customer may rave about your responsiveness at first, but they might not be any happier in a year.

From an Agile perspective this is a big “requirements upfront” anti-pattern:

Looks simple huh? (Source)

As someone with UX Research experience I can say beyond a doubt that lists of features rarely address true needs. They jump to the What before the Why.

Value Proposition

If one feature is the deciding factor between the buy or pass what does that tell you about your business and product? Consider tools that solve a unique pain incredibly well. We get frustrated as users. We have to invent workarounds to make up for missing features. But we use it anyway because it does something incredibly well. If you’re battling over RFP bullet points consider the game you want to play. Are you battling over commodity features?

Opportunity Costs

This one is simple. By working on one thing you are by definition not working on something else. What are you sacrificing to attend to the prospect request? What could you build or explore given those resources? What is the value of doing this now vs. two months from now?

Distractions & Multitasking

External requests typically involve a lot of multitasking. There are endless cycles back and forth between sales, product management, and engineering. It’s hard to get the right people on the phone. You’re at the whim of conference calls. Just when you think you’ve nailed down the request someone else pops up and peppers your understanding like a gattling gun. Conservatively the team is at 50% effectiveness and it seeps into their other responsibilities.

Product development teams also feel the pinch. Prospect requests are typically run in parallel with existing roadmap driven work. It takes 3x the amount of time to finish two parallel tracks. SImply put, your team runs slower.

Conclusion

Hopefully that gives you some food for thought. I currently work for Pendo.io, an analytics tool with in-app guide and messaging functionality. One of the unique selling propositions of Pendo is that we record user activity retroactive to install. In the rush to crank out customer requests it can be prohibitive to add metrics and measure uptake. Our customers use this feature to reality check their intuition. Sure, the deal closed, but did anyone end up using it? Did it impact customer satisfaction (measurable with our in-app surveys and funnels)? The cost to answer these questions is low which in turn improves your team’s intuition in the face of bias. Until the costs are real, the debate will always swing towards Sales and the immediate prospect request.

Hope this has been helpful. Follow me on Twitter at @johncutlefish to keep the conversation going.