Systeric / Docs
Open App →

PM Apprenticeship

How we run a product manager apprentice’s first 180 days, day to day. This is the PM companion to PE Apprenticeship (the Product Engineer version); the hiring bar lives in Hiring and the ladder and attributes in Product Manager. It covers the milestones, the guardrails that make early autonomy safe, the 1:1 cadence, and the day-90 call. A per-person tracker to copy into a fresh doc is at the bottom.

A PM apprentice (APM) starts by learning how PMs decide, working under one, then owns a slice with guidance. In the consulting parallel, the 180 days are an analyst becoming an associate: fully reliable on the analyst work (the data, the definition drafts, the quality pass) by day 90, and by day 180 able to run the entirety of a project’s product operations, paired with a lead engineer, setting strategy and direction alongside the Fractional CTO rather than waiting to be handed them. The rhythm mirrors the engineer’s 7 / 30 / 60 / 90 shape, adapted to the PM craft: the first “ship” is not code but a real artifact the team uses.

Day 7 First artifact in the flow Day 30 Runs the cadence Day 60 Owns a scoped slice Day 90 The honest keep-grow call Day 180 Runs a project

Two people run it. The onboarding buddy (a PM or Lead PM) owns the day to day: pairing on Discover and Define, reviewing every artifact, transferring how we decide here. The manager owns growth and fit, using the Product Manager radar. The buddy is the first line for everything; the manager reads trajectory.


The milestones#

What an apprentice can do unsupervised by each date, not a checklist to race through. The dates are targets; someone can arrive early or need longer, and that is what the day-90 call is for.

ByMilestoneWhat it means
Day 7First artifact in the flowHas written one real problem statement and gotten it into Glide, and owned one weekly update end to end. Small and guided, but real, none done for them.
Day 30Runs the cadenceHas taken a small problem through Discover, sat in a Define session, kept the weekly update, and is comfortable in Glide: Requests, Roadmap, the story map.
Day 60Owns a scoped sliceTakes a small, well-scoped problem from Discover through Define to a clean Build handoff with guidance: a metric defined before build, release notes drafted, the plan kept honest.
Day 90Decision checkpointEnough signal for an honest call: on track for PM, extend the runway, or stop. On track means the analyst work now runs unsupervised, the data, the definition drafts, and the quality pass done without a net. Never a surprise.
Day 180Runs a projectCrosses from analyst to associate: runs the entirety of one project’s product operations with its lead engineer, the problems, the calls on what to build, shipped and measured, carries the client conversations directly, and works the strategy and direction with the FCTO instead of receiving them. Ready to be a PM.

What an APM does at each stage#

Product work runs a loop: Discover, Define, Build, Launch, Learn. At each stage the senior (the buddy or the FCTO) owns the call, and the APM owns the work that makes that call real: this is the split underneath the milestones above.

StageThe senior ownsYou (APM) ownWhat you are building in yourself
DiscoverWhich problems are worth looking intoFind and provide the data and user signal; turn noise into evidenceData analysis, and reasoning from it
DefineThe high-level problem and the solutionCraft the definition doc: acceptance criteria, states, the metricTurning intent into a Build-ready definition
BuildThe technical bar and the call on tradeoffsWalk the flow like the user, mark gaps against the definition, verify the outputJudging quality: knowing “done” when you see it
LaunchThe go / no-goRun the release checklist and notes; relay the two-minute statusDelivery discipline and clear communication
LearnThe lesson, and what changes nextGather the metric and read, honestly, whether it movedReading impact, past the number you hoped for

The split moves as you earn it: early on the senior brings the problem and the solution and you do the legwork; then you start drafting the problem statement yourself and the senior corrects it rather than writing it; by the time you’re ready for PM, you run the project end to end and bring the FCTO a call to pressure-test, not a blank to fill.

Now / next / later#

Underneath the stages, keep one simple board so the senior always has clarity without asking: Now is what’s actively in Build or Launch, kept short so it means something; Next is defined and queued: nothing enters Next without a definition doc; Later is a decision, not a graveyard: each item is either still being discovered or deliberately parked with a reason, never just forgotten. A request lands in Later first, and moving it to Next to Now is the visible trail of your work.

Learning to query#

Discover is the stage where the APM earns their keep, and it runs on data the apprentice pulls themselves. Waiting on an engineer for every number is the difference between an analyst and a messenger, so this is the first hard skill to build, starting in week one.

No computer science background is assumed or needed. Work the three in order, alongside real questions rather than before them:

  1. Using Metabase: the tool, so you can get real answers on day one without writing code.
  2. Database Design Principles: the picture of how data is actually stored, built from a spreadsheet upward.
  3. Reading a Schema: walking into an undocumented database, building a query in either MongoDB or SQL, and verifying the answer before you believe it. It ends with a curated learning path.
  4. Querying MongoDB: the actual syntax, with one real question worked stage by stage so you can see the documents change shape. Nine practice exercises at the end.

The bar by day 90 is not fluency in a query language. It is that you pull your own numbers and you check them before anyone else has to.

What you walk away with#

The apprenticeship builds skills that transfer to any product, operating, or founding role:

  • Reasoning from data, so you argue from what is true, not what is loudest.
  • Turning a fuzzy ask into a precise definition that a team, or an AI, can build without guessing.
  • Judging quality, knowing “done” when you see it and naming the gap when you do not.
  • Communicating so people get it the first time, and relaying between the people who want a thing and the people who build it.
  • Thinking in now / next / later, holding a whole roadmap in your head and keeping everyone oriented.
  • Reading impact honestly, including when the number you hoped for did not move.

Week one: get to the first artifact#

The first week is built backwards from day 7. Front-load context so the week ends on a real artifact the team uses, not a reading list.

  • Day 1. Accounts, Glide access, calendars. Meet the buddy, set the standing daily time, walk the guardrails below. Start Core and How Systeric Works.
  • Days 2 to 3. Shadow the buddy’s cadence: sit in on a Discover conversation and a Define session, read the current roadmap and story map. Pick one small, real observation worth framing.
  • Days 4 to 5. Write the problem statement for that observation, take it to the buddy, and get it into Glide. Draft the weekly update alongside the buddy and send it. First artifact done.

By the end of week one they have touched the flow once, from a raw observation to a written problem and a shipped update. Weeks two to four widen it: a full Discover, a Define they help run, less pairing.

The day-one welcome messages are role-agnostic; they are in PE Apprenticeship.


Guardrails#

These hold for the whole apprenticeship. They are what make it safe to give someone real product influence early. Walk them on day one.

  • No solutions in Discover. A problem statement carries no solution. If you cannot write the cost of inaction without a fix in it, you have not finished discovering.
  • Do not commit scope or dates alone. Nothing gets promised to a client or the team without a Define and the PE sign-off. Budgets and dates come out of the process, not a hallway.
  • Never skip a gate. A Request does not advance without the leadership review; an item does not reach Build without the solution sign-off.
  • Write it down. Decisions, changes, and asks live in Glide and the weekly update, not in DMs. If it is not written, it did not happen.
  • Escalate early. A slipping date, an overloaded week, or a doubt surfaces the same day. Silence is the failure mode, for a PM most of all.

The 1:1 cadence#

Two 1:1s, two jobs. Same shape as the engineer program.

  • Buddy 1:1 (daily, then tapering). A PM or Lead PM, the first line. Daily for the first weeks to transfer how we frame problems and run sessions, then a few times a week as they find their feet. Unblocking, pairing on live work, reviewing every artifact before it goes out.
  • Manager 1:1 (weekly, then biweekly). Weekly for the first month, then biweekly. Growth and fit, run against the Product Manager radar: feed the spike, clear the one thinnest spoke holding them below PM. Delegate one rung ahead, then close the gap with review. No surprises: the day-90 call is discussed continuously, never sprung.

On top of the two 1:1s, three times in the first half the APM, the buddy, and the lead sit together for a 30-minute calibration: see Apprentice Check-ins for the session and the template.


The 90-day checkpoint ([date])#

Enough signal for an honest call. On track for PM, extend the runway, or stop. Written against the radar, with one concrete moment per attribute, never a surprise.

  • On track: owning scoped slices with guidance, the judgment spokes (product sense, user insight, strategy) visibly moving.
  • Extend: the trajectory is right but the reps need longer; re-base the plan and say so.
  • Stop: a non-negotiable is failing, or the judgment is not moving despite the reps. Kind, clear, early.

Per-person tracker#

Copy this into a fresh doc for each apprentice. Keep it live; it is the spine of the manager 1:1.

[Name] · started [date] · buddy [name] · manager [name]

Milestones#

  • Day 7: first artifact in the flow (problem statement in Glide + one weekly update)
  • Day 30: runs the cadence (Discover, a Define, the weekly update, fluent in Glide)
  • Day 60: owns a scoped slice (Discover to Build handoff, metric and release notes)
  • Day 90: decision checkpoint
  • Day 180: runs a project (operations end to end, direction with the FCTO)

Shape (the seven PM attributes)#

Product sense · User insight · Strategy & prioritization · Delivery · Data & impact · Communication · Influence. Note the spike to feed and the one blocker to clear.

Buddy 1:1 log#

[date]: [what they worked on, what to reinforce]

Manager 1:1 log#

[date]: [trajectory, the spike, the blocker, the next rep]

90-day decision ([date])#

[On track / extend / stop, with the concrete evidence]


Related: Apprentice Check-ins, PE Apprenticeship, Product Manager, Using Metabase, Database Design Principles, Reading a Schema, Querying MongoDB, Hiring, Internship Program, Leading People, How Systeric Works