Senior PM, PayTax. Take-home case study, an onsite presentation, and a 45-minute design workshop. The centerpiece was a one-hour interview with a small business owner in Richmond, Virginia who handles garnishments by hand. I did not advance. The recruiter feedback is below, verbatim.
Pick a long-standing institution that people interact with regularly but where the product or servicing experience is sub-par, and reimagine it. Justworks gave a list of suggested topics ranging from DMV redesigns to airline boarding to wage garnishment processing. Candidates could also propose their own.
The brief explicitly called for problem definition, customers and pain points, success metrics, hypothesis and scope, constraints and risks, and a few solution directions, with the workshop closing the loop into a tightly scoped MVP.
I shortlisted six topics, including some original ones (a Plaid-style address-change hub, a uniform job posting standard), but landed on wage garnishment processing for a specific reason: a long-time friend of mine runs a small business and I knew he dealt with garnishments. I work best when I'm starting from a real problem, and the fastest way for me to start is a conversation with someone who actually lives the workflow. The topic was a means to that conversation. Garnishments also happen to sit directly inside Justworks' domain, map to product surface area they could build now, and give a workshop a sharp problem to scope. So the topic was strong on its merits. But the deciding factor was access to a real user.
I picked garnishments because a long-time friend of mine runs a small business and I knew he dealt with garnishments. I work best when I'm starting from a real problem, and the fastest way for me to start is a one-hour conversation with someone who lives the problem. He made time, would tell me the truth, and walk me through the actual process as he experiences it, which is gold. That's the topic-selection criterion that mattered most to me.
He runs a non-emergency medical transportation company in Richmond, Virginia, with eighteen employees, mostly 1099. He handles all HR, payroll, dispatch, training, and garnishment processing himself. He gets about four garnishments a year. We talked for an hour.
Most candidates will read ADP white papers. Almost none will sit with a sole proprietor in Richmond and ask him to walk through what arrives in the mail and what he does with it. That's the difference between desk research and a case study. The full transcript is in the downloads.
Justworks already processes garnishment deductions through payroll at no extra charge and responds to withholding notices on behalf of PEO clients. The core deduction is handled. The opportunity is the employer-facing workflow around it: order intake, interpretation of ambiguous withholding, lifecycle tracking, status visibility. The prompt rewards "extend an existing capability," not "ship a new product from scratch."
The 45-minute workshop was the second half of the room and the part most candidates under-prepare. I built a Figma board with prepared frames, prompts, and a flow that walked the panel from the four solution directions to a scoped MVP and a rough wireframe. The before-and-after of that board is in the Deliverable section below.
Five days before the submission deadline I had a prep call with the recruiter and walked her through both the deck and the workshop. She gave feedback. She specifically liked the voting dots and the participation design of the workshop. I also walked the materials through with a colleague in my career group, who gave me sharper feedback on the deck pacing and the V1 narrative. Two rounds of preview before the panel saw anything. None of this stopped the panel from giving me the feedback they did, but it's worth saying that the materials weren't built in a bubble.
Two artifacts. The presentation deck (below). And the Figma board I designed for the workshop, with a before/after view so you can see what the panel and I co-produced in 45 minutes.
Use the deck controls to advance slides. Open in Google Slides ↗
This is what I walked into the workshop with. The frames I prepared to take the four solution directions from the deck and converge on a tightly scoped V1 with the panel.
This is what we landed on together in the room. The panel weighed in on must / should / won't, scoped the MVP, and we sketched the order-intake flow with the engineer at the table.
The room felt good. The team engaged hard with the interview material. The "disposable income" insight got a real reaction. The workshop ran mostly on time (some sections were faster than others) and we landed on a tight MVP. I walked out thinking I'd presented well and read the room well.
One detail worth stating plainly: the hiring panel, three people from product, engineering, and data engineering inside Justworks, did not know that employers are legally accountable if a garnishment isn't paid correctly. This had me feeling like I had done enough research to at least moderately impress the group.
I did not advance. The recruiter shared feedback on a debrief call. Here it is, as she relayed it:
"Justworks panel feedback. Research good, understood the craft, sense, customer focus. Improve: stronger solutioning for users, additional clarity to see where they were going. Cool down: 6 months."
I don't agree with most of it, and I want to say why honestly. Not because the feedback was unkind, but because the disconnect between the room I was in and the rubric I was being measured on is the actual lesson here. I did ask if they wanted me to whiteboard the interface, but even that felt inauthentic since design wasn't in the room. I did verbally review the roadmap that we collectively built and laid out as the closer instead. Now I wonder if I should have mocked up the interface to make it more clear and close with next steps.
I built a Figma board with voting dots, prompts, and frames designed for the panel to use. I previewed it with the recruiter beforehand. She liked it. When I got into the room, the hiring manager wanted me to lead the whole thing. So which is it? Is this a collaboration simulation or a solo presentation in a room with witnesses?
Nobody typed into the board except me. Nobody moved a sticky except me. I'd pre-filled most of the workshop to save myself from live typing, which turned out to be a good call, because if I hadn't, the boards would have stayed empty. So why have a digital whiteboard at all? The setup made sense for actual collaboration. It made no sense for what actually happened.
The takeaway I'm carrying forward: don't trust an interview format that calls itself collaborative. Build the workshop assuming you'll do all of it yourself, and let any real participation be a bonus.
The Round 4 invitation said the panel would include "members of the product, design and engineering team." The actual panel was three people: a Group Product Manager (the hiring manager), a Senior Director of Product, and a Data Engineering Manager. The Senior Software Engineer who was on the original invite couldn't attend. No designer was ever in the room.
Late in the presentation someone asked when I'd engage with design on this work. My answer was "design should be in this meeting." Which is correct, and which I'd say again. A wage garnishment workflow is fundamentally a design problem before it's a roadmap problem. If the panel intended to evaluate how I work with design, they'd needed to actually put one in the room.
I closed the presentation with a phased feature roadmap and a section on how to build employer trust over time. That's about as clear a "where this goes" as a 20-minute deck supports. Hypothesis, success metrics, scope, four solution directions in priority order, all on the slides. If the panel wanted MORE clarity than a phased roadmap and an explicit hypothesis with success metrics, then the rubric was something other than "show us where this goes."
There's also a specific moment that makes this feedback hard to take. As the workshop was running low on time, I offered to mock the roadmap on a physical whiteboard, which I'd confirmed with recruiting in advance would be in the room. The panel said no, just walk them through it. So I walked through the roadmap we'd just built. They later told the recruiter next steps weren't clear. In a real working meeting, colleagues who want more detail push for it. They asked for less, then graded me on more. That's the same fake-collaboration pattern showing up a second time.
I came in with four solution directions and let the workshop converge on one. The prompt explicitly asked for "light ideation" and convergence in the workshop, so I built to that brief. But a different panel could read four directions as not enough conviction, and this panel did. Fair critique. The version I'd run next time leads with one recommendation and defends it, with the alternatives in the appendix.
The workshop wasn't a workshop. It was a presentation that the panel sat through, scored against checkpoints I couldn't see, in a format that promised participation and didn't deliver it. When the rubric doesn't match the activity, the candidate gets feedback that doesn't quite land. That's where I think this came from.
None of this is sour grapes about a "no." Plenty of "no's" are just "no's" and I take those on the chin. This one I'm publishing because the misalignment is the lesson. If you're a candidate prepping a workshop, build it for one hand to do all the work. If you're a hiring team running this format, decide which one it is and tell candidates upfront. Either format works on its own. Mixing them is what produces feedback that doesn't connect to what actually happened.
Build the workshop expecting to fly solo. The biggest lesson. Pre-fill every frame, every prompt, every recommendation. If the panel actually engages, that's a bonus. If they don't, the boards still tell a complete story without anyone else lifting a pen. Voting dots and open prompts assume reciprocity that isn't guaranteed in an interview format.
Show, don't tell, where it's going. One mid-fidelity wireframe of the order-intake flow would have done more for "see where they were going" than three slides of solution-direction copy. Even a screenshot from a working clickable prototype.
Bring the user into the room more directly. The user's voice was in the deck, but a 30-second audio clip from the interview would have changed the room. Real product teams play user clips in reviews for a reason.
Recruiters are not reliable narrators. Five days before the onsite I had a prep call with the recruiter. She walked through both the deck and the workshop, liked the participation design, and sent me into the room confident. The panel didn't engage with the materials the way she'd reacted to them. That's not on her, but it does mean a recruiter's read is a recruiter's read, not the panel's. Next time I'd ask directly: "Will design be in the room?" and "When you say 'collaborative workshop,' what does the panel expect to participate in versus observe?" If the answers are vague, push for specifics. Recruiters answer those questions if you ask them clearly. And if a hiring manager prep call is available, take it over the recruiter version.
Everything I used or produced. The interview transcript is the most reusable piece if you're doing payroll or compliance work.