Turn an ambiguous brief into one reviewable delivery slice

While shaping this portfolio, requests such as “make the site useful for founders, hiring teams, and partners” described an ambition, not an executable scope. The same ambiguity appears when a product brief lists features before naming the user, current flow, essential outcome, or owner of acceptance.

The exact plan depends on the product and team, so uncertainty must remain visible. A useful first scope needs a real current-state example, a fixed-versus-negotiable constraint boundary, a named reviewer, and an observable acceptance signal; otherwise a confident estimate would be guesswork.

• Estimate directly from a feature list before the problem and current flow are understood.
• Hide unknowns inside a polished proposal and let them surface during implementation.
• Redesign the whole product before agreeing on one core flow and its acceptance signal.

Capture the goal, user, current state, essential outcome, constraints, and collaboration shape first. Turn those inputs into a problem statement, a temporary suggested path, one first useful step, open questions, and meeting preparation. Only then define one delivery slice with explicit inclusions, exclusions, dependencies, ownership, and a review signal.

The current Project Fit tool produces an editable brief and only attaches verified related cases when the entered context matches them; it does not submit the brief or manufacture certainty. The Process page carries that brief into scope, observable progress, and handoff. The learning is that an explicit unknown is useful scope input, while a guessed answer becomes hidden delivery risk.