Skip to content

Product SOP

Role: Product Manager
Prerequisites: Complete the Meta SOP first
Visual reference: Whimsical Flowchart

Your priorities: the Feature Readiness Dashboard, opening the initial FE PR, and testing product quality on finished full-stack tickets. You are also responsible for creating the first pass of all full-stack tickets, managing the backlog for each developer, and running your daily/bi-weekly pod calls. You are not writing specs. You are building the first version, creating the work for engineers, and shepherding features to customers.

PM-Led Roadmapping

You own the roadmap for your product area. This means you conduct the research — customer conversations, competitive analysis, data analysis — and then present your proposed epics to leadership (Tom, John, and Chris) for collaborative review and approval before development begins.

Leadership does not hand you a roadmap. You build it, defend it, and iterate on it based on evidence.

The Feature Readiness Dashboard

This is the single source of truth for what the team is working on. Every Epic and Outcome lives here. Engineers, Design, and QA all take their work from it.

Link: Feature Readiness Dashboard

Your responsibilities:

  • Keep every Epic and Outcome up to date — status, owner, current stage (backlog / in progress / MVP / Alpha / Beta / GA)
  • Write Outcomes, not tasks. An Outcome describes what changes for the customer, not how to build it. Engineers figure out the how.
  • Flag when something is blocked or at risk before it becomes a problem
  • Prioritise ruthlessly — if something isn't in the top of the backlog with a clear outcome written, it will not get built

What a good Outcome looks like:

"A user can export their contact list to Salesforce in one click from the People table, with a confirmation of how many records synced."

What a bad Outcome looks like:

"Build a Salesforce export button on the People table that calls the api-commercial endpoint and syncs records."

The first tells the engineer what to achieve. The second tells them how to build it — that's their job, not yours.

The No-Slop Rule

No AI-generated content meant for another human to consume gets published without your manual review. This applies to everything: Linear tickets, PR descriptions, docs, Slack summaries. If a human will read it, you must review it first. Read it. Trim the filler. Sharpen the language. If it reads like a machine wrote it, rewrite it until it doesn't.

Cursor Rules for Ticket Creation

Add these two rules to your Cursor settings so every ticket and plan Cursor generates follows the right format.

Rule 1 — Planning a Linear ticket:

When asked to plan a linear ticket, ensure you include the following:
1. Detailed implementation instructions BASED ON THE RELEVANT CODE 
   STRUCTURE FROM REPOS
2. INCLUDE RELEVANT APIs to use to achieve all actions the 
   front-end enables.
3. Structured and concise enough to include in a linear comment to 
   a development agent to minimize mistakes or bugs and lead to 
   fastest correct implementation.
4. Output of your plan is ALWAYS in the style of linear comment 
   calling a development agent. It starts with 
   '@cursor implement the below plan in a new PR'

Rule 2 — Creating a Linear ticket:

When asked to create a linear ticket:
1. ALWAYS use this format: Description, User Stories (as a, I want 
   to, so that), Technical Requirements (including links and design 
   docs), Acceptance Criteria (given when then), Constraints
2. Epics are structured as: Epic > Subissues 1. backend and/or 
   data science and/or data engineering foundational work first > 
   Subissue 2. front-end > Subissue 3. Design
3. For front-end and design tickets DO NOT BE TOO TECHNICAL OR 
   VERBOSE, focus on the title, description, user stories, 
   acceptance criteria so that it's SUPER EASY TO DESIGN AND TEST 
   FOR A QA TESTER.
4. Put them into the Unified Product COM triage queue unless 
   otherwise instructed.

Creating High-Level Full-Stack Tickets

For every feature, you create the high-level tickets that engineers need to make the front-end functional. This is a two-step process: plan first, then create the tickets from the plan. All ticket creation happens via the Linear MCP in Cursor.

Step 1 — Plan the Tickets

Using the cred-wiki as architecture context, plan the full-stack 
work needed to make [feature name] functional.

Outcome: [paste the outcome from Feature Readiness Dashboard]

Keep it high-level — focus on what needs to exist for the user, 
not how to build it technically. Leave technical specs to the 
developer who picks it up. 

Group by: what's needed in each repo (dbt, model-api, 
api-commercial, web-commercial).
Show me the plan before creating any tickets.

Review the plan. Remove anything too technical — the developer will figure out implementation details. Keep each item focused on the user outcome it enables.

Read everything AI generates

All AI-generated content meant for humans must be read by you and slop cut down. Do not blindly ship Cursor's output as tickets. Read every ticket, trim the filler, sharpen the language, and make sure it reads like something a human wrote with intent.

Step 2 — Create the Tickets

Using the Linear MCP, create high-level tickets under 
[parent Epic / issue ID] based on the plan above.

Keep descriptions focused on user outcomes, not technical specs. 
The developer will refine the technical approach.
Assign to [developer name].

Assign tickets directly to the relevant developer. There are no sprints — each dev has a personal backlog. Priorities on an epic level per dev live in the Feature Readiness Dashboard.

Opening the Initial FE PR

For every front-end feature, you build the first PR — not a spec, not a Figma file, not a Linear ticket. A real PR with real code.

This is the most important thing you do in the delivery cycle. A well-scaffolded PR means the engineer can understand the intent immediately, knows exactly what needs to be wired up, and can start building BE tickets within an hour of picking it up.

How to Build the Initial FE PR

  1. Plan the UI in Claude first — before touching Cursor, let Claude suggest the UX and research competitors:
I'm building a front-end for this outcome:

[paste the outcome from Feature Readiness Dashboard]

First, research how competitors handle this type of feature — 
what UX patterns work well in similar B2B SaaS products?

Then plan the UX layout: what pages are needed, what the user flow 
looks like step by step, what components appear on each screen, 
and how the user moves between them.

Keep it focused on the user experience, not technical implementation.

Let Claude suggest the layout and competitor patterns first. Review, iterate, and refine until the UX flow makes sense. This is where you catch flow issues before any code is written.

  1. Bring the UX plan to Cursor — open Cursor with all five repos in your workspace (including cred-wiki) and plan the implementation:
Using the cred-wiki as architecture context, plan the front-end 
scaffold for the following outcome in web-commercial:

[paste the outcome from Feature Readiness Dashboard]

UX layout: [paste or summarise the layout from Claude]

Build the pages, flows, and UI components needed so the intent is clear. 
Buttons and interactions can be non-functional — the goal is a working 
skeleton that an engineer can take and wire up.

Use only existing Storybook components. Flag any components that don't 
exist in Storybook rather than creating one-off styles.
Show me the plan before writing any code.

Review the plan, then tell Cursor to implement it.

  1. Test it locally — does it look right? Can you follow the user journey? Fix anything obviously wrong with Cursor before handing off.

  2. Open a PR:

    • Title: [Feature] [outcome name]
    • Description: link to the Feature Readiness item, one paragraph on what this is trying to achieve and why

  3. Once you're happy with the PR, create all the full-stack tickets and assign them to developers — follow the Creating High-Level Full-Stack Tickets process above. The PR is your reference for what needs to be wired up.

  4. Hand off:

    • Simple features with clear UX: assign the PR directly to the Engineer
    • Complex or UX-heavy features: assign to Design first, they refine, then it goes to Engineering

  5. For complex features: host a dedicated 1-on-1 kickoff meeting with the assigned engineer to walk through the context, goals, and any nuance that isn't obvious from the PR and tickets alone. This is optional for simple features but strongly recommended for anything with multiple repos or non-obvious dependencies.

What You Do Not Do

  • Do not write a spec document before building the PR
  • Do not prescribe implementation details — describe the outcome, not the method
  • Do not leave review comments on engineer PRs — pull the branch locally and fix directly in code

Reviewing PRs

When an engineer hands a PR back to you for product review:

  1. Pull the branch locally — do not review from the GitHub diff
  2. Walk through the full user journey as a customer would
  3. Fix anything wrong directly in code using Cursor — copy issues, flow problems, missing states
  4. If something is architecturally wrong (wrong behaviour, missing requirement), Slack the engineer with a specific description. Do not leave a GitHub comment.
  5. Once satisfied: approve the PR and hand to Design for UI review

Alpha / Beta / GA Sign-Off

Once a feature merges and moves to MVP in the Feature Readiness Dashboard, the quality gate process begins.

MVP to Alpha

Before moving to Alpha, the Feature Readiness ticket must include:

  • Published docs — the feature must be documented in the wiki
  • A Loom video — walkthrough of the full-stack experience so reviewers can see it working

  • PR link — so reviewers can pull the branch and test the full-stack experience themselves

  • Publish the feature docs and record the Loom video

  • Add the docs link, Loom video, and PR link to the Feature Readiness ticket
  • Tom, Chris, and PM test the feature together for product quality
  • Fix minor FE and usability issues yourself directly in code — you are trained to do this with Cursor. Do not create tickets for things you can fix in 10 minutes.
  • Open PRs to fix every issue found — use Cursor, merge immediately
  • Once all issues resolved: Tom and Chris sign off
  • Move feature to Alpha in Feature Readiness Dashboard
  • Brief the team and any AMs who need to be informed

Alpha to Beta

  1. Feature is live for a limited set of customers under a PostHog feature flag
  2. Collect customer feedback actively — direct conversations, PostHog session recordings, support tickets
  3. Open PRs to fix every issue that surfaces
  4. Once feedback stabilises and critical issues are resolved: move to Beta
  5. Expand the PostHog feature flag rollout

Beta to GA

  1. Broader customer rollout
  2. Continue collecting feedback and fixing issues
  3. Once stable across a meaningful customer set: move to GA
  4. PostHog feature flag removed from code and deleted from PostHog
  5. AMs announce the feature to customers using your docs and Loom video
  6. Marketing uses the same docs and video for external announcements

The rule at every stage: you do not move forward until the issues from the current stage are fixed. Not "mostly fixed." Fixed.

PostHog Analytics Review

After a feature reaches Alpha, you own the analytics. This is how you know whether the feature is working and whether customers are using it.

What to review weekly once a feature is live:

  • Are the events firing at the expected rate? (If users should be clicking Export but no Export events are firing, something is wrong)
  • Are there error events that shouldn't be there?
  • What's the drop-off in multi-step flows? (Where are users abandoning?)
  • Are the customers using it the way you expected, or are they using it differently?

If something looks wrong: Slack the engineer who built it with the specific PostHog data. Do not create a ticket — just fix it.

If usage is lower than expected: This is a product problem, not an engineering problem. Talk to customers before changing anything.

Backlog Management

You own the backlog for each developer. This means you are responsible for making sure every dev always knows what to work on next.

Your responsibilities:

  • Create the first pass of all full-stack tickets — high-level BE/DE tickets that engineers then refine
  • Keep each developer's backlog prioritised so they can pick up the next item without asking
  • Scan backlogs weekly for anything sitting too long, misclassified, or blocked
  • Prioritise incoming feature requests into the Feature Readiness Dashboard if they have legs, or close them with a note if they don't
  • Bug backlog is owned by QA — you don't manage bugs, but flag anything critical that needs urgent attention

The best backlog management is writing outcomes clearly enough that engineers know exactly what to pick up next without needing to ask.