Mob Prototyping: One Day, One Room, One Prototype

The short version

Mob programming is a bad idea for production code. Three engineers staring at the same function gives you one engineer's output for three salaries. But for prototyping, it's the opposite. One day a week, your trio (PM, designer, engineer) sits together with one screen, AI coding tools like Claude or Cursor, and builds a working prototype in eight hours. The math works because prototyping is primarily a decision-making activity, not a production activity. The week's structure: 30 minutes framing, 2.5 hours building, lunch, 2 hours iterate-and-polish, 1 hour test prep, 1 hour document and park. By Friday, you're showing the prototype to three customers. I've been doing this at Smartcat for six months. It's the single biggest improvement to how my team works.

I wrote a post a while back arguing that mob programming is mostly a bad idea. I stand by that for production code. Three engineers staring at the same function for hours while one person types is a productivity disaster. You pay three salaries and get one person's output.

But I was wrong about where mob programming belongs.

It doesn't belong in engineering sprints. It belongs in prototyping.

The idea

One day per week, your product trio, PM, designer, and engineer, sits together in the same room (or the same Zoom with screen share) and builds a working prototype. Not a mockup. Not a spec. A functional thing that a customer can use.

One screen. One keyboard (usually). Three brains. Eight hours. By end of day, you have something to show a customer tomorrow.

I started doing this at Smartcat six months ago. It's the single biggest improvement to how my team works since I started using AI coding tools.

Why this is different from mob programming

Traditional mob programming fails because it applies a high-coordination format to work that doesn't need it. Writing production code is mostly an individual cognitive task. Adding more people doesn't make it faster. It makes it slower. The driver-navigator model creates a bottleneck where the driver can only type as fast as the group can agree on what to type.

Prototyping is fundamentally different. Here's why.

The decisions are different. Production code decisions are technical: "Should this be a class or a function? What's the right data structure?" Those decisions benefit from individual expertise, not group consensus. Prototype decisions are product decisions: "Should the user see their match score before or after they click apply? Should onboarding be three steps or five?" Those decisions benefit enormously from having PM, design, and engineering perspective in the room simultaneously.

The feedback loop is different. In production coding, feedback comes from tests, code review, and eventually users, days or weeks later. In prototyping, feedback is immediate. You build something, look at it together, react, and change it. That rapid evaluation loop is exactly what a small group is good at.

The cost of being wrong is different. Wrong production code costs you rework, technical debt, and deployment risk. Wrong prototype code costs you nothing. You throw it away and try a different approach. When the cost of being wrong is near zero, speed of exploration matters more than precision of execution. And a group exploring together covers more ground than an individual.

The goal is different. Production code aims for correctness. Prototyping aims for learning. You're not trying to write elegant code. You're trying to answer the question: does this solve the customer's problem? Three perspectives answering that question simultaneously is genuinely faster than one.

What a prototype mob day looks like

Here's my actual schedule for Thursdays, which is our mob prototype day.

9:00 AM: Frame the problem (30 min)

The PM (usually me) presents the opportunity we're exploring. Not a spec. Not a PRD. A problem statement backed by signal data.

"This week, 38 support tickets mentioned export timeouts. Enterprise customers with datasets over 10,000 records are hitting a wall. Three of them are in renewal conversations. Here's a prototype concept: a streaming export that shows progress and lets them download partial results."

The designer reacts: "What if instead of a progress bar, we show them the data populating in real time so they know it's working?"

The engineer reacts: "Streaming is actually easier than batch for this. We could use server-sent events. Want me to spike it?"

In 30 minutes, everyone has context. Everyone has an opinion. Everyone understands why this matters. In the old model, this alignment took a week of async back-and-forth across three separate conversations.

9:30 AM - 12:00 PM: Build together (2.5 hours)

This is where it gets interesting. The engineer drives. They're typing. But the PM and designer aren't watching passively. They're actively shaping what gets built in real time.

The engineer starts building the export flow. The designer says: "Make the button say 'Export All' not 'Download CSV.' And put it above the fold, not buried in a menu." The PM says: "Can we add the record count? If they see '12,847 records' they'll understand why it takes a moment."

Every design decision that would normally take a Slack thread and a Figma review happens in 10 seconds. The designer sees the actual UI being built, not a mockup of what it might look like. The PM sees whether the flow matches the customer problem, not an abstract wireframe.

The AI coding tools matter here. The engineer isn't writing every line from scratch. They describe what they need, Claude or Cursor generates it, and the trio evaluates together. "That looks right but the spacing is off." "Can we add a cancel button?" "What happens if they navigate away mid-export?" Questions that would be backlog items in a spec-driven process get answered in real time because all three people are watching the code come to life.

12:00 PM: Lunch break

Step away. Let the morning's decisions settle.

1:00 PM - 3:00 PM: Iterate and polish (2 hours)

You come back and click through what you built. This is the part that's impossible to replicate asynchronously. Three people clicking through a prototype together, reacting out loud, catching things the others missed.

The designer notices the loading state feels janky. The engineer fixes it in two minutes. The PM says: "Wait, what if the customer has two datasets? Can they export both at once?" The engineer tries it. It works. But the UI gets confusing with two progress bars. The designer sketches a solution on the whiteboard. The engineer implements it in 15 minutes.

This cycle, build, react, fix, build, react, fix, runs a dozen times in two hours. Each cycle takes 5 to 15 minutes. By 3 PM, the prototype has been iterated more times than most features get iterated in a full sprint.

3:00 PM - 4:00 PM: Test prep (1 hour)

Now the trio shifts to planning how to test it. The PM identifies which customers to show it to. The designer adds one more polish pass so it doesn't feel obviously rough. The engineer deploys it to a shareable link.

By 4 PM, the prototype is live, polished enough to show a customer, and the PM has three customer calls scheduled for Friday.

4:00 PM - 5:00 PM: Document and park (1 hour)

The engineer writes a quick technical note: "Here's what we built, here's what would change if we built it for real, here's the estimated effort." This is the future engineering spec, written by the person who already understands the solution because they built it.

The PM writes the test script: what to ask customers, what to watch for, what counts as a pass.

The designer captures the design decisions: why we chose this layout, what alternatives we considered, what we'd refine in production.

One day. One prototype. All three perspectives baked in from the start.

Why the trio matters more than the tech

You could argue that a PM alone with AI coding tools can build a prototype in two hours. I've written about that. It works. But the mob approach produces a better prototype, and here's why.

The PM doesn't know what's feasible. I've prototyped features that looked great to me but an engineer would immediately say "this approach doesn't scale" or "there's a much simpler way to do this." When the engineer is in the room, the prototype is architecturally sound from the start. The path from prototype to production is shorter because the prototype was built with real engineering constraints in mind.

The PM doesn't think in design patterns. I'll build a flow that works but has six screens when a designer would say "this can be two screens with a toggle." The designer in the room reduces complexity in real time. The prototype is more intuitive because design thinking shaped it during construction, not after.

The engineer doesn't know the customer context. Left alone, an engineer builds for correctness and edge cases. In a prototype, that's wasted effort. The PM in the room keeps saying "we don't need that yet" and "the customer would never do that" and "the important thing is this one flow." The prototype stays focused on the learning goal instead of growing into a mini-product.

Nobody builds in a vacuum. The biggest benefit is harder to quantify. When three people build something together, they have shared context. There's no handoff meeting needed. No spec interpretation arguments. No "that's not what I meant" in code review. Everyone knows what was built and why because they were there.

The math actually works (for prototyping)

My argument against mob programming for production code was about productivity math. Three engineers producing one engineer's output is a bad deal. Let me run the same math for prototype mobbing.

Without mob prototyping: PM writes a spec (4 hours). Designer creates mockups (6 hours). Review meeting (2 hours, times 3 people = 6 person-hours). Revision cycle (4 hours across all three). Engineer builds prototype (8 hours). PM reviews, finds issues (2 hours). Engineer fixes (4 hours). Designer reviews, finds issues (2 hours). Engineer fixes again (3 hours).

Total: 41 person-hours across 2-3 weeks.

With mob prototyping: Three people in a room for 8 hours.

Total: 24 person-hours in 1 day.

The mob is cheaper and faster. Not because mob programming is inherently efficient (it isn't, for production code). Because prototyping is primarily a decision-making activity, not a production activity. And decision-making is faster when the decision-makers are in the same room reacting to the same artifact.

You also eliminate an entire category of waste: misalignment. Every spec that a designer interprets differently than the PM intended, every mockup that an engineer implements differently than the designer drew, every review cycle that sends it back because "that's not what I meant." All of that waste disappears when you build together.

What this looks like after a month

Week 1: You prototype a streaming export feature. Customer reaction: "I love it but I need it to go directly to our data warehouse." You learn the real problem is integration, not speed.

Week 2: You prototype a direct Snowflake export. Customer reaction: "Yes. This. When can I have it?" Engineering estimates production build at 3 weeks. You greenlight it with confidence because you've already tested the concept.

Week 3: You prototype a new onboarding flow for enterprise customers. Customer reaction: "The flow is fine but I don't understand what 'workspace configuration' means." You learn the problem is naming and education, not UX. You fix it in the prototype in 20 minutes.

Week 4: You prototype two competing approaches to a notification system. You show both to customers and let them pick. One wins decisively. Engineering builds only the winner.

Four weeks. Four prototypes. Four decisions backed by real customer feedback. In the old model, you'd still be in design review for the first one.

When not to do this

Mob prototyping isn't for everything.

Don't mob on incremental improvements. If you're adding a sort option to a table, just build it. You don't need three people to figure out how dropdown sorting works.

Don't mob on technically complex spikes. If the engineer needs to figure out whether streaming SSE works with your infrastructure, let them do that alone. The PM and designer don't add value to a technical feasibility investigation.

Don't mob when you don't have a clear opportunity. If you're mobbing on "let's brainstorm what to build," you'll spend a day building random things. The opportunity should be identified before the mob day starts. Signal data, customer interviews, or a clear pattern from your discovery engine should tell you what problem to solve. The mob day is for building the solution, not finding the problem.

Don't mob every day. One day per week. That's the sweet spot. More than that and you're cutting into the individual deep work that everyone needs. The PM needs time for customer conversations. The designer needs time for design system work. The engineer needs time for production code. One day of joint prototyping fuels the rest of the week.

How to start

This week: Pick one opportunity your team is exploring. Something you've heard from customers, something that showed up in your signal data, something you've been debating in Slack for too long.

Block one day. All three people, full day, same room or same video call. No other meetings. No Slack during the session (except breaks).

Start with 30 minutes of framing. PM presents the problem. Everyone aligns on what you're building and why.

Then build. Engineer drives. PM and designer shape the solution in real time. Use AI coding tools. Iterate fast. Don't worry about code quality, you're building a prototype.

End the day with a deployable link and a plan for who you're showing it to tomorrow.

Friday: Show it to 3 customers. Get feedback. Decide: build it for real, iterate next Thursday, or kill it.

I was skeptical of mob programming for years. I'm still skeptical of it for production code. But for prototyping, putting the whole trio in front of one screen for one day a week is the fastest way I've found to go from opportunity to validated solution. It eliminates handoffs, compresses feedback loops, and produces prototypes that are better than what any one person would build alone.

Try it once. One day, one room, one prototype. If the prototype is better than what you'd have built alone and the customer feedback is sharper than your last spec review, you have your answer.

Sources: Claude, Cursor, Slack, Figma.