As deeply data-driven, analytical product managers (or product owners or business analysts or development leads), we’d like to pretend that incoming technical requests are simply transactional: we decide what to do with them, insert them into a backlog if necessary, and move on. In the real world, though, real people and real agendas are involved. And that means there’s a personal and political context to consider when prioritizing demands on our already-overloaded development organization.
We (product managers/owners) should still be driving decisions about development priorities and relative value based on the facts as we know them: importance to our broad market, business value, relative development effort, alignment with strategic initiatives. (Steve Johnson has a wonderfully simple spreadsheet for this, and Mike Cohn has been working this issue forever.)
But that’s not enough. In order to avoid the endless spin cycle of re-requests and re-justifications and re-prioritization, we need to understand the emotional/organizational underpinning of product requests. That lets us deal with underlying needs, maintain empathy for the requester, and drive pragmatically effective decisions.
It’s worth remembering that every active product has an enhancement queue that’s 10x or 50x larger than can ever be delivered by its development team. You’ll never get to the bottom of it. Also, most requests are badly considered, or have easy workarounds, or are being addressed elsewhere, or undercut your product strategy and pile up technical debt. So graciously handling dozens of never-to-be-fulfilled requests per week is an essential part of every product manager’s job.
Let’s consider three audiences for requests against some imagined enterprise SaaS finance application.
Current customers
These are the folks who pay your salary, so deserve thoughtful handling. They’ve probably also had to push through your Sales Engineering and Support groups to finally get to you – the person who is supposed to be able to help. Unpacking this:
- Actual request: “We need two more columns added to your ‘Profit & Loss’ report so that we can correctly handle sales taxes at the city/county/province level.”
- Unstated personal context: “This is a real problem. We have a legal obligation that we must address. This isn’t enough to disqualify you as our vendor, but it’s taken me weeks to get through your Support team and bug submission process. I’ve invested time because my boss needs me fix this. Besides, how hard could it be to add a couple of columns to a report?”
- The questions you really need to answer: “How many customers are affected? What is the value of solving this problem? What is the cost of building this solution instead of fixing something else? Will this negatively impact our relationship?”
What you owe your customer:
- Thoughtful review of the underlying need, not just the request. “Let’s make sure I understand the root issue. You need to report total sales monthly by geo-codes that are smaller than states or countries for local sales taxes and VAT… and one way to get that data is from our ‘Profit & Loss’ report.” Avoid solving the wrong problem.
- Workable alternatives, even with competing products. “Have you tried our export utility? Our data warehousing option? There’s also a third party analytics tool that some customers really like. I know the product manager there, and can help arrange a trial version.” Real solutions are better than promises.
- Humbly accepting the request. “I understand the issue, and I don’t see an obvious workaround. Let me put this into our backlog and get some technical review. My developers know the architecture better than I do, and may see alternatives. In any case, we have to size and schedule the work.” Assume this may get escalated, so create a trackable ticket/story.
- No false promises. “Getting version 6.5 shipped is our focus for the next month or more. So let’s keep looking for workarounds.” You are your product’s truth teller, and will be dealing with this customer for years.
Note that we’ve addressed the customer’s need to be heard, not only the request itself. We’re trying jointly to solve the underlying problem rather than just routing paperwork.
Cultural sidebar: The Japanese are famous for the many ways they can indirectly say “no” without actually saying “no.” It’s culturally unacceptable there to bluntly turn down requests, so they have lots of well-understood alternatives. (For example saying “That would be difficult” while audibly sucking air through ones teeth.) I remember the meeting with one of our Japanese customers who kept saying “hai” and our US sales guy who was totally thrilled. Later we were reminded that “hai” means “yes, I hear you” rather than “yes, I agree.”
As product managers, we need to cultivate nuanced ways of communicating.
Sales people
If your company has a sales force, these are the folks who bring in money. They are (at least in their own view) the most important people at your company, and everyone else works for them. It’s critical to remember, though, that individual sales reps are paid handsomely to close individual deals. It’s not their job to evaluate broad market interest in features, or make trade-offs between segments. Unpacking this:
- Actual request: “The $16.4M Goldman Sachs deal depends on adding two more columns added to our ‘Profit & Loss’ report. We need a commitment for Q3 by Friday.”
- Unstated personal context: “Goldman’s evaluation committee says they need. Closing this gets me a bonus and the 110% Quota Club trip to Hawaii; otherwise it’s steak knives and employment opportunities elsewhere. Besides, some extra columns can’t be more than 10 lines of code.”
- The questions you really need to answer: “Is this deal real, and is it really that big? Does closing it actually depend on only solving this one issue? Are we encouraging reps to sell features we don’t have?”
What you owe your sales team:
- A quick, realistic assessment. “This is a one-off request we haven’t seen from other customers and may have some real technical challenges. And we’re working 100% on version 6.5 through next month. Getting a commitment by Friday for Q3 is next to impossible.” Let your sales rep plan his escalations wisely. This might actually be a loser deal, or enough for the rep to say he pled his case.
- A hard scrub of the actual need and workarounds if this deal is big and serious and urgent. “Let’s get me on the phone with you and Goldman’s technical lead so we can explore alternatives.” We really want to close the deal, and sales teams often miss technical details. How can we make our sales team heroes without spending precious development time?
- Contingency planning with Development. “Jorge, I’m hoping this Goldman thing won’t interrupt your team’s planned work. But let’s brainstorm some options and guesstimate their impact in case it comes back around.” Don’t be caught flat-footed if this opportunity turns out to be real.
- A heads-up to your immediate manager about possible escalations. “Sarah, this Goldman deal may get bounced to your desk. Let me prep you in case our VP Sales walks over.” Your top reps didn’t get to the top by taking NO for an answer, and will work over/around/through you if the deal warrants.
Sales would love an instant YES, of course, but deserves some useful information in any case. Be bluntly “American” to avoid being misunderstood.
Executives
Your CEO is paid to drive big ideas, find new markets, create strategic initiatives and manage your boss’s boss. He’s also the final escalation point on big deals. BTW, he has an irrational belief that the development organization has unallocated resources. Unpacking this:
- Actual request: “The Goldman deal needs this minor reporting enhancement. When can you get this done?”
- Unstated personal context: “This deal is real, and $16.4M is big enough that we may throw some of our development plans under the bus. Product management should have figured it out already.”
- The questions you really need to answer: “What costs are we willing to incur (late products, lost customers, one-off spending…) to win this deal? What size opportunities deserve this level of CEO involvement?”
What you owe your CEO:
- A realistic answer. “Of course we could implement that change, but that would push Version 6.5 back into next quarter. You’ve made personal commitments to Boeing, Commerzbank and Staples on our ship date. And our Sales VPs thinks $8-$12M of other core business would be at risk.” Inserting something new into the development calendar almost always means delaying something else, and you should specifically identify what will spill. Vague warnings that ‘other stuff will be delayed’ are not actionable.
- Help re-ordering your roadmap or prioritized market stories. “Does the Goldman work go here, above this committed item? Above all of these?”
- Creative solutions to the problem. “There’s a third party development shop that solves similar problems. We could pay for a one-off customization and buy some time to design/implement the right solution.” Find the middle way.
- Accept the answer. “Yes, sir.” If you’ve thoughtfully laid out alternatives, costs and risks for your CEO, then you’ve done your job. No need for organizational seppuku.
CEOs tend to evaluate alternatives in financial terms. You MUST be able to assign a dollar impact to postponed roadmap items, otherwise you’ll forever be pushing strategic stuff back for this quarter’s special. Dig up the revenue forecast you originally used to greenlight Version 6.5.
Sound Byte
Customer requests are more than just transactions: they have a personal and political context. Especially if that particular request is going deep into the backlog, be thoughtful about how you handle it and communicate decisions.