Problem Definition and Framing Questions

Direct answer

Before committing to a custom build, separate the client's stated request from the underlying problem it's meant to solve, and check whether a narrower, more general solution already on the roadmap (or a small configuration change) would satisfy the actual need. If it does, build the general version; if the need genuinely requires something no other customer would use, weigh the maintenance and fragmentation cost explicitly against the deal's value before deciding to build, generalize, or decline.

Structured elaboration

Evaluate the true underlying problem: ask the client (or their account team) what specific outcome the requested feature is meant to produce, not just what the feature is. A request for "a custom export format" might really be about integrating with one specific downstream tool the client uses, which could potentially be solved by a more general, already-planned integration rather than a one-off export format built just for them.

Test whether a narrower solution works: check the request against the existing roadmap and against other customers' requests; if two or three other accounts have asked for something adjacent, that's a signal the need generalizes and a broader feature is justified, not a one-off; if it's genuinely unique to this one account, that's a different signal.

Decision criteria: (1) does this underlying need show up in other customers' requests, even if not phrased identically, meaning it's a generalizable need rather than one account's idiosyncrasy; (2) what's the ongoing maintenance cost of a custom integration versus a general feature, since custom code paths tend to accumulate cost over years, not just at build time; (3) how does the deal's value compare to the maintenance cost, estimated honestly rather than optimistically; (4) does declining put the deal, and the relationship, at genuine risk, or is there room to offer an alternative the client would accept.

Mitigation options if the answer isn't a clean build-or-decline: a time-boxed custom solution with an explicit sunset date, revisited once usage data shows whether other customers adopt something similar; or a configuration-level solution within the existing general feature, rather than genuinely custom code, which avoids the long-term fragmentation cost even if it takes slightly longer to build initially.

Worked example

If the account team's conversation reveals the client's real need is "get transaction data into their existing accounting software automatically" rather than literally "a custom export format," and two other accounts have separately asked about accounting-software integration in the past two quarters, that's strong evidence the underlying need generalizes; the recommendation becomes building a general integration (serving three accounts' real need) rather than the client's originally-requested custom export (serving only one).

Trade-offs and pitfalls

Generalizing a request into a broader feature takes longer to build than the narrow custom version, which risks missing the specific client's deadline even though it produces a better long-term outcome; when the deal timeline is tight, an explicit trade-off conversation (short-term custom bridge, longer-term general replacement) may be needed rather than a clean either-or choice. The opposite pitfall is defaulting to "always generalize" as a reflexive policy, which can mean under-serving a genuinely large, strategically important deal whose specific need really doesn't generalize and is worth the maintenance cost on its own merits.

Direct answer

Rather than building the dashboard as specified, lead with a short discovery conversation aimed at one question: what decision are you trying to make, and how would you make it differently depending on what the data shows? A request "for visibility" almost always has a real decision hiding behind it, and surfacing that decision usually reveals a narrower, faster deliverable than a full dashboard.

Structured elaboration

The questions to ask, in order: (1) "What decision would you make differently if you had this data, versus if you didn't?" This is the single most important question, because if there's no clear answer, the request may genuinely be for situational awareness rather than a decision, which changes what "done" looks like. (2) "How often would you check this, and what would trigger you to act on what you see?" This distinguishes a need for a live dashboard from a need for a periodic report or even a one-time analysis. (3) "What's the smallest version of this that would already tell you something useful?" This surfaces whether a full dashboard is actually needed or whether a single number, refreshed weekly, would answer the underlying question.

If the VP's (vice president's) answers reveal a genuine, recurring decision (say, "I need to know weekly whether to reallocate budget between two initiatives based on their relative performance"), the request reframes into a much narrower, well-scoped deliverable, two specific metrics compared side by side, rather than an open-ended dashboard. If the answers reveal no specific decision, the honest reframe is proposing a lighter-weight alternative, such as a monthly summary email, and explaining why: building a full interactive dashboard for situational awareness alone is a larger and more expensive commitment (both to build and to maintain) than the underlying need justifies.

Worked example

Discovery timeline: a 30-minute conversation using the three questions above, followed by a one-page problem statement circulated back to the VP for confirmation before any build work starts ("I understand the need is: decide weekly whether to reallocate budget between initiative A and B, based on their relative cost-per-acquisition; is that right?"), rather than starting a multi-week dashboard build on the original vague request.

The identical three-step move, surface the actual intent, propose evidence to test the assumption, offer a non-dismissive path forward, applies just as well to a peer stakeholder as to a VP: when a stakeholder insists "users want a carousel on the homepage because competitors use it," the same sequence surfaces what problem the carousel is meant to solve, proposes a cheap way to test whether that problem is real, and avoids either building the carousel uncritically or dismissing the idea outright.

Trade-offs and pitfalls

Pushing back on a VP-level request "for visibility" carries real political risk if handled poorly: framing it as "I don't think you need this" reads as dismissive, while framing it as "help me understand the decision this supports, so I build the right thing the first time" reads as diligence. The pitfall to avoid is building the originally-requested dashboard anyway to avoid the conversation; that path optimizes for avoiding short-term friction at the cost of shipping something that may not get used, which is a worse outcome for both the requester and the team that built it.

Direct answer

Rather than picking a side between "ship fast for the demo" and "protect platform stability," surface what each group is actually optimizing for underneath their stated position: the sales leader needs a credible story for a specific deal, and the product manager needs to protect a reliability commitment already made to existing customers. Once both underlying needs are explicit, the real design space is usually wider than "ship it or don't," and a path exists that serves both without either group having to fully back down.

Structured elaboration

The reframe has three moves. First, separate the stated position from the underlying need: "ship feature X for the demo" is a position; "I need this specific prospect to see the product can do Y before their decision deadline" is the underlying need, and the two aren't identical, since there may be other ways to demonstrate Y. Second, do the same for the other side: "protect platform stability" is a position; "we've committed to an uptime standard for existing customers and can't risk a regression before that's proven safe" is the underlying need. Third, once both needs are explicit, look for options neither position alone considered: a scoped, feature-flagged demo environment that shows the capability to the specific prospect without shipping to the full platform, for example, serves the sales leader's actual need (a credible demo) without touching the product manager's actual concern (platform-wide stability).

Artifacts and language: write the two underlying needs side by side in a single shared document (not two competing proposals), and frame the conversation explicitly as "here's what I heard each of you actually need, tell me if I've got that right" before proposing any path forward. This does two things: it makes both sides feel heard on their actual concern rather than their stated position, and it turns the conversation from a negotiation over whose priority wins into a joint problem-solving exercise.

Worked example

If the scoped demo-environment option isn't feasible (the capability genuinely can't be faked convincingly without the underlying platform change), the shared-need framing still helps: it turns "should we ship this or not" into "given that the prospect's deadline is real and the stability commitment is real, what's the minimum platform change that satisfies both," which is a more solvable question than the original either-or framing.

The same reframe-to-shared-objective move generalizes beyond sales-versus-product: when growth wants weekly active-user growth and finance wants higher average revenue per user, the two stated positions are genuinely different metrics, but the underlying shared objective, usually sustainable revenue growth, is discoverable with the identical three-move sequence used above.

Trade-offs and pitfalls

This reframe takes real facilitation time, a 30-minute conversation with both stakeholders rather than a quick decision made unilaterally, which isn't available for every conflict; on a genuinely low-stakes disagreement, spending this much process on it is its own kind of waste. The other pitfall is using the "shared frame" language as a way to avoid making an actual call: at some point, if the two underlying needs genuinely can't both be served, someone still has to decide, and the reframe should inform that decision, not substitute for making it.

Direct answer

Five criteria: business impact if unaddressed, urgency (real deadline versus perceived), how many users or accounts are affected, whether the request is reversible if wrong, and whether the underlying problem is even confirmed with evidence yet. Weighted together, these separate requests that genuinely need fast-tracking from ones that feel urgent but aren't.

Structured elaboration

Business impact if unaddressed: what happens if this request sits for two weeks versus two months; a request whose cost grows the longer it's unaddressed (an active revenue leak) ranks differently than one whose cost is flat over time (a nice-to-have improvement).

Urgency, real versus perceived: does this have an actual external deadline (a contractual date, a regulatory requirement) or is the urgency coming from whoever's asking feeling strongly about it; the two are easy to conflate and only one of them should move a request up the queue on its own.

Scope of who's affected: one account, a segment, or the whole user base; broader impact generally, though not always, deserves faster attention than a narrow one, all else equal.

Reversibility: a request that's cheap to try and easy to undo if wrong can be fast-tracked with less certainty required up front; a request that's expensive or hard to reverse needs more confirmation before jumping the queue, regardless of how urgent it feels.

Confirmed versus assumed: has the underlying problem actually been checked against data, or is this still at the "someone reported it" stage; an unconfirmed request shouldn't skip the line ahead of confirmed ones just because it arrived more recently or more loudly.

Weighting: business impact and confirmed-versus-assumed carry the most weight, since they answer "is this real and how much does it matter," while urgency and reversibility function more as tie-breakers between requests that score similarly on the first two.

Worked example

Two requests arrive the same week: one from a single enterprise account demanding a specific integration "by Friday" (high perceived urgency, but affects one account, reversibility is low since building it commits ongoing maintenance, and the underlying need hasn't been confirmed against other accounts' needs); another flagging that a payment-confirmation email hasn't been sending for three days, discovered through a support-ticket spike (high business impact, growing the longer it sits, affects all users hitting that flow, and it's confirmed with data). Applying the rubric ranks the payment-email issue above the single-account integration request, even though the account's request arrived with more explicit urgency language attached to it.

Trade-offs and pitfalls

A five-criteria rubric applied mechanically, without judgment, can produce a technically-correct ranking that still feels wrong to the people involved, particularly when a request from a loud or senior stakeholder scores lower than the rubric would suggest they expect; the rubric is a decision aid that should be explained transparently when a ranking surprises someone, not a black box used to avoid a difficult conversation. The other pitfall is treating the weighting as fixed forever; a rubric calibrated for a stable-state product may need re-weighting during a genuinely different period, such as right after a major incident, when confirmed impact should temporarily dominate even more heavily than usual.

Direct answer

Headline states the problem and its business impact in one line; the three bullets cover the current state, the desired state with its timeframe, and the specific decision or resource being asked for. The whole slide should be readable, and the ask actionable, well within the 90 seconds an executive typically gives a single slide.

Structured elaboration

Headline: a single sentence naming the problem and why it matters in business terms, not a vague title. "Checkout abandonment is costing an estimated [$X] per month, concentrated in the shipping-cost reveal step" is a headline an executive can act on; "Checkout Improvements" is not.

Bullet 1, current state: the specific, quantified baseline, in one line, no supporting detail the executive doesn't need at this altitude ("Abandonment at the shipping-cost step is 31%, up from 22% two months ago").

Bullet 2, desired state and timeframe: what success looks like and by when ("Target: reduce to 24% within one quarter, based on early experiment results").

Bullet 3, the ask: the specific decision or resource needed from the executive, stated as an actual ask, not a status update ("Requesting approval for a two-week experiment testing earlier cost disclosure, no additional headcount required"). This is the part most commonly missing from executive slides that read as informative but leave the executive unsure what they're actually meant to do with the information.

Worked example

Headline: "Checkout abandonment at the shipping-cost step is costing an estimated [$X] per month, calculated as affected sessions times the abandonment-rate gap times average order value, and has worsened over the past two months." Bullet 1: "Abandonment at this step rose from 22% to 31% since early [month], concentrated among first-time buyers." Bullet 2: "Target: back to 22% within one quarter, informed by an early low-cost experiment already showing promise." Bullet 3: "Requesting sign-off to scale the experiment to 100% of traffic; no additional budget or headcount required, two-week rollout." An executive reading this in under 90 seconds knows what's wrong, how big it is (with the dollar figure traceable to a stated formula rather than asserted on its own), what "fixed" looks like, and exactly what they're being asked to approve.

Trade-offs and pitfalls

The most common failure is treating the slide as a status update rather than a decision request, ending with a description of the problem and the current investigation rather than a specific ask, which leaves the executive informed but with nothing concrete to do, and often means a second meeting is needed just to get to the actual decision. The opposite failure is overloading the slide with investigative detail (methodology, alternative hypotheses considered and ruled out) that belongs in a supporting document, not the headline slide; if an executive wants that detail, they'll ask, and a slide should be built to answer that follow-up rather than to pre-empt it by including everything up front.