Ship features users love

You own the feature roadmap and need to connect user feedback to shipped features, keep eng and design aligned, and prove you're solving real problems. This guide takes you from research to a delivered Plan, starting with a single Brief.

Who this doc is for

You're a product manager turning user problems into shipped features. You want your thinking — the problem, the evidence, the success metric — to travel with the work so eng and design build the right thing. Start by writing a Brief that captures the user problem and how you'll know it's solved.

Pre-flight checklist

Before you start:

• Gather your user research, feedback, or usage data, even if it's informal. The Brief is stronger when it points at evidence.
• Get clear on what you're solving: the user problem and the business metric it moves.
• Know who's building it — the engineers and designer you'll bring in to review.

Your first week

A concrete path from a user problem to an aligned plan:

1. Create a Brief that captures the user problem, the success metric, and the scope. Name the minimal lovable version, not the wishlist.
2. Link it to your user research, hypotheses, or market learning so reviewers can see your thinking.
3. Invite engineering and design to review and surface risks early. You're done when the team agrees on the problem and roughly what "solved" looks like.

Post-creation next steps

Once the Brief exists:

1. Link your Brief to user research — a Goal, related Briefs, or external links.
2. Define success metrics clearly. Activation, retention, CSAT — pick the one this feature is meant to move and attach a Metric.
3. Review with engineering for feasibility and an estimated scope.
4. Review with design. Decide: is design exploration needed before eng starts, or can design iterate in parallel? Let the design risk drive the answer — novel surfaces need exploration first; familiar patterns can run in parallel.
5. Generate a Plan once alignment is solid.
6. Deliver the Brief to a pull request — a Cloud Agent can ship it without an engineer at the keyboard — then track progress toward your success metric as the work ships.

Feature depth

Go deeper on the artifacts a PM leans on most:

• Briefs — writing PM-focused Briefs with a user problem, success criteria, and explicit non-goals.
• Plans — balancing design, eng, and PM work in a single Plan.
• Goals — connecting feature work to a business metric.
• Delivering Briefs — shipping a ready Brief to a GitHub PR and tracking the result.
• Cloud Agents — handing delivery to the cloud when the work doesn't need an engineer at the keyboard.
• Initiatives — grouping a stream of related Briefs under one outcome.

Sample first-week workflow

1. Monday: gather user feedback and research.
2. Tuesday: write the Brief capturing the user problem and success metric.
3. Wednesday: sync with the eng lead on scope and risk.
4. Wednesday: sync with the designer on timeline and dependencies.
5. Thursday: generate the Plan; identify whether design is on the critical path.
6. Friday: begin tracking the metric or set up measurement.

Common pitfalls

"How detailed does my Brief need to be?" Include the user problem, the success metric, and the minimal lovable product. Link to research if you have it. Detail beyond that is usually waste.

"Should design and eng work in parallel or in sequence?" It depends on your design risk. Outline the risk in the Brief and use the Plan to show the sequencing you chose.