Problem Definition and Framing Questions

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

For the design team: "Search results feel irrelevant to users, and we don't yet know whether the cause is our outdated ranking signals, a design or discoverability issue, or something else; we want to identify the dominant cause and improve perceived relevance within [N] weeks." For executives: "Search relevance issues may be costing us engagement; we're investigating root cause now and will have a scoped fix plan within [N] weeks." Same underlying problem, different altitude and different information each audience actually needs to act on.

Structured elaboration

The design-team version needs enough specificity to guide investigation: it names that the cause is unconfirmed (avoiding the trap of asserting "outdated ranking signals" as settled, since that was engineering's theory, not a validated finding) and gives the team something to test against.

The executive version needs business framing and a commitment, not investigative detail: executives generally don't need to know whether the candidate cause is ranking signals or a discoverability issue, they need to know the business impact is being taken seriously and when they'll get a real answer. Including engineering's specific technical theory in the executive version invites a premature commitment to a fix nobody has confirmed yet, and it gives a busy executive a detail they can't act on.

Worked example

If the original brief's inputs turn out to conflict, customers say results are irrelevant, engineering says ranking is outdated, product wants more engagement, and there's no formal measurement yet, both rewritten versions deliberately do NOT pick a side on which input is correct. Instead they state the shared fact (search relevance is a live concern with unconfirmed cause) and commit to finding out, which is honest given that no measurement exists yet to confirm any of the three inputs' theories.

Trade-offs and pitfalls

The risk in writing two versions of the same statement is that they drift into actually describing two different problems if not written carefully from the same underlying facts; keeping both versions traceable to the same baseline problem (search relevance concerns, cause unconfirmed) is what prevents the executive version from over-promising or the design-team version from under-specifying. The other pitfall is defaulting to the technical version for both audiences, which is a common failure when the person writing the statement is closer to engineering than to executive communication; the tell is a statement executives read but can't act on, because it's full of implementation detail they have no way to evaluate.

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.

Direct answer

A lightweight governance model needs three things: clear roles (who owns problem definition for a given effort, and who reviews it), a small number of decision gates tied to when work actually gets committed (not extra process layered on top of existing ones), and a short set of required artifacts at each gate, kept minimal enough that teams don't route around them.

Structured elaboration

Roles: an owner, typically the lead on the effort, accountable for the problem definition being complete before proceeding; a reviewer, someone outside the immediate team (a peer lead, a cross-functional partner) who checks the definition for the gaps a close-in owner might miss, particularly an unstated assumption or a missing constraint. The reviewer role is deliberately lightweight, a 15-minute check, not a full second discovery pass, since a heavyweight review process is exactly the kind of thing multiple teams will start skipping under deadline pressure.

Decision gates: two, tied to existing checkpoints rather than new ones: at the point work gets added to a team's committed roadmap (requiring a completed problem brief and reviewer sign-off), and at the point a solution direction is chosen (requiring the hypotheses and success criteria fields to be filled in, confirming the direction ties back to a specific, testable claim rather than being picked on instinct).

Required artifacts at each gate: at the roadmap-commitment gate, the problem brief (evidence, affected users, impact estimate); at the solution-direction gate, the hypotheses and success criteria that justify the chosen direction. Kept to these two, rather than a longer list, because each additional required artifact is another point where a team under pressure is tempted to shortcut the process.

Measuring adherence: track the share of roadmap-committed efforts with a reviewer-approved brief before commitment (the leading indicator), and separately, sample a subset each quarter for whether the review caught anything substantive (a gap, an unstated assumption) versus rubber-stamping everything that comes through, which distinguishes a genuinely functioning review from a check-the-box formality.

Worked example

If the quarterly sample shows the reviewer step caught a real, substantive gap (a team's brief didn't account for a legal constraint the reviewer, from a different part of the org, happened to know about) in 1 of 8 sampled cases, that's evidence the review step is doing real work, not just adding a signature requirement; if it catches nothing across a full quarter of sampling, that's a signal the review has become a formality and needs either a different reviewer assignment or a more specific review checklist.

Trade-offs and pitfalls

Cross-team governance risks becoming exactly the bureaucracy it's meant to prevent if the gates multiply over time, a common failure mode where each new incident prompts "let's add a check for that" until the process is heavier than the problem it solves; resisting that drift, and periodically removing checks that aren't catching anything, is as important as adding the checks in the first place. The other pitfall is a reviewer role that's purely advisory with no actual teeth at the gate, in which case teams under deadline pressure will proceed regardless of the reviewer's input, and the governance model exists on paper without actually shaping behavior.

Direct answer

Ship the web version on the six-week timeline as planned, and for mobile, ship the smallest set of changes that avoids leaving the two platforms visibly and confusingly inconsistent, deferring the full redesign to a follow-up phase. The problem statement makes the trade-off explicit rather than silent: "we are prioritizing a complete redesign on web within the six-week window, and a scoped-down update on mobile to avoid inconsistency, with the full mobile redesign following in phase two, because engineering capacity does not support both platforms simultaneously in this window."

Structured elaboration

Scope boundaries: define explicitly what mobile gets in this phase (the same underlying search logic and results ranking as web, but not the new visual layout) and what it doesn't (the redesigned card layout, the new filtering interface), so engineering, design, and stakeholders share the same understanding of what's actually shipping on each platform.

Phased delivery approach: web ships the full redesign on schedule; mobile ships a minimal-viable-change version, updated results data and ranking behind the existing mobile layout, in the same window, with the mobile visual redesign following as an explicitly scheduled phase two rather than an open-ended "later."

Risks: users switching between web and mobile may notice the visual inconsistency during the gap between phases, which is a real but bounded cost, worth naming explicitly rather than discovering through user complaints; and phase two needs a committed timeline and owner, or "we'll get to it" phases have a well-documented tendency to slip indefinitely once the pressure of the original deadline is gone.

Worked example

The problem statement communicated to stakeholders: "Web search results redesign ships on the original six-week date. Mobile ships the same underlying search improvements (data and ranking) within the same window, on the existing visual layout, with the mobile visual redesign following in phase two, targeted for [specific date] and owned by [specific person]. This avoids either delaying the entire launch to accommodate mobile engineering capacity, or shipping a visually inconsistent experience with no plan to resolve it." Naming a phase-two date and owner up front is what prevents "phase two" from becoming a phase that never happens.

The same scope-boundary discipline applies to a "quick" UI update that can't touch the backend data model (a checklist of what must be clarified up front: which fields are display-only versus backend-dependent, what trade-offs a display-only fix accepts) and to a legacy design-system migration spanning 200-plus component variants (a phased migration with a rollback strategy and acceptance criteria defined per phase, not just at the end).

Trade-offs and pitfalls

The main risk in this kind of phased approach is that phase two loses priority once the phase-one pressure is gone and a new deadline arrives for something else; committing to a specific date and owner for phase two at the same time you commit to phase one is what protects against that, though it isn't a guarantee. The other pitfall is defining the phase-one mobile scope too narrowly to be worth shipping at all, in which case the better call might be a short, explicit delay on mobile alone rather than a phase-one release so minimal it doesn't move any of the metrics the redesign was meant to improve.