Building on a post from last July about Incompatible Worldviews…
Almost every Go-to-Market-side enterprise stakeholder I interview tells me that their product team is unresponsive: that folks rarely get anything back after submitting an (urgent, strategic, well-considered) ticket through the company’s agreed-upon enhancement request process. That the occasional response comes long after their urgent situation has resolved itself via lost deals or workaround solutions, with a less-than-helpful “not now” or “need more information” or “we’re sorry.”
GTM leaders typically ascribe this situation to lack of attention, poor work ethic, or weak understanding of customers on the part of product management – i.e. personal failures best addressed by replacing or upgrading product staff. Or by hiring outside experts to teach them prioritization. Or via more efficient processes (aka ‘best practices’). Or by only hiring “hard core” folks willing to sleep under their desks.
They often propose grading product managers on answering tickets. This might be an SLA (service level agreement) requiring product management to respond to every incoming request within 2 business days. Feature request queues are instrumented, metrics are auto-reported daily, bonuses and promotions are tied to average response time.
But if this is a nearly-universal problem – systemic across companies and industries – there must be something more fundamental happening. It can’t be that 90% of product managers are incompetent or lazy or quietly quitting.
Instead, I think it’s the combination of three broad organizational challenges:
[1] most requestors see the world one account/user at a time and urgently want to solve that one customer’s issue. All other issues (and existing commitments) are temporarily forgotten.
[2] software product companies should almost never make changes for a single customer, no matter how big the deal. But many GTM folks come from software services companies whose bread and butter is building exactly what one client will pay for. The idea that we’d routinely not do precisely what customer X suggested is bizarre, sacrilegious.
[3] the Lake Wobegon effect (“all the students are above average”) where requestors intellectually understand that 97% of all tickets must be rejected, but their item is somehow in the top 3%. It’s important right now to this customer, so must (somehow) get approved and implemented in short order. Why have a request process except to approve what I need?
Across the aisle, each product manager sees the aggregate request stream from coworkers and partners and paying customers, which includes hundreds of new tickets each week via email, slack, Jira, Zendesk, phone calls, PostIts, F2F meetings, lists from Customer Advisory Board meetings, end user “vote up your favorite suggestion” portals, and hallway conversations with the CEO.
Note that forcing all of these requests into one system-of-record doesn’t reduce the number of items… 280 tickets/week merged into Aha! doesn’t change the fact that 275 of them will never make it into the product development queue.
And requesters really don’t just want any answer: they want a YES answer.
If I spend 90 seconds skimming a ticket and quickly respond with “REJECTED,” I expect the human at the other end to want a conversation; to present more context; to communicate urgency; to claim large revenue numbers; to ask for much deeper reasoning and analysis; to show me competitor data sheets; to question my method; to escalate to my boss or threaten my job.
Giving this item a thorough review – including an in-depth interview with that end customer and impact assessment on other users and identifying any technical complications/ dependencies and guesstimating financial outcomes and rough-sizing the work with Engineering – is a half-day or a half-week or a half-month of effort. Per ticket.
So each product manager will now spend 1120+ hours/week thoughtfully reviewing and prioritizing and responding to incoming requests. (In fairness, many are duplicates or deeply misguided or too fragmentary to understand. That slashes the work to <600 hours/week/product manager. 😊 ) Almost immediately, we’ll turn the product management team into a full-time ticket review team, not doing any core product work: planning; strategy; defining and tracking OKRs; product launches; looking out ahead of obvious incremental fixes; bringing donuts to development teams; supporting Sales calls; depositioning the competition; revising Board decks.
Imagine a machine learning application that goes through the ticket queue in real time, matches each against keywords in corporate strategy PowerPoints, invents an outcome metric, inspects upcoming development sprints for unallocated capacity, and then immediately rejects 97% of incoming items. We’d soon be arguing about how to fix the ML model… to somehow approve 50% instead of 3%. It’s the rejection that stings, not the method.
There’s no shortage of ideas or suggestion boxes or tickets or feedback channels or 'Voice of the Customer' mechanisms or conference rooms full of PostIts. And the wider the funnel, the more incoming ideas won’t make the cut. We’re short of vetted, validated, deeply thought-through ideas that are worthy of experiments and might just move the needle.
For me, this is an investment portfolio problem, not a response time problem. Savvy product managers at product companies know that investors value repeatable, frictionless, sell-the-same-bits-hundreds-of-times software at 6x to 15x revenue, so we quickly pick 20-30 reasonable options for experiments and deep dives, looking for the next 2-3 winners that will drive measurable outcomes and meaningful revenue for scores of customers. The remaining 8000 get no love.
Borrowing from the investor world... I’m part of an angel network that invests in early-stage startups. The fund takes more than 250 introductory meetings each year but only funds 5-7 new companies, or 2-3%. So we have to make very quick judgments to move 15-20 candidates into serious due diligence and the other 230+ into “check back later and let us know how things are developing.” Experience and good judgment prevail, even though we might miss a winner.
So how do we get away from “ever more ideas and suggestions is better” and “every ticket deserves an hour of analysis?” I look toward sensible aggregations by departmental leaders on a slightly longer schedule:
- From Technical Support leaders: what are our 7 most frequent issues (not 20 or 100) this month? What are the 3-4 emerging issues that we’re most worried about (not 12 or 45)? How much can we save if we move 2 (not 60 or 75) into the few next sprints? Can Tech Support help us focus?
- From Sales execs: what 3 missing features (not 15 or 35) cost us the most deals last quarter? Does Engineering (not Sales) think any of those are small or straightforward? If we address those, will Sales commit to a higher close rate or more revenue?
Notice that gathering this separately by sales region or vertical or account size gives us 16 different lists with 100+ candidates rather than sales-wide priorities. - From Engineering management: if we could spend 40 developer weeks on technical debt and internal tooling this quarter, which few projects will improve team throughput and quality the most?
- From Integrations/Customer Success team leads: which access method or API extension would eliminate the most CS time and effort next quarter (assuming they are rewarded for doing less, not invoicing more hours)?
Etc. Having designated reviewers and prioritizers in other key departments lets us spend more time on the handful of really important requests from each. Better to put 42 hours each into a half-dozen serious possibilities than 2 minutes each on 130 unscrubbed tickets.
And worth noting that none of this will magically make everyone happy. Incoming demands will always be 20x more than we can ever build, so 95% still go into the later/never pile. Account teams and support groups still won’t feel listened to. Integration squads will still uncover unique third-party systems that we don’t connect to. Many legitimate customer needs won’t be met. Product managers will still be seen as unresponsive. But we’ll get more — and better — products shipped that satisfy large numbers of customers.
So applying SLAs to request queues ignores the fundamental issue: the development funnel is very narrow, and the incoming request stream is very wide. The vast majority of asks won’t make it through.
Sound Byte
Process fixes like internal SLAs only help if we have a process problem. When we have demand that's enormously higher than any reasonable capacity, we need to aggregate inputs or do rapid triage – and move on.