“A Working Request Process Should End in YES” (aka Incompatible Worldviews)

Apologizing in advance: I’m intentionally exaggerating the differences between two broad corporate groups: wildly oversimplified roles and attitudes and reward systems. Each group does something irreplaceable.

Especially in B2B/enterprise software companies, I see two dramatically divergent (incompatible) worldviews that IMO explain a lot of corporate behavior.

The Enterprise Sales/Solutions side of the organization [new sales, renewals, customer success/implementation, professional services, support escalations, account-based marketing] deals with one major customer at a time then mentally moves on to the next. Sequentially. Right now, this deal/customer/integration is the most important thing, so my customer’s request must be one of the company’s top priorities.
The Product/Development side of the organization [product, engineering, design, first-line support, product marketing] deals with cumulative impact across all customers and prospects, including everyone who is still paying to use any version of any products. Aggregate outcomes. Total demand for engineering always outstrips resources by 20x-100x, so they can only consider the handful of requests that benefit large numbers of customers. 95%+ of all incoming demands must inevitably be rejected.

I observe that this is much more than a vocabulary problem. Rather it represents a fundamental ongoing disagreement about how decisions are made – and who makes them.

Let’s overstate the two groups’ viewpoints.

Enterprise Sales and Solutions Teams…

Are paid/rewarded/promoted for working with individual prospects or customers one at a time. Sales teams get quota relief from closing individual deals, not market segments. Integration groups are usually assigned to one (or a few) deployments, moving on when the application works. Customer support reps handle one ticket or issue at a time.
Try to fit the current product to the customer’s unique situation and requirements. Extensions, custom integration code and workarounds are wins. Finding a new use case or novel market segment for an existing product is a coup! Where else can we make this product fit?
Celebrate big wins and completed integrations, then move on to the next opportunity. Commitments from Product/Development are assumed to be on schedule. Custom code will work in perpetuity (since no one has ongoing support responsibility). Architects and product managers are responsible for assuring that future product versions are compatible with every customer’s extensions and workarounds and specials.
Assume that every enterprise customer has a list of enhancements, requests, demands, needs beyond the current offering. These are mostly seen as reasonable and technically sound. Sales teams must show good faith by getting some of them approved and committed.
Expect that we can fund incremental development out of deal dollars. Hire someone to do what Engineering can’t get to, or refuses to do.

In the one-at-a-time worldview, feature request processes are purely administrative, intended to get most things approved. Major customers need what they need, and closing this sale (or completing this integration) is top priority. Sales/Solution teams jump through the hoops created by Product/Development, expecting to quickly get committed delivery dates rather than silence or rejections. Stated strongly, a working customer request process ends in YES for most requests. If things are turned down – or responses take too long – then escalations go right to the CRO and CEO.

(After all, the customer already gave us the specs. How hard could it be to add a report or change a workflow or support one more API?)

Across the aisle is an entirely different world.

Product/Development Groups…

See total demand from the whole company for enhancements, fixes, and features that always wildly over-exceed engineering capacity: I typically see 20x or 35x more demand than can ever be met. (A 200-person company with one request per week per employee means 10,000 requests/year. 50x-100x actual throughput.)
Observe that most incoming requests are incomplete, out of context, poorly thought through, and likely to have a negative impact on other customers. Almost all are specs (“do this”) rather than problem descriptions (“here’s what isn’t working”), with a suboptimal solution. Unpacking, understanding and validating an enterprise feature request takes days or weeks. (In my experience, most customer-spec’d work doesn’t actually deliver what that customer really needs, so is entirely wasted effort.) See Teresa Torres' framing.
Need to identify how many other customers are having this same problem, and whether one improvement will satisfy the larger group. Can we solve a range of issues across the installed base with one fix? Speed up onboarding for hundreds of customers with a single workflow improvement? Doing honest discovery with a dozen similar customers takes weeks. Enterprise sales teams each focus on their one major prospect, not meticulous market validation.
Know the existing roadmap is optimistic, and already exhausts all engineering & design bandwidth. So committing to any new feature necessarily means decommitting something already promised. There are no secret resources or hidden teams or magic agile improvements or underutilized developers. Very few freebies. And the items we delayed from last quarter(s) already fill up future quarters.
Expect customers using products in unusual ways to have unusual needs. Our first healthcare customer will have a stack of new-to-us pharma regulatory and audit requirements; HR policies in Europe are very different from the US. So a sales win in a new segment or rare use case can force major changes in the entire product plan — forcing decommits on already-promised work.
The company is obliged to support every line of code that any customer is using, including all back versions and all custom extensions. This ultimately falls to Product and Engineering even if built by an Integrations team, so Engineering’s support burden increases every time we do custom work. Even if it’s for one customer. Emergency escalations of old/broken/unmaintained/”unsupported” stuff can easily consume 1/3 of the entire Product/Development budget. Every new feature reduces capacity for future features, so needs to be considered in a broad product-wide context.
One-time outsourcing usually makes this worse. (“We can take $20k from this $250k deal for contract developers.”) Training an outside team; reviewing their work; mediating technical discussions; managing timelines and dependencies is typically harder than doing it internally. And one-time funding means that our own Engineering will be responsible later when it breaks or needs maintenance. (Everything eventually breaks.)
Creating software is a craft, not an assembly line. Every new feature is being built for the first time. Complexity, technical discoveries, staff churn, dependencies and overconfidence mean that estimates are always low… schedules typically slip. This quarter’s commitments are constantly at risk.
Sizing everything in the backlog is a fool’s errand. (We’re never going to green-light 95% of it.) Responding intelligently to every incoming customer request is unreasonable. (If each of 10,000 items needs ½-day analysis, that’s 25 full-time product managers doing nothing else but validating tickets, most of which will never be worked on.)

Product management, then, sees its job as carefully curating and validating the handful of items which will make a measurable difference to the broad customer base. Rejecting the remaining 95%. Avoiding commitments we can’t meet, single-customer requests, long-term support we won’t staff. Using our ever-so-scarce engineering and design talent for a short list of validated improvements that will deliver major impact across the installed base.

In the cumulative Product/Development worldview, choosing this month’s few in-plan items is central to serving the overall customer base. Rapidly eliminating the bottom 85%+ of incoming demands (or quietly ignoring them until many different customers highlight the same problem) is essential to getting anything done. Finding polite ways to love our stakeholders but unequivocally decline their demands (“you’re terrific and I love what your department does and how well you advocate for customers, but no — we’re never going to do this particular thing, even if we put it into the backlog”) is a core part of the job.

Notice that the Sales/Solutions and Product/Development worldviews are not just different, but in direct conflict. “Giving each customer what they want” and “having a scalable, repeatable product with little incremental new-customer effort” don’t easily coexist.

So we’re often in a position where Sales/Solutions sees Product/Development as inattentive, incompetent, and unconcerned about what buyers really need. From their POV, this is a process and personnel problem to be solved by simplifying submission forms and hiring more responsive product managers.

Product/Development sees an endless stream of demands and escalations from Sales/Solutions that are (mostly) poorly conceived, hopelessly under-validated, certain to run up more technical debt or create unfunded support issues, and which will necessarily derail the 2 or 3 company-survival improvement efforts that we’ve already promised. It inevitably leads to poor products. From their POV, this is an organizational and political problem to be solved by endlessly showing its cumulative impact to executives and then demanding some executive backbone.

It’s easy for this to devolve into “we said, they said” and “my job is harder/more important than your job. FYI, Sales usually wins when we argue philosophy. But the two models lead to entirely different company-level financial outcomes. Boards and investors really care about the size of the exit.

Money Matters

Investors pay 6x-10x ARR for SaaS companies that can add new customers with very little/no effort, no customization, no specials or separate code threads or single-tenant hosting or architectural changes. The investment thesis is that once we’ve found product/market fit, we can scale up Sales & Marketing to bring in scads of new customers without scaling up Product/Development or Implementation/Success very much. We can sell the very same bits to a 2nd and 3rd and 500th customer without doing fresh engineering. Building products is a relatively fixed cost as ARR grows like a weed.

Professional services firms are generally worth 1x revenue. They grow by hiring more developers, and bill clients for development time/effort rather than already-built software. They have to keep project pipelines full and tech teams busy. Hiring and management attention are on incoming deals, staffing, project estimation, and hourly developer costs. There’s margin in selling engineering hours/days/months, but nothing like the eye-popping per-customer margins of repeatable software. Investment in truly repeatable/ scalable products is put off for just this quarter (and then next quarter and the one after that) to generate current cash for the latest project.

So “who decides” and “how do we manage customer requests” is a Board-level issue tied to eventual financial exits. IMHO, sales-led and product-led companies have strongly opposing models for how the company scales and makes money. And individual sales teams can lower the total market value of a company by driving commitments on a few big-ticket promises that undercut whole-market strategic work. I claim that companies can’t succeed both as product-first and professional-services-first.

Solving the Wrong (But Apparent) Problem

Most of my CPO coachees have been through a wave of Sales/Solutions insistence on more visibility and input into the prioritization process. I observe that neither side is asking for the right thing, or responding to the real underlying issue.

Let’s start from the (unfairly oversimplified) Sales/Solutions view that the company’s request process is broken: that the request process should deliver a “yes” 80% or more of the time. That product management and engineering agree, but aren’t smart enough or motivated enough to do it. That Sales and Customer Success have to lean in, inspect the process, chase a bunch of critical customer requests, and figure out where it’s broken — i.e. do Product’s job for them.

Sales/Solutions asks for more frequent updates and more visibility into the roadmap. Product dutifully presents ever-more-detailed roadmaps and plans, quarterly and then monthly and then weekly and then links to the live documents.
- But the content doesn’t change very often, with major work still taking weeks/months and only a few small customer-visible improvements getting into production each sprint. Sales/Solutions still doesn’t see their latest batch of demands showing up in the roadmap. What they really want: urgent customer needs appearing on next week’s roadmap…
“We need someone to sit in on sprint planning and prioritization. That must be where new requests are considered and rejected.”
- But sprint planning is in engineer-speak, mostly wrangling over which few tickets go into next week’s sprint. Lots of discussion about estimation, dependencies, technical debt, work assignments, test automation, design handoffs. Sales-side folks are frustrated and bewildered that their specific item doesn’t come up for extended discussion/argument. Product/Engineering seems to be wasting time on trivial stuff….
“We need an SLA with Product that all requests get a response within 2 business days.”
- This can’t last more than a few days. Even with the entire product management staff putting their full effort into serious analysis and validation of incoming requests, they can’t keep up. Or work through the backlog. And by the end of the week, there’s a hue and cry about abandoning engineering deliverables, cross-functional coordination, launch prep, customer roadmap presentations, pricing, sprint demos, competitive analysis, design reviews, quarterly revenue and headcount planning… while each submitter is thinking about their one item, the cumulative impact is an avalanche.
“Product management should attend the weekly pipeline meetings and identify which deals need early product/engineering visibility.”
- Slightly better, but I’ve sat through hundreds of hours of sales pipeline reviews and gleaned little. It’s the flip side of sprint planning: hours of quick-step updates on dozens of deals, with emphasis on sales stages and buyer qualification (40%? 60%? Do we know who’s on the RFP committee? T&Cs? Influencers?) It lacks the use case details and technical background that product managers would need. These are handy for identifying the top N deals (usually covered first), which helps deflate the claim that 35 different deals are each the largest in their region. A 15-minute chat with someone in Sales Ops gets the same information, but without the face time that shows engagement.
“We need Product/Development representation on the deal desk, which reviews the largest or most strategic in-flight opportunities.”
- Better: a few opportunities, pre-sorted based on size by Sales. With 5 or 8 deals that have board-level visibility — and fewer people around the table — there’s a chance to ask hard questions and get a few weeks ahead of executive escalations. But these almost always need extensive side conversations and deeper dives, since the essential product facts aren’t presented and may not yet exist. If the VP Product attends on behalf of the larger product team, this is mostly delegating to the right person.

Finishing the thought, I haven’t seen much success when we assume that the feature request process is unintentionally broken. At best, this turns product managers into current-quarter technical sales support: not the job we need or hired them for. And a top contributor to product management churn. (“If we’re not going to set product strategy, make hard decisions, and ship products that lots of customers love… then I can look for a company will let me.”)

Instead, we’re probably getting the right outcome: only a handful of new things committed or added to roadmaps, with the vast majority declined or ignored. But neither group sees this as a win. Hard to be satisfied when one side expects order-of-magnitude more productivity/responsiveness and the other side is unwilling (or not allowed or too polite) to definitively say NO several times a day.

Focusing on Organizational Reward Structures

If this is so common at B2B/enterprise companies (and elsewhere), solutions can’t just be about yelling at each other, frequently replacing people, or writing ever-more-prescriptive process documents. The two groups have IMO opposing goals and reward systems.

We pay sales teams to close big individual deals (and fire them if they don’t). We reward current-quarter thinking. (“What would it take to get you to sign today?”) We fly the top sellers to President’s Club in Fiji. Expecting groups to act against their incentives is insane.

So imagine that we’re willing to make some really hard decisions at the C-level to become a low-friction/high-velocity/single codeline/repeatable product company with less and less dependence on internal integration and success teams. (If we really want to be a professional services firm, we don’t need product managers at all; instead, project managers and development teams that are redeployed at the end of each project.)

Some structural and compensation changes might include:

Sales teams get 100% commission relief on existing standard products, less 200% of the paid integration/consulting work that we do ourselves. (e.g. a $150k deal with $30k of services and customization is comped at $90k)
If we fund outside development from license revenue, that has to be repeated every year to maintain/support/adapt the contract work. (e.g. if $40k out of a $400k deal goes to a third-party developer in year 1, they also get $40k in years 2, 3, 4, 5…) The outside team is responsible for all customer-requested changes and keeping this work compatible with upcoming product releases. When the customer eventually cancels, ARR stops and outside maintenance is finished.
Integration/success teams are measured on fast project completion (aka “time to value”) rather than maximizing billable hours. They get a bonus for handing off custom work to approved third party consultancies. “Who can we give this work to, so we can manage the next opportunity?” becomes more important than “How much can we charge for this?”
Each product manager is the official liaison to Product/Development for one major deal. Sales/Solutions makes the list at the beginning of each quarter, and the CPO assigns those to the most appropriate product manager. (E.g. in a company with 6 product managers, Sales names no more than 6 major deals, with no mid-quarter swaps.) Product managers get in early, keep context, and run out ahead of last-minute commitments or technical surprises. Some deals take several quarters to close, so the same product manager stays on it.
Exec teams get exactly two “this is the most important deal of the quarter” magic tokens, given to the CEO at the start of the quarter and collected by VP Engineering or VP Product when the CEO and CRO escalate something new versus the plan of record. Handing over those physical tokens keeps us from forgetting and using the same two tokens twelve times.

Sound Byte

In my experience, enterprise-focused software companies need to be either “one deal at a time” consultative service firms or scalably repeatable product firms. Product management often takes the rap when single-deal-focused Sales/Solutions groups run headlong into single-codeline-scaling economic models. Executives should see the pattern, and work on C-level alignment rather than individual blame.