Santiago — Product + Project Lead JD

Role: Product + Project Lead, MemberIntel
Incumbent: Santiago Perez Asis
Reports to: Blair Williams, CEO
Peers (also report to Blair): Seth Shoultes (Lead Architect, MemberIntel) · Russ Williams (Lead Designer, MemberIntel)
Capacity allocation: 80% MemberIntel / 20% cross-Caseproof
Effective: May 2026
References: MemberIntel SPEC v1, SPEC v1.5, SPEC v2, decision-rights matrix, phased plan, Seth — Lead Architect JD, Russ — Lead Designer JD

---

Mission

Keep MemberIntel on cadence and translate strategic direction into shipped product. The Product + Project Lead is the operational anchor and product-execution owner — PRD authoring, sprint cadence, dependency mapping, risk register, L10 scorecard, beta program design, support enablement, and the connective tissue between MemberIntel and the rest of Caseproof.

You decide what the PRDs say (with Blair’s final approval on strategy and pricing), when the rhythm fires, and how the team coordinates across functions. You do not decide how it gets built — that’s Seth — or what it looks like — that’s Russ, with Blair’s direction.

You are the operational anchor of the MemberIntel team — a peer to Seth and Russ, not a manager of either. Blair sets strategy; Seth owns the engineering; Russ owns the design; you own everything that connects them and the customer-facing surfaces that depend on them shipping in concert.

---

Authority structure

CEO (Blair) holds: product strategy, target customer, 18-month roadmap, pricing, material architecture approvals, brand direction

Lead Architect (Seth) holds: sprint scope, engineering velocity, technical and architecture decisions, engineering hiring

Lead Designer (Russ) holds: visual system, product UX, design hand-off to engineering

Product + Project Lead (Santiago — this role) holds:

Product:

• PRD authoring and acceptance criteria (Blair approves on strategy / pricing surfaces)
• Free→Pro conversion mechanics (you propose; Blair approves)
• Beta program design
• Customer onboarding flow scoping (with Russ on UX, Seth on data ingestion)
• Cross-functional content / marketing-site coordination
• IPJ liaison and domain-name administration
• Support enablement before launch (with Wray on CS)
• The ship / no-ship gate at GA

Project / operational:

• Sprint cadence, ticket tracking, and dependency mapping
• L10 scorecard for MemberIntel
• Risk register maintenance and review cadence
• Cross-rock coordination (MemberIntel ↔ MemberPress core ↔ MemberMouse legacy ↔ growth)
• Status reporting to leadership across all Caseproof projects you cover
• Project-management tooling decisions (Linear / Notion AI / etc.)
• Meeting cadence and rhythm (standups, planning, retros, reviews)

Sam (Brain Content Lead) reports to you — see Sam — Brain Content Lead JD.

---

What you own

1. Sprint cadence

• Run the MemberIntel sprint cycle (cadence TBD with Seth — likely 2-week sprints).
• Sprint planning, mid-sprint check-ins, sprint review, and retrospective.
• Capacity planning across the engineering team.
• Burndown / velocity tracking — surface drift early.

2. Ticket and dependency tracking

• All MemberIntel work tracked in Linear (or the team-agreed tool).
• Dependencies mapped: MemberPress-core changes blocking MemberIntel features, MemberIntel features blocking marketing rollouts, etc.
• Critical path always visible — what would slip GA if it slipped this week?
• External dependencies tracked (privacy counsel, PR agency, third-party APIs).

3. Risk register

• Maintain MemberIntel’s risk register per SPEC §14 (Anthropic dependency, content lead bottleneck, eval differentiation, compliance, Phase 2 calibration).
• Review risks bi-weekly with Seth.
• Escalate hot risks to Blair within 48 hours of identification.
• Track mitigation actions to close.

4. L10 scorecard for MemberIntel

• Define the weekly numbers (signups, conversion, eval pass rate, cost-per-user, etc.) once telemetry exists.
• Pre-launch: track readiness milestones (privacy counsel engaged, beta cohort onboarded, marketing site live, etc.).
• Post-launch: track the metrics defined in SPEC §2.
• Surface trends and outliers — don’t just collect numbers.

5. Cross-team coordination

• Coordinate dependencies across:
  • MemberPress core (Paul Carter) — data sync APIs, MP-side surface required for MemberIntel
  • Growth (Curt Noble) — marketing site launch, paid acquisition timing
  • Design (Russ) — design dependencies for engineering
  • Operations (Danielle) — Senior AI Engineer hire and onboarding
  • Senior AI Engineer (post-hire) — eval-suite milestones, prompt-versioning rollouts, cost-telemetry surface for the weekly cost-per-cohort review
  • Payments (Ally) — Stripe integration and pricing logic
  • CS (Wray) — support enablement before launch
• Make sure no dependency is invisible to Seth or Blair.

6. Status reporting

• Weekly status snapshot to Blair (concise, traffic-light style: green/yellow/red on each rock).
• L10 attendance with crisp scorecard read.
• Quarterly: drive the architectural review check-in (per the quarterly-architecture-review-template) — keep agenda tight and timeboxed.
• Cross-rock view for Caseproof leadership when MemberIntel timelines impact other initiatives.

7. Meeting rhythm

• Daily standup or asynchronous equivalent with engineering.
• Bi-weekly sync with Seth (30 min).
• Bi-weekly sync with Russ (30 min).
• Weekly sync with Sam once he’s transitioned in (30 min — brain content backlog and blockers).
• Monthly leadership review with Blair, Seth, Russ.
• Sprint reviews and retros at sprint cadence.
• Quarterly architecture review (you facilitate; Seth and Russ attend; Blair joins).

---

What you do NOT own

• Sprint scope decisions. Seth decides what fits in a sprint; you track whether it actually fits and surface drift.
• Architectural decisions. Seth’s call.
• Engineering hiring decisions. Seth’s; ops/fit is Danielle’s; you don’t sit in the loop unless asked.
• Design direction and visual system. Russ owns; Blair approves direction.
• Pricing or strategic calls. Blair.
• Engineering management. You don’t direct engineers; you ask them to surface what’s blocking the work.

---

Critical role norms

1. Cadence over heroics. A predictable rhythm beats sporadic sprints of intensity. You enforce the rhythm.
2. Dependency-mapping is your superpower. When something slips, you know within 24 hours which downstream rock is affected.
3. Risks surfaced early are not failures. Treat early risk surfacing as a signal you’re doing the job well — the team should bring you problems before they’re crises.
4. Status reports are short and honest. Green/yellow/red, with the “why” in one sentence per item. No long narratives.
5. You don’t manage Seth’s people. You ask the engineers what they need; you don’t tell them what to do.
6. You can disagree with priorities. Bring concerns to Blair within 48 hours — same escalation discipline that Seth and Russ use.
7. Cross-rock visibility goes both ways. When Caseproof’s other initiatives could collide with MemberIntel timelines, you flag it before it’s a problem.

---

Success measures (12-month)

Measure	Target
Sprint completion rate	≥ 85% planned-vs-shipped, sustained
Velocity drift	≤ 15% sprint-over-sprint variance once stable
Risks surfaced ahead of impact	≥ 80% of register items flagged ≥ 1 sprint before they affect the critical path
Cross-team dependency surprises	≤ 1 per quarter (a “surprise” = unmapped dependency that delays a milestone)
L10 scorecard cadence	100% on-time weekly delivery
Status report on-time delivery	100%
Blair’s confidence in MemberIntel timeline	”I know what’s actually happening every week” — qualitative quarterly check

---

Reporting cadence

Cadence	Audience	Format
Daily	Engineering team	Standup or async digest
Weekly	Blair	Status snapshot (traffic-light + critical path)
Weekly	Sam (once transitioned)	Brain content sync (30 min)
Bi-weekly	Seth	Sprint sync (30 min)
Bi-weekly	Russ	Design coordination (30 min)
Monthly	Caseproof leadership	L10 scorecard
Quarterly	All leads + Blair	Architecture review (you facilitate)

---

What “good” looks like in this role

• Blair gets predictable status reports — no surprises about MemberIntel’s actual state.
• Seth focuses on architecture and code; he doesn’t have to think about cross-team dependencies because you’re tracking them.
• Blair can plan launch comms with confidence because the engineering timeline you surface is real.
• Risks surface 1–2 sprints before they become problems, not after.
• Cross-rock collisions are anticipated — MemberIntel doesn’t blindside MemberPress core or growth.
• The team enjoys the rhythm — they know when standups are, when planning is, when retros are. The cadence is reliable.
• The L10 scorecard tells a story leadership can act on, not just a list of numbers.

---

Document version: Draft v1 — companion to the phased plan. Cadence and tooling specifics finalize as the team comes online.