CAF Technical PM — role framing + roadmap-build kit (v0)

Founder asked to be technical PM for CAF (Todd = front-end PM), needs to share a roadmap + vision, and wants to fit CAF into the bigger Decision Intelligence Engine (DIE) 5-point program. First time as an "official" PM. This is the framing spine + the questions needed to build the actual roadmap. phData-internal — keep in local vault, not public.

The three strategic wedges (this is the spine of the whole pitch)

1. The missing context vault is your opening

DIE's 5 points: skill vault (forge) · Gandalf (governance) · DCA (solutioning/impl) · CAF (use-case gen/pre-sales) · vertex(?). There is no context layer. Every other point silently needs one: forge needs context to build good skills, Gandalf needs provenance to govern, DCA needs context to implement, CAF needs it to assess. The cellar (context vault + steward + pointers-not-copies) is already built in the brigade. Position it as the missing connective substrate, and CAF as its reference implementation. That reframes CAF from "1 of 5 peers" into the substrate the other 4 ride on — which is exactly career-advice #2 (remix others' work into something more valuable).

2. Hexagonal architecture is the deployment-war peace treaty

Murray wants AWS · Anderson wants Snowflake · Andrew wants max-Anthropic · clients want their own env. That's a political turf war with a technical answer: hexagonal ports make every deployment target an adapter, not a fork. You don't pick a winner or lose a stakeholder. This makes you the neutral integrator every camp needs — career-advice #1 (vendor powerhouse) across all three vendors instead of being captured by one. "The Snowflake guy" is a ceiling; "the guy whose architecture makes every vendor camp win" is not.

3. The brigade is DIE's operating model, not just CAF's

The agent-brigade (stations · rail · expo · gates · factory) is a general operating system for agentic delivery. Map it onto DIE: forge = what the factory produces; Gandalf = the gates + meta-council + close-out already in the brigade; DCA = consumes CAF's Build Manifest to implement; CAF = front of the funnel. The assessment brigade populates the Snowflake frontend (the key deliverable) — that's the concrete near-term proof point that the model works end-to-end.

IC → PM: what actually changes (the soft-skill shift he asked about)

1. Your output flips from artifacts to decisions + alignment. As IC you're graded on what you build; as PM, on whether the right thing got built by others. Hardest adjustment for a strong IC: you have the brigade, your instinct is to just build it. Resist doing eng's job — your leverage is now direction + unblocking.
2. You manufacture alignment among people who disagree (Murray/Anderson/Andrew). Turning a turf war into a plan everyone can live with IS the job. Hexagonal is your gift here — a technical answer to a political problem.
3. You own the WHY and WHAT; you delegate/negotiate the HOW. Vision, roadmap, priorities = yours. Implementation = the team's (you + Todd).
4. You make decisions legible — write everything down. PMs who don't write lose the narrative. He already has this superpower (the vault/HQ + decision-log habit).
5. You say no and sequence ruthlessly. A roadmap that says yes to everyone (all 3 deploy targets at once, all 5 DIE points now) is a failure. The roadmap is as much what you're NOT doing.
6. You make others successful and share credit (= career-advice #2, literally the PM job description). You win through the point-owners, not around them.

Career-ladder tie-in ([[2026-05-27-analytics-career-ladder]]): CAF PM is an L4→L5 move — leads a structured non-project initiative, aligns outcomes across stakeholders. This is the "quick advancement" lever, made concrete.

The PM toolkit (docs + cadence to stand up)

• Vision / strategy one-pager — the north star: what CAF is, who it's for, why it wins, what "done in 12 months" looks like. This is half of what he was literally asked for.
• Roadmap — outcome-based, Now / Next / Later (NOT a Gantt of features or dates he can't hit). Anchor to outcomes ("assessment brigade populates the frontend at X quality/latency"), not tasks.
• PRD / one-pager per major deliverable — Snowflake frontend, assessment brigade, context vault.
• Stakeholder map + RACI — who wants what, who decides, who's consulted. Critical given the deploy war. Names: Murray, Anderson, Andrew, Todd, clients, the DIE exec sponsor.
• Decision log — he has the habit; keep it.
• Success metrics / definition of done — how DIE leadership will judge CAF. Without this the roadmap is unfalsifiable.
• Operating cadence — sync with Todd, a stakeholder readout rhythm, one shared status surface. PM where stakeholders already look (phData's existing Jira/Confluence/Notion), don't invent a new surface.

DIE 5-point map + where CAF sits

What I need from him to build the actual roadmap

1. Horizon + audience + format: who is the roadmap FOR (DIE exec sponsor? the 5 point-owners? formal leadership readout?), by when, how formal? Sets the whole shape.
2. vertex: what does it do, who owns it?
3. Ownership split with Todd + reporting line: technical-PM vs front-end-PM boundary, and who's the DIE exec sponsor he's serving?
4. Mandate scope / ambition: PMing just CAF, or making the play for CAF-as-DIE-substrate (context vault as the connective layer)? The difference between a competent roadmap and a category-defining one — and a choice about how much political capital to spend.
5. Fixed near-term anchors: what's already committed (Snowflake frontend milestones, KB4 July 15) that "Now" must honor?

Round 2 — founder's answers + the sharpened story (2026-07-05 ~11:30pm)

Answers he gave

• Exec sponsorship: Vincent (Chief Solutions/Strategy Officer). Troy owns DIE overall (unconfirmed). Warren (sales SVP) watches all CAF-request throughput. Real dollars are gated on a native Snowflake app deployed via Anderson. → that native-app is the roadmap's north-star "why."
• He has the entire MLE bench (~12 people) IF he gives clear objectives. Clear objectives = the PM deliverable; the bench is his leverage.
• Vision confirmed: cellar+brigade as the unifying pattern across all major projects. Murray can build AWS-tailored brigades better than he could (federation working as intended — wedge #2 validated). Gandalf + DCA live in the client env and ground against the codebase, not the KB — but the KB still has value there.

The real story to get straight (his instinct is right)

He wants to "step back and get the story straight before pushing a thread in multiple directions." That instinct IS the PM job — the disjointedness he senses is the coherence gap a PM exists to close. His 6-weeks-in self-doubt is misread: naming the pattern below is seeing clearly, not being lost.

The pattern he named = the strategic opening: smart people + high autonomy → slap together an impressive demo → get people excited → "scale this" → pull back the covers = nearly vaporware. Evidence: job-scraping (works once, not all cases), Murray's CAF+DCA AWS demo (no docs, show>substance, unclear DCA got the right CAF handoff), his own Snowflake site (hardcoded bits, flaky CAF→Snowflake load before this weekend).

CAF/brigade discipline is the antidote to exactly that pattern — specs, contract gates, reproducibility, ticket-as-build-record, docs-as-artifact. That is his differentiated PM value: not another smart person making demos, but the one imposing the discipline that turns demos into scalable systems. That is the story.

Two problems he named are already solved in the build

• "Murray had no clear spec for what he could get out of CAF" → that spec EXISTS: the typed Build Manifest (schema v1.1) is the CAF→DCA contract. The unreliable handoff (his Snowflake site's hardcoded bits, flaky load) is the same class of bug the Build Manifest + fail-loud ingest killed this weekend. His weekend work IS the template — generalize it to CAF→DCA (Murray) and CAF→Snowflake (Anderson).
• "6hr run times can't scale" → the UC-as-ticket parallelization (inner rail, dimension battery fans out, wall-clock = slowest UC ≈ 10x, plus single-UC refinement without rerunning half-CAF). That's the scale story for the roadmap.

The operating model (ties his two career levers together)

Give the MLE bench clear objectives (contracts + the brigade pattern) → they build tailored brigades (Murray/AWS, others/domains) → he's the powerhouse behind the pattern across all vendors (lever #1) → he remixes forge/Gandalf/DCA/CAF into a coherent whole via the shared cellar+brigade (lever #2). Bench = leverage; clear objectives = the unlock; the shared pattern = the credit-sharing coherence.

Todd dynamic (founder answered ~11:46pm)

Todd is 3 days in (greener than the founder), front-end PM, DIRECT report to Vincent. Split TBD. Read = leverage, not threat: founder holds the substance (6 wks + owns the actual system); Todd holds the short line to the sponsor (founder's own line runs Taylon→Elizabeth, not Vincent). Two moves advised:

1. Shape the split NOW while TBD + Todd onboarding — propose it, don't wait. Clean substance cut: founder owns the engine (CAF, brigade pattern, contracts, backend); Todd owns the user-facing front end (Snowflake app surface). Founder defines it because he understands what there is to divide.
2. Todd = conduit to Vincent, not rival. Onboard him, make him look good, share credit (= career-lever #2). Today's teaching deck IS Todd's onboarding artifact — walk him up the curve on it → founder becomes the anchor a Vincent-facing PM leans on. Green co-PM who owes his mental model to founder + has sponsor's ear = ideal ally.

Still needed before the v0 roadmap draft

• Exact ask: format + deadline + audience for what Vincent/Troy expect him to "share."
• What vertex does + confirm Troy owns DIE.
• (Todd boundary now partially answered — propose engine/front-end split; confirm Todd accepts.)

Next: Ray drafts the v0 vision one-pager (native-Snowflake-app north star + discipline-layer thesis) + Now/Next/Later roadmap once he confirms the ask format. Not built tonight — the thing he most wanted now was the story straight, which is above.

Related: [[2026-07-03-hex-deployment-matrix]] · [[2026-07-01-caf-ecosystem-map-and-brigade-restructure-read]] · [[2026-05-27-analytics-career-ladder]] · [[2026-06-14-caf-restructure-organizing-brief]] · [[project_caf_pm_role]]