InterviewIntermediateResponsible AI & Advanced Practice / Building an AI PM portfolio / #19
Describe the portfolio you would build in 30 days starting from zero.
SPARK the portfolio piece is Fernbrook Match, an AI tool that pairs volunteers to community programs by skill and availability
Fernbrook Community Trust is a fictional nonprofit that runs volunteer programs for local community groups. Thandiwe Mabaso, a customer support lead job-hunting into AI product roles, chose it as her 30-day sprint: an assistant that matches a volunteer's skills and free hours to the program that actually needs them. Casper Lindqvist, her mentor, checks in with her every Sunday.
The direct answer
Build one project, start to finish, not three half-built ones. Five days to scope it to one real problem, fifteen days to build and test it against a real eval set, five days to write it up with the tradeoffs you rejected, and five days to get two real people to read it and rebuild whatever they get stuck on. One finished, defensible project beats three demos that never got past "it mostly works."
Do this, in order
Pick one narrow, real problem in the first five days, and stop looking for a better idea after that.Why: a 30-day clock can't survive a week three pivot to a completely different project.
Spend the middle two weeks building and testing against a real eval set, not polishing a demo.Why: an eval set is what turns "it works" into a number someone else can check.
Save five full days at the end just for the write-up.Why: a rushed write-up on day 30 undersells thirty days of real work.
Get two real people to react to it before you call it done.Why: you can't see your own blind spots on day 29 the way a fresh reader can.
Have a pivot plan ready in case the model just doesn't work well by day 20.Why: thirty days is tight enough that you need a fallback decided in advance, not invented in a panic.
Skip a polished front end, a deploy pipeline, or a second project entirely.Why: none of that proves judgment, and all of it eats days you don't have.
How to answer this, stage by stage
Nobody is grading whether your 30-day plan is exactly right. They're grading whether you'd actually finish something real by day 30.
Stage 1
Scope it to one real starting point
Say it like this
"Say I've got thirty days and nothing built yet. I'd spend it on one project: a volunteer-matching assistant for a community nonprofit."
Why this works
Commits to a concrete plan immediately, instead of describing portfolios in the abstract.
Stage 2
Say your structure out loud
Say it like this
"I'll use SPARK. Situation, where I'm starting from. Payoff, the habit I want the sprint to build. Anchor, the one plan I commit to. Risk, what happens if I'm wrong. Keep out, what I deliberately skip."
Why this works
Shows this is a designed plan, not just a to-do list with dates attached.
Stage 3
Say the payoff you actually want
Say it like this
"I don't want three projects that all 'mostly work.' I want one habit: finishing something real enough that a stranger could poke at it."
Why this works
Names the real goal of the sprint, not just the deliverable.
Stage 4
Give the anchor, the actual plan
Say it like this
"Five days to scope it, fifteen to build and test it against a real eval set, five to write it up, five to get real people to react and fix what they get stuck on."
Why this works
This is the answer to the question. Concrete days, concrete phases.
Stage 5
Say what happens if it's wrong
Say it like this
"If day 20 comes and the model's genuinely not good enough, I don't panic-rebuild. I write up the failure honestly instead, that's still a real, defensible project."
Why this works
Shows the plan survives its own worst case instead of assuming everything goes smoothly.
Stage 6
Say what you're deliberately skipping, and close
Say it like this
"No fancy front end, no deploy pipeline, no second project. None of that proves judgment, and all of it eats days I don't have."
Why this works
Ends on a clear boundary, showing judgment about what not to build, not just what to.
Let's learn
A volunteer-matching assistant is a tool that reads what a volunteer can do and when they're free, and points them at the community program that actually needs exactly that.
Thandiwe started with zero: no project, no code, thirty days before her first real AI PM interviews. Casper's first question to her wasn't "what will you build," it was "how will you spend the days."
Knowledge spark: what's a golden set?
A small pile of real or realistic test cases you check a model against, so a claim like "it works well" turns into a number someone else can actually verify.
Her first instinct was to sketch three different project ideas and start all three at once, hedging her bets. Casper pushed back hard on that plan specifically.
Hours planned per week, by phase of the 30-day sprint
Building takes up the middle two weeks almost entirely. Writing and testing only get real hours once something real actually exists to write about.
Here's the turn: the risk in thirty days was never running out of good ideas. It was running out of days before any single idea got finished enough to defend.
Three half-finished projects prove less than one finished one. Thirty days is enough time for exactly one real proof, not three attempts at one.
At its worst: a candidate spends all thirty days switching between ideas, chasing whichever one feels most promising that week, and arrives at day 30 with three folders of code and nothing a stranger could actually evaluate.
The decision that mattered
Pick one project by day 5, and don't reopen that decision, no matter how tempting a better idea looks on day 12.
What I would leave alone: a genuinely rough, unpolished interface is completely fine for a 30-day project. Nobody's evaluating your front-end skills here, only whether the underlying decision and evidence are real.
The lesson: a tight deadline doesn't reward speed for its own sake. It rewards knowing exactly which one thing is worth finishing, and refusing to trade it for a shinier idea halfway through.
Now here is the same thing as a story
The short version above is what you'd say describing your 30-day plan out loud. Read this one for how Thandiwe actually spent hers.
Thandiwe Mabaso spent six years leading a customer support team, and she can read a frustrated ticket and know within a sentence whether someone needs a refund or just needs to be heard.
Day zero looked like this: nothing built, and a hard deadline already ticking.
Day one, she had three ideas: the volunteer matcher, a donor-outreach summarizer, and a grant-eligibility checker. By day four, she'd sketched rough plans for all three and genuinely believed she could build all of them in parallel.
Casper drew this exact tree on their Sunday call. Thandiwe was already three days into the left branch.
Casper's question was plain: "Which of these three could you actually finish, with a real eval and a real write-up, by day 30?" Thandiwe realized, honestly, none of them, not at the pace she was going.
Committing to this one plan on day 5 was the decision that actually made day 30 possible.
She picked the volunteer matcher on day 5 and didn't reopen the choice again, even when a more exciting idea occurred to her on day 12. By day 20, her matching model's accuracy against a small real eval set of 40 past volunteer placements had climbed from a rough 58% to a stable 88%.
Model accuracy against the eval set, days 6 to 20
If the line had stayed flat near 58% by day 18, Thandiwe's backup plan was ready: write up the miss honestly instead of quietly hiding it.
The real cost of her first four days chasing three ideas wasn't the four days themselves. It was that she nearly spent the whole sprint the same way, never finishing anything real enough for a hiring manager to actually test.
Even her fallback plan was decided in advance, not invented in a panic on day 20 itself.
Chasing all three ideas at once had felt like the responsible move, hedging against picking the wrong one. It stopped feeling responsible the moment Casper's one question showed she wasn't actually finishing any of them.
Every one of these four was tempting at some point during the thirty days. None of them made it into the final build.
I started three projects to hedge my bets. It took one direct question from Casper to see that hedging, with thirty real days on the clock, was actually the riskiest plan of all.
SPARK, the 30-day planNot a to-do list. SPARK is what forces a tight deadline to protect its one real decision.
S
Situation. Where you're starting from.
Zero portfolio, thirty days, real interviews already on the calendar.
Names the real constraint before any plan gets built around it.
P
Payoff. The habit the sprint should build.
Not "have a project." Finishing something real enough that a stranger could poke at it.
The habit is the actual product of the thirty days, not just the code.
A
Anchor. The one plan you commit to.
Five days scope, fifteen days build and test, five days write up, five days get tested by others.
The answer to the question itself, concrete enough to argue with.
R
Risk. What breaks if you're wrong.
If the model genuinely isn't good enough by day 20, the write-up pivots to an honest failure page instead.
The anchor survives its own worst case instead of assuming a smooth month.
K
Keep out. What you deliberately skip.
A polished front end, a deploy pipeline, a second project. None of it proves judgment.
Shows restraint, not just ambition, in how the thirty days get spent.
Only one corner of this grid produces something a hiring manager can actually evaluate by day 30.
The recap, one line per letter: situation is starting from zero with a real deadline, payoff is the habit of finishing one real thing, anchor is the four-phase plan itself, risk is the honest-failure fallback, and keep out is everything deliberately left unbuilt.
And if you want to be sure it really works, try it somewhere elseSame five letters, a waste-collection route planner instead of a volunteer matcher. A different building, and this time the thirty days start with a much smaller dataset.
Cinderfield Waste Management is a fictional municipal waste service. Rosalind Verhoeven, starting from zero with the same thirty days, chose an AI tool that predicts which collection routes will run over their scheduled time. Tomas Vitkus, her mentor, reviews her plan.
Mapped onto SPARK: her situation was thirty days and a genuinely tiny real dataset, only two months of route logs available to her. Her payoff was the same habit, finishing something real, not a bigger dataset than she actually had. Her anchor adjusted the phase split: seven days scoping and gathering what little real data existed, twelve days building against that small set with heavy cross-validation instead of a large eval, six days writing up the data limitation honestly as part of the story, five days getting tested by others. Her risk: if the small dataset made the model's accuracy genuinely unstable, her fallback was to reframe the entire project around building a defensible data-collection plan for a future, larger rollout, rather than pretending a shaky model was solid. Her keep out list matched Thandiwe's closely: no polished interface, no second project, and in her case, no attempt to synthetically inflate a small real dataset into a falsely large one.
Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "one project, four phases, five days each for scope and write-up, the rest split between building and testing," and stop.
Cost: there's no budget for paid tools or compute this month. Say so honestly, and scale the project's ambition down rather than skip the eval or the write-up entirely.
The model gets better, for real: if your model performs better than expected by day 15, that's not a reason to add a second project. Use the extra time on a harder eval set instead.
Where people run it wrong.
They start more than one project to hedge their bets, and finish none of them by day 30.
They spend most of the thirty days on the interface, since it's the most visible progress, and run out of time for a real eval.
They treat the write-up as an afterthought for the last evening instead of five real, planned days.
How to use it live. When someone asks what you'd build in thirty days from zero, ask yourself one question first: which single project could you actually finish, eval and write-up included, not just start. Commit to that one, out loud, and don't reopen it.
Flashcards (tap any card to flip it)
1 · THE FRAMEWORK
What framework fits "describe the portfolio you'd build in 30 days from zero"?
Tap to flip
ANSWER
SPARK: situation, payoff, anchor, risk, keep out. The anchor is the concrete four-phase plan itself.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Thandiwe Mabaso, a former customer support lead who built a volunteer-matching assistant for Fernbrook Community Trust in thirty days.
3 · THE HABIT
What did Thandiwe do in her first four days that she had to walk back?
Tap to flip
ANSWER
She sketched plans for three different projects at once, hedging her bets instead of committing to one.
4 · THE ANCHOR
What's the four-phase split across the thirty days?
Tap to flip
ANSWER
Five days to scope, fifteen to build and test, five to write it up, five to get real people to test it.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Starting three projects at once instead of committing to one by day 5, which felt safer but was actually the riskiest plan for a hard thirty-day deadline.
6 · THE NUMBER
Fill in the blank: by day 20, the model's accuracy against a real eval set climbed from 58% to ___.
Tap to flip
ANSWER
88%. If it had stayed near 58%, Thandiwe's backup plan was an honest failure write-up instead.
7 · THE REPLAY
Same thirty days, one project committed to by day 5. What's different by day 30?
Tap to flip
ANSWER
One finished, tested, written-up project exists, instead of three unfinished folders nobody could evaluate.
8 · CROSS PRODUCT TRANSFER
Section 4 answers this again for a different product. Which one, and what's different about the risk step?
Tap to flip
ANSWER
Rosalind Verhoeven's route-overrun predictor at Cinderfield Waste Management. Her risk fallback was reframing around a future data-collection plan, since her real dataset was tiny.
Check yourself Score: 0 / 0
Multiple choice
1. Why does this answer recommend one project over three, given the same thirty days either way?
A. Because building three projects is always technically harder than building one.
B. Because a fixed thirty-day window is only long enough to finish, eval, and write up one project properly, and an unfinished project proves nothing.
C. Because hiring managers refuse to look at more than one project per candidate.
D. Because three projects would require three separate write-ups of equal length.
Show hint
Look at the decision tree comparing three shallow builds to one deep build.
Show answer
B. The constraint is time, not ambition. One finished project is checkable. Three unfinished ones aren't.
True or false
2. True or false: this answer recommends spending significant time in the thirty days building a polished front end.
True
False
Show hint
Look at the "keep out" step.
Show answer
False. A polished front end is explicitly left out, since it doesn't prove judgment and eats days better spent on the build and the eval.
Fill in the blank
3. Fill in the blank: the anchor plan gives ___ days to building and testing, the largest single share of the thirty.
Show hint
Look at the stacked bar chart of hours by phase, and the anchor timeline.
Show answer
Fifteen days. Five for scoping, five for the write-up, and five for outside testing round out the rest.
Short answer, where it wouldn't matter
4. Name a part of a 30-day build where cutting corners is genuinely fine.
Show hint
Look at "what I would leave alone."
Show answer
Model answer: The interface. A rough, unpolished front end is fine, since nobody's evaluating design skill here, only the decision and the evidence behind it.
Short answer, apply it yourself
5. Think of a real deadline you've faced. Did you commit early to one plan, or hedge across several options until time ran out? What would committing earlier have cost you, and saved you?
Show hint
Try to name the actual moment you either committed or kept hedging.
Show answer
Model answer: Most people can name a real deadline where hedging felt safe but actually cost them a finished result, the same pattern Thandiwe caught herself in on day 4.
Short answer, the number question
6. If Thandiwe only had fifteen days instead of thirty, which single phase should shrink the most, and why?
Show hint
Think about which phase can flex without breaking the whole plan.
Show answer
Model answer: The build-and-test phase, since scoping and the write-up both need a real minimum to stay honest, while a smaller eval set can still produce a real, if narrower, result.
Before you close the answer
Why this works
Tests whether you can turn a wide-open, exciting question into a real, committed plan under a hard deadline, and whether you'd protect that one plan instead of chasing a better idea halfway through.
Follow-up traps
"What if a much better project idea occurs to you on day 12?" Response: write it down for later, and stay on the current plan, since reopening the choice mid-sprint is exactly what turns thirty days into zero finished projects.
"Isn't thirty days too short to build anything real?" Response: it's short enough that you have to pick one thing, which is the whole point, a real, narrow, finished project in thirty days beats an ambitious, unfinished one in ninety.
If pressed
Thandiwe's real eval set held 40 past volunteer placements Fernbrook had already made by hand, which she used specifically because it let her measure the model against decisions a real coordinator had actually stood behind, not just her own judgment of what looked like a good match.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
