strategize

Structure the brief around context, gap, opportunity, goals, constraints, guiding principles, key assumptions, and proposed Phase 1 scope. Ask clarifying questions mapped to each section rather than guessing, and document what you explicitly chose not to explore.

Use five foundational questions: Is the problem real and severe, who exactly has it, is the chosen solution form factor right, is the feature set validated against demand, and what competitors or workarounds already exist. Each question has a decision gate that feeds the next.

Establish problem severity through evidence of frequency, severity, and trajectory using desk research, intercept interviews, and surveys. Then define measurable hypotheses in the form: if we take an action, then an outcome occurs because of a stated assumption.

No, it synthesizes existing research rather than conducting primary research. When the foundational questions reveal knowledge gaps, it hands off to a research skill for interview scripts, usability tests, and surveys, then synthesizes the findings back into the strategic frame.

The main anti-patterns are building for the wrong audience, solving a non-problem, feature bloat from stakeholder wish lists, competitive blindness, and premature commitment where wireframes exist before the problem is validated. Each maps to a skipped foundational question.

Skip it when the task is designing UI flows, defining visual identity, or writing implementation specs, since those belong to downstream skills. It also should not make final tactical prioritization decisions, which belong to execution teams and stakeholders.