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 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 does not belong in engineering sprints. It belongs in prototyping. I have been doing it at Smartcat for six months, and it is the single biggest improvement to how my team works since I started using AI coding tools.
The idea
One day per week, the product trio, PM, designer, and engineer, sits together in the same room or the same Zoom and builds a working prototype. Not a mockup. Not a spec. A functional thing a customer can use. One screen, one keyboard, three brains, eight hours.
Why it works when production mobbing does not
Four things flip when you move from production code to prototyping. The decisions are different: production decisions are technical and reward individual expertise, while prototype decisions are product decisions like should the user see their match score before or after they click apply, and those benefit from PM, design, and engineering in the room at once. The feedback loop is immediate: you build, look at it together, react, and change it. The cost of being wrong is near zero: you throw the code away. And the goal is learning, not correctness.
What the day looks like
Thursday is our mob day. 30 minutes framing, where the PM presents the opportunity backed by signal data, not a spec. 2.5 hours building, engineer driving while PM and designer shape in real time. Lunch. 2 hours iterating and polishing, where the build-react-fix cycle runs a dozen times, each cycle 5 to 15 minutes. 1 hour of test prep, deploy a shareable link and line up which customers to call Friday. 1 hour documenting, where the engineer writes the technical note that becomes the future spec, the PM writes the test script, and the designer captures design decisions.
The math
Without the mob: PM writes a spec, designer mocks, review meeting, revision cycle, engineer builds, PM reviews, engineer fixes, designer reviews, engineer fixes again. Total, 41 person-hours across two to three weeks. With the mob: three people in a room for eight hours. Total, 24 person-hours in one day. You also delete an entire category of waste, misalignment, because there are no handoffs to interpret differently.
This week, pick one opportunity you have heard from customers or seen in your signal data. Block one day, all three people, no other meetings. Start with 30 minutes of framing, then build. End the day with a deployable link and three customer calls scheduled for the next morning. Try it once. If the prototype is better than what you would have built alone, you have your answer.