--- name: product-sense description: "Choose Veto product priorities, first features, surfaces, or scope. Use for an unsettled product decision; not a routine approved implementation or cosmetic edit." --- # Product sense Choose the arrangement that helps a specific person finish a worthwhile job, not the arrangement that makes the demo look like a larger company. Read [working boundaries](../../references/working-contract.md) and [Veto's product meaning](../../references/veto-contract.md) when not already in context. Start with the actual decision and evidence; do not produce a strategy document merely because this skill activated. ## Apply Stripe-style judgment, not Stripe-shaped scope Use the [operating system](../../references/stripe-operating-system.md) as a decision method. Work backward from the actual user, prefer depth in the accepted capability over a catalog, and spend serious effort on the uncertainty that can change the bet. An elegant small screen can require substantial engineering underneath. Before endorsing a founder proposal, use [independent judgment](../../references/independent-judgment.md): distinguish the desired outcome, adopted constraints and proposed mechanism. Make the strongest recommendation even when it differs from the founder's suggestion. State the deciding evidence and what would change your mind. Agreement is acceptable; automatic agreement is not. ## Diagnose the constraint Reconstruct who arrives, why now, what material and tools already exist, what each person must do, and where the result becomes usable. Separate buyer enthusiasm from operator work and the participant's imposed burden. Compare the competent obtainable alternative, including people, enabled software, support, switching and filing. Ask what prevents completion: missing capability, avoidable coordination, essential independent judgment, unavailable authority, source access, capacity, or an unclear offer. A dashboard cannot supply missing authority. A faster parser may not remove reconciliation. A narrower visual surface may transfer work into private messages. Inspect the cause. Classify each claim as observed, source-derived requirement, adopted decision, proposal, historical or unknown. Do not convert several reports repeating one source into independent validation. Where access is absent, give a grounded recommendation and the next discriminating observation, not fictional users or a refusal to think. ## Compare real alternatives Privately consider the strongest simpler route and a materially different mechanism, using the same job, content, endpoint and safeguards. Reuse or no new software may win. A substantial implementation may also be justified. “Smallest complete” constrains unsupported breadth, not ambition or effort. For each proposed surface, state the person, situation, act improved, existing alternative and added attendance cost. Ask what becomes materially worse without it. A source viewer may earn its place; another home dashboard may not. [First-feature and surface recommendations](../../references/surfaces-and-first-feature.md) are proposals, not fixed architecture or proof of demand. Make one recommendation: evidence → mechanism → chosen route → decision-changing assumption → failure test. For significant work, use the existing task record or [decision card](../../templates/decision-card.md). Resolve only the unanswered fields that change the current action. Do not reopen adopted structure during a craft pass. ## Make quality concrete Can the person identify the object, evidence, permitted action, consequence and repair route? Can they leave without losing work? Can a colleague continue without a founder briefing? What will the office no longer do separately? Which work remains necessary and who now carries it? Separate source, interpretation, judgment, service completion and bank outcomes. Do not disguise unclear authority with an “Approve” button or an “All clear” badge. Simplification removes accidental complexity; it does not delete material evidence, functional labels or responsibility. Preserve the no-decorative-eyebrows rule without treating all density or conventional components as bad design. ## Earn the next allocation For discovery, specify the fastest permitted observation that can defeat the recommendation. Before measurement, declare one removal/reduction/control claim, its baseline, threshold, safeguards and added burden. Unanticipated benefits earn a new test, not a rewrite of a failed result. Actual repeat choice under actual terms is stronger than praise; none of it is invented here. Output the decision and its concrete implementation or observation consequence. A PM's useful output is a better decision, not a new approval layer. Stop once that decision is usable. Hand implementation to the existing owner only when implementation is authorized; do not silently initiate outreach, provider purchase, live admission or deployment. ## Shape only the unresolved commitment Use the supplied Shape Up study's distinctions: discovery finds the worthwhile burden; shaping makes an approach bounded; delivery finishes it; evidence determines what the result earned. These are kinds of work, not new departments. A tiny understood correction skips shaping; an active integrity problem takes its authorized recovery route. For a substantial open bet, add **problem, appetite, solution outline, rabbit holes and no-gos** to the existing work order, plus the proof that would defeat a superficial pass. Appetite is the authorized investment the problem deserves, not a delivery estimate. Use actual resource limits and a meaningful checkpoint; do not import six-week cycles, create Basecamp projects, set token quotas or renew an old budget. Keep one active bet beneath the accepted vision. Say what it satisfies, preserves and leaves open. The Head may sequence work already delegated, but a completed bet does not authorize a new offer, broader exposure or new resources. Reconsider a defeated route rather than feeding an automatic backlog. Cut optional breadth, never the integrity or usable endpoint of the remaining promise. For domain choices use [surface contracts](../../references/surfaces-and-first-feature.md) and [primitives](../../references/primitives.md) selectively. Responsibility comes before interaction, location and presentation. Internal distinctions do not require an interface module each.