Product Manager

Execution is cheap now. A product engineer with AI can build what used to take a team, so the bottleneck is no longer how much gets built. It is judgment: knowing what is worth building, for whom, and why now. That is the scarce thing, and it does not scale by adding headcount.

So product management at Systeric is a small, senior function. A handful of PMs carry the judgment for many projects, rather than one PM per team shipping features. The ladder reflects that: it is one path that gets deeper and broader, not a management chain. You apprentice, you own a project, then you platformize what you learned running it. There is no management chain at all, no Group PM, Director, or VP layer. Near the top, the most senior PMs embed as a client’s fractional CTO, owning a company’s product and technical direction rather than a chain of reports.

How a project is staffed#

Every project runs on a pair: one PM and one lead engineer, both reporting to the Fractional CTO on it. The PM owns the product operations end to end, the lead engineer owns the technical execution, and the FCTO owns the client relationship and sets direction with them. That pair is the whole point of the structure. A project that has a PM and a lead who can run it does not need the FCTO in its detail, which is what lets one FCTO carry several projects at once. See Roles for the full staffing shape.

The Bridge#

Take the PM out and put biz in a room directly with engineering, and you don’t get speed, you get bias. Two failures follow, and they’re the same failure seen from each side.

• To engineering, everything sounds urgent. A biz stakeholder has no visibility into technical cost, so a real emergency and a preference stated forcefully arrive looking identical: now. With no signal to tell them apart, engineering either treats everything as fire and burns out, or discounts all of it and misses the one that mattered.
• To biz, a technical concern sounds like foot-dragging. An edge case, a migration risk, a fragile spot in the code: real reasons to slow down, but stated in engineering’s language they read as excuses. Whoever is most senior or most recently frustrated wins the room, and the edge case ships broken because nobody translated why it mattered.

Either way, the call gets made by leverage, not by what the person using the product actually needs.

A PM’s job is fidelity in both directions: represent the real user faithfully enough that priority is set by their impact, not by who is loudest, and represent the real technical picture faithfully enough that biz makes the trade with the full cost in view. “The user” here is whoever the product actually serves in the moment: a paying customer, the ops team keying in orders, another engineer calling an internal API. See Personas & Jobs for how to name them precisely.

Bad, and this is an invented case, not a real one: sales tells engineering the checkout needs one-click reorder by Friday, because a client demo is Monday. Engineering ships Thursday night, skips the case where the saved card was removed, and forty customers get charged against a card that no longer exists.

Good: the PM hears the same Friday ask, checks it against what a reorder actually looks like for a real shopper (three items, once a month, always the same card), and comes back with the real trade: the demo can run on a script Monday, or one-click ships broken to real customers next week to hit Friday. Sales gets an honest choice instead of an unlabeled emergency, and engineering gets a reason instead of a deadline.

That’s the translation a PM is actually paid for: not managing a backlog, but standing between two languages so the decision gets made on the user’s terms, not on whoever pushed harder.

At a Glance#

One path, from apprentice to the apex. It does not fork into parallel IC and management tracks: a PM grows by carrying more judgment over more of the product, until the most senior embed as a client’s fractional CTO. It rejoins engineering and design at the top, in the CTO, the one best at building product.

The hinge is Lead PM, and it is the same hinge the engineering ladder turns on at Lead: you stop doing the work and start building the thing that makes it repeatable without you. Below it, you are running projects. At it, you are turning what you learned running them into a product or a platform.

APM → PM → Lead PM → Fractional CTO → CTO

The spine down the middle column is the whole story: a slice → a project → a product or platform → a company as its fractional CTO → the whole product.

The consulting parallel#

The lower rungs map cleanly onto a consulting firm, and it is the fastest way to place them. An APM is the analyst: they build the fact base, the data, the user signal, the first draft of the definition, and check the build against it, all under someone who owns the call. A PM is the associate: they run an engagement’s day to day, own every operational call on it, and carry the stakeholder conversations themselves. A Fractional CTO is the partner, embedded in the client, owning the relationship and covering several engagements at once because each has a PM and a lead engineer running it.

Lead PM is where the parallel breaks, on purpose. A consulting firm sells hours, so its ladder keeps climbing through bigger engagements. We do not want that. At Lead PM the job stops being another engagement and becomes turning engagements into an asset: a product, or a platform the next engagement starts from. There is no consulting rung for that, and that is the point of difference.

The same parallel is the delegation rule. Analyst work is delegable: hand an APM the research, the data pull, the first draft of a definition, the quality pass on a build, the release checklist, the honest read on whether the metric moved. The call is not: what to build, what scope or date gets promised to a client, whether a gate is passed, and who owns the client relationship stay with the PM and above. An APM earns the call by doing the analyst work well enough that you stop checking it, which is what the first 180 days are built to produce.

Lead PM: platformize or productize#

Running a project well is the PM rung, and it does not compound. Run five and you have run five projects. The rung above is where the work changes shape: you look across what we have built for clients and ask what should stop being bespoke.

There are two honest answers, and both count.

• Productize it. The thing solves a problem beyond the client who paid for it, so it becomes something we can sell. Glide and Lore both started this way, as internal answers to problems we kept hitting on client work.
• Platformize it. The thing will not be sold, but the next engagement should not rebuild it. It becomes the starting line instead of the first month of work.

The test for the rung is not seniority or scope. It is whether the leverage outlives the engagement. A Lead PM’s output is something the firm still has after the client is gone: a product with users, or a platform the next project starts on top of. If everything you shipped last year left with the client, you are still doing the PM job well, not the Lead PM job.

This is why it is the same word engineering uses. On the engineering ladder, Lead is where you stop shipping tickets and start platformizing how the work gets done. Same hinge, different material: the engineer platformizes the how, the Lead PM platformizes the what.

Your Shape: The Seven Attributes#

The ladder tells you your altitude. This tells you your shape: where you are strong, where you are thin, and what to do about it.

It is attribute-focused, not level-focused. You are not “a PM”. You are a profile: maybe strong at product sense, thin at data, middling at strategy. Place yourself honestly on each attribute and the line comes out jagged. That jaggedness is the point: it shows exactly where to push next.

It is a mirror, not a scorecard. Nobody is graded or ranked here. Each attribute is a direction to grow, not a number to defend.

• Product sense: taste and judgment for what is worth building, and the conviction to cut the rest.
• User insight: getting past what users ask for to the real problem they have.
• Strategy & prioritization: choosing what to do and what not to, and in what order, and why now.
• Delivery: driving the work to shipped and measured, now mostly by directing engineers and AI rather than doing it yourself.
• Data & impact: choosing the metric that actually matters, then proving it moved.
• Communication: being understood the first time; aligning people without authority.
• Influence: raising the few PMs and bending the org toward the right product, with leverage rather than headcount.

Gauging Someone#

You gauge a PM by their shape: where they sit on each of the seven attributes, drawn as a radar. Here is every level’s shape. Place your report against the rung they are growing toward, and the gap is the work.

How to read the shapes. This is one path, not a fork. Each rung’s shape contains the one below it: you keep everything and add, nothing recedes. The early rungs are spiky, strong on a few spokes and thin on the rest; the later rungs fill out as the job widens from one project to a product to a whole company. The depth spokes (product sense, user insight, strategy, data) lead the way up, with communication and influence coming in hardest at Lead PM, where you have to make other people want the platform you built.

• APM: the analyst, thin nearly everywhere on purpose; the reps that move first are data and user insight.
• PM: owns one project end to end, paired with a lead engineer, direction set with the FCTO.
• Lead PM: platformizes; strategy jumps because the call is now what stops being bespoke, and influence jumps because nobody adopts a platform they were not sold on.
• Fractional CTO: the rare product mind, embedded as a client’s fractional CTO, owning a company’s product and technical direction.
• CTO: the synthesis, best at building product.

The climb, in detail#

The radar is the summary. Here is the same thing in words for the climb, apprentice to Lead PM, attribute by attribute. The point of each row is what genuinely changes by level, not a baseline every PM is expected to do. Every PM talks to users and defines a metric; what moves up the ladder is the judgment behind it.

Hiring For It#

Hiring is two gates, in order. First the non-negotiables: critical thinking, honesty, ownership, low ego, high agency. Fail one and it is a no-hire at any level, no matter the rest. Those, and the loop built to force them out, live in Hiring. Then the read: where does the candidate sit on each attribute? Since PM is a small, senior function, the bar is high and the search is slow on purpose.

You hire at the level the evidence supports, attribute by attribute, not the title on the CV. A spiky candidate is normal: hire the spikes you need and coach the rest, but never past a failed non-negotiable.

Growing Your Reports#

The shared growth philosophy (double down on the spike, clear the one blocker, and the mechanism that levels up any attribute) lives in Growing Your Reports. What’s specific to PMs is the rep itself, attribute by attribute:

In a small function, one Lead PM who turns a project into a platform moves more than any single PM’s output, because the leverage keeps paying after the engagement ends; see Growing Your Reports for why that trade compounds. For how the work itself moves stage by stage, see How Systeric Works.

Related: Roles, PM Apprenticeship, Product Engineer, Product Designer, Hiring, Growing Your Reports