Product planning

Help decide what to build and make the chosen outcome precise enough to implement. Follow the user's scope and existing product decisions; recommendations are not automatically approved requirements.

Establish context

Read the relevant project instructions, product brief, requirements and existing research if available. Identify the target audience, problem, product stage, region, constraints and requested deliverable. Inspect only the code or designs needed to understand an existing feature. A new project can start with a concise brief; do not require a repository or a large documentation system.

Proceed with stated, reversible assumptions. Ask only about missing choices that materially affect the outcome, such as the intended customer or business model. Keep unrelated work moving.

Research an opportunity

• Frame the decision and evidence needed before searching. Compare the relevant direct competitors and substitutes using consistent criteria.
• Browse current primary sources for features, prices, policies and platform constraints. Record URLs, dates, market and confidence. If live research is unavailable, label the result as hypotheses and identify what needs verification.
• Distinguish observed facts, first-party claims, user feedback and your inference. Reviews suggest hypotheses; they do not establish market size or represent every customer.
• Consider the complete service experience: onboarding, core value, trust, support, failure recovery and retention. For a marketplace, examine both supply and demand and the initial geographic/category focus.
• Recommend a scoped opportunity with tradeoffs, assumptions to test and an experiment. Do not invent interviews, demand, revenue, competitors' private metrics or regulatory conclusions.

Define the selected feature

Use the project's feature-spec format if one exists; otherwise use the brief outline.

Map the primary journey and meaningful alternatives: entry, completion, cancel/back, failure, retry and cross-role consequences. Define ownership, states, permissions, data changes, integrations, compatibility and acceptance criteria where relevant. Identify what is outside scope. Separate decided requirements from proposals and unresolved decisions.

Break the feature into demonstrable increments. Tie each increment to a user outcome and testable acceptance criteria. Prefer an explicit dependency over an invented answer. Do not select new frameworks or infrastructure without a task-relevant reason.

Deliver

Provide the research or feature brief requested, recommendation and rationale, evidence links, assumptions and actionable open decisions. Update an existing authoritative document when authorized; avoid duplicate specifications. Product success criteria belong in the brief even if analytics tooling will be chosen later.

This workflow does not start implementation, contact participants, publish surveys or spend money unless the user requests those actions. If implementation was also requested, continue within that scope once material requirements are sufficiently resolved.