AI-Adjacent Roles Bootcamp
Go beyond the lessons: build a portfolio of real artifacts, drill the interview, and follow a paced program.
The capstone
A portfolio of real AI-adjacent artifacts for one feature, built end to end.
AI-Adjacent Roles Capstone
The idea: Knowledge becomes skill only when you do the work. In the capstone you take ownership of one real AI feature at the start and carry it from a vague "add AI" request through prompt design, rigorous evaluation, a responsible-use review, a buildable spec, and a real prototype. You produce the exact artifacts an AI PM / prompt engineer / AI-operations specialist makes on the job — and because those roles emphasize different things, you'll own the lens you picked in Week 1 and go deeper on the deliverables that prove it (see Pick your lens below). By the end you'll have a portfolio — all about the same feature, telling one coherent story, with a clear spike toward your target role — that proves to yourself and to employers that you can actually do the job, not just describe it.
How it works: Each deliverable unlocks after the syllabus topic that teaches its skill. You produce the artifact (a template is provided), submit it, and the app's AI reviews it against a rubric, gives you specific feedback, and lets you revise until it's solid. Finished deliverables assemble into your portfolio.
Your project: Ship an AI Feature End-to-End — The Support Copilot
You don't choose a product here — you're handed a real scenario and asked to own the AI inside it.
The scenario. FjordPay is a mid-size fintech whose support team is drowning: ticket volume doubled after a product launch and replies now take 14 hours. Leadership says "use AI to fix this" but is nervous about wrong answers to customers about money. You're brought in as the AI-adjacent owner of a proposed Support Copilot — an LLM assistant that drafts replies to common billing and account questions for human agents to review and send.
Your job across the capstone: design the prompts that make it reliable, build an evaluation that proves how good (and how unsafe) it actually is, decide where humans stay in the loop, write the spec engineering can build, and ground it with a real hands-on prototype — choosing where AI genuinely helps and where it must not act alone.
Every deliverable is about this same feature, so the artifacts stack into one narrative instead of six disconnected exercises.
The deliverables (your capstone arc)
| # | Deliverable | Unlocks after | The skill it proves |
|---|---|---|---|
| 1 | Prompt spec & iteration log | Topic 4 (Prompt engineering fundamentals) | Engineering a reliable prompt and iterating it |
| 2 | AI output evaluation & rubric | Topic 5 (Evaluating AI output and quality) | Judging AI quality systematically |
| 3 | Responsible-AI risk register & human-in-the-loop plan | Topic 7 (AI limitations, risks, and ethics) | De-risking AI and placing the human |
| 4 | AI feature PRD | Topic 8 (AI Product Management) | Specifying a probabilistic feature engineering can build |
| 5 | Hands-on build write-up (with RAG) | Topic 9 (Tools and the AI ecosystem) | Actually building and grounding the feature |
| 6 | Portfolio case study & pitch | Topic 10 (Landing an AI-adjacent role) | Telling the story to a hiring manager |
Each builds on the last: your prompt becomes the thing you evaluate; the eval's failure patterns drive the risk register; the risk decisions and the eval's quality bar shape the PRD; the PRD becomes a real build; and everything assembles into the case study and pitch. Together they tell one coherent story about the same Support Copilot.
Pick your lens — and let it shape the work
In Week 1 you were told to pick the AI-adjacent lens you'll own: AI PM, prompt engineer, or AI-operations specialist. That choice isn't cosmetic. All six deliverables stay required — a credible portfolio shows you can do the whole arc — but your lens decides where you go deep. Build every artifact to a solid pass, then over-invest in the one or two that your target role lives in. A hiring manager skims a portfolio for the spike that proves the role; the per-lens "Go deeper if…" note on each deliverable below tells you where your spike should be.
| Your lens | The hiring manager wants to see | Where to spike (deepen) | Where a solid pass is fine |
|---|---|---|---|
| AI PM | You can specify a probabilistic feature and define "good enough" | Deliverable 4 (PRD) and 2 (eval rubric → quality bar) | Deliverables 1, 5 |
| Prompt engineer | You engineer and iterate prompts methodically, not by luck | Deliverable 1 (prompt spec & iteration log) and 2 (eval) | Deliverables 3, 4, 6 |
| AI-operations specialist | You can measure quality, catch failures, and keep the system safe in production | Deliverable 2 (eval), the monitoring/eval-gate parts of 3 and 4, and 5 (build + failure logging) | Deliverable 6 |
The lens does not change the template, the rubric criteria, or the required sections — those are the floor everyone clears. It changes how much depth and evidence you bring to the deliverables that matter most for the job you're aiming at, and it gives you the language to explain that emphasis in your case study and pitch.
What each deliverable is
-
Prompt spec & iteration log (after Topic 4) — A production-style prompt for the Support Copilot — system role, task, context/constraints, output format, and 1–2 few-shot examples — plus a documented iteration log showing 3 refinement rounds (initial → diagnosed problem → revised) across multiple test inputs, with the verification/safety guardrails baked in. (~75 min)
- Go deeper if… Prompt engineer — this is your headline artifact. Push to 4–5 iteration rounds, show why each change worked (which token/structure/example moved which behavior), and include at least one ablation ("removed the few-shot example → fee hallucinations returned"). Treat the iteration log as your portfolio centerpiece. AI-ops — bake the machine-checkable guardrails in (e.g., a regex/JSON-schema check that fails any reply asserting a fee not in context) so this prompt is monitorable downstream. AI PM — a solid pass is fine; spend your saved time on the PRD. Keep the prompt's contract (inputs, output format, refusal behavior) crisp so it's easy to spec against later.
-
AI output evaluation & rubric (after Topic 5) — A systematic evaluation of the Copilot's drafted replies against a self-authored rubric scoring accuracy/factuality, relevance, completeness, tone, safety, and instruction-following on 6–8 sample outputs — with 1–3 scores, specific documented feedback per failure, and a summary of recurring failure patterns (e.g. "invents fee amounts"). (~90 min)
- Go deeper if… AI-ops — this is your headline artifact. Expand to 12+ outputs, report it like a metric you'd put on a dashboard: pass-rate per criterion, the eval gate you'd block a release on ("ship only if safety pass-rate = 100% and factuality ≥ 90%"), and which checks could run automatically vs. need a human spot-check. Note how you'd re-run this eval as a regression suite when the prompt or model changes. AI PM — translate the rubric into the "good enough" quality bar you'll reuse verbatim in the PRD (Deliverable 4); be explicit about which criterion is the launch-blocker. Prompt engineer — tie each failure pattern back to a concrete prompt fix so the eval visibly closes the loop with Deliverable 1.
-
Responsible-AI risk register & human-in-the-loop plan (after Topic 7) — A risk register covering hallucination, bias, privacy/PII, over-reliance, and misuse — each with likelihood/impact, a concrete mitigation, and a decision on where a human must review or override — plus the AI-disclosure and verification policy for customer-facing replies. (~75 min)
- Go deeper if… AI-ops — make the mitigations operational: for each risk, name the signal you'd monitor in production and its threshold (e.g., "track % of drafts edited by agents before send; alert if it crosses 30%", "log every guardrail trip and review weekly"). Specify what's auto-blocked vs. human-reviewed and who gets paged. AI PM — focus on the human-in-the-loop placement decision and the policy trade-offs (coverage vs. safety); this is the judgment a PM owns. Prompt engineer — a solid pass is fine; just make sure each risk you can mitigate in the prompt (refusals, "say I don't know") links back to a specific guardrail in Deliverable 1.
-
AI feature PRD (after Topic 8) — A PRD written for AI's probabilistic nature: problem/goal/user, a quality bar defining "good enough" (tied to your eval rubric), design-for-failure fallbacks, the human-in-the-loop control, a feedback mechanism, user stories, and acceptance criteria including an explicit "AI is wrong/unsure" edge case. (~90 min)
- Go deeper if… AI PM — this is your headline artifact. Go deep on the quality bar and success metrics (north-star + guardrail metrics, how you'd measure them post-launch), crisp acceptance criteria for the wrong/unsure edge case, a rollout plan (shadow mode → assisted → wider), and explicit scope cuts. Make it something an eng lead could estimate from. AI-ops — strengthen the monitoring and feedback-loop sections: what's instrumented, what the dashboard shows, what triggers a rollback, and how the agent-edit signal feeds back into eval. Prompt engineer — a solid pass is fine; make sure the prompt's I/O contract and refusal behavior from Deliverable 1 are reflected accurately in the acceptance criteria.
-
Hands-on build write-up (with RAG) (after Topic 9) — A documented hands-on build: implement your Copilot prompt in a real chat assistant (Claude/ChatGPT/Gemini) or a no-code tool, ground it on a small FjordPay knowledge snippet to apply RAG, run it on real-style tickets, and write up what you built, the tools/concepts used (API, RAG, agents), what worked, what failed, with screenshots/transcripts as proof. (~90 min)
- Go deeper if… AI-ops — this is a headline artifact for you. Run the build through your eval (Deliverable 2) as a live gate: score the real outputs, log every failure and guardrail trip, and show the before/after when you add RAG. Capture the kind of run-time evidence you'd monitor in production (latency, refusal rate, grounding hits/misses). Prompt engineer — show the prompt-vs-context interaction: how grounding changed behavior, where the prompt still had to compensate, and the final wording you'd ship. AI PM — a solid pass is fine; focus the write-up on whether the result clears the PRD's quality bar and what you'd cut or change before a real launch.
-
Portfolio case study & pitch (after Topic 10) — A one-page portfolio case study assembling the prior deliverables into one narrative — problem, what you built, how you evaluated and de-risked it, the impact, and the domain + AI framing — plus a 90-second spoken pitch script you can deliver in an interview to walk a hiring manager through the project. (~60 min)
- Go deeper if… (every lens) — lead with the spike. Name your lens in the first lines and make the artifact you went deepest on the centerpiece of the story: AI PM — "I defined the quality bar and the wrong/unsure spec"; prompt engineer — "I iterated the prompt from 40% to 95% safe across N rounds, here's the log"; AI-ops — "I built the eval gate and the monitoring that keeps it safe in production." The other five deliverables become supporting evidence for the role you're pitching, not six equal-weight bullets.
What "done" looks like
A complete capstone is six artifacts about one AI feature, each passing its rubric, assembled into a portfolio you can link from your resume and walk through in interviews. This is exactly what Topic 10 tells you to build — and the case study and pitch in Deliverable 6 are the package a hiring manager sees first. When you reach the interview prep and the program schedule, you'll practice presenting these artifacts the way you would to a hiring manager.
What the finished portfolio demonstrates about you
A hiring manager reading this portfolio can see that you can:
- Engineer prompts, not just write them — structure a reliable prompt and iterate it methodically when it fails, rather than relying on one lucky try (Deliverable 1).
- Evaluate AI like an operator — define a rubric, score outputs honestly, spot hallucinations, and name recurring failure patterns instead of trusting the model (Deliverable 2).
- Reason about risk and ethics — anticipate hallucination, bias, PII, over-reliance, and misuse, and decide where a human must stay in the loop on a money-sensitive feature (Deliverable 3).
- Specify probabilistic features — write a PRD that designs for failure and defines "good enough" with a measurable quality bar, which is what separates AI PMs from traditional PMs (Deliverable 4).
- Actually build — ship a working, RAG-grounded prototype and report honestly on what worked and what didn't, proving you've touched the real tools, not just the theory (Deliverable 5).
- Tell the story — frame the whole project as domain expertise + AI judgment and pitch it in 90 seconds (Deliverable 6).
Together these say the thing employers most want to hear about a non-traditional AI-adjacent candidate: you can be trusted to put AI in front of real users and know where it must not act alone.
Tips
- Keep it real and specific. "Make the AI safe" is weak; "block any reply that states a fee amount not present in the knowledge snippet, and route it to a human" is the kind of concrete guardrail this work is judged on.
- Reuse your earlier work. Your eval's failure patterns should visibly drive your risk register; your quality bar should reappear in your PRD's acceptance criteria — graders (and employers) love a coherent thread through all six deliverables.
- Own your lens. Clear every deliverable's rubric, but pour your extra effort into the one or two the Pick your lens table points you to — the PRD if you're an AI PM, the prompt spec and iteration log if you're a prompt engineer, the eval gate and monitoring if you're AI-ops. A portfolio with one deep spike beats six shallow-but-even artifacts; the spike is what convinces a hiring manager you can do that job.
- Be honest about failure. The build write-up that documents what broke and why is stronger than one that claims everything worked. Catching your own AI errors is the exact signal these roles hire for.
- Use the templates in
../templates/as starting points —prompt-spec.md,ai-output-evaluation.md,risk-register.md,ai-feature-prd.md,build-writeup.md, andportfolio-case-study.md— and revise based on the AI feedback rather than aiming for perfect on the first try (that's the whole loop).
Interview prep
Open-ended drills with a framework, model answer, and scoring rubric.
Templates
Reusable fill-in artifacts you’ll use across the capstone.