Discovery's oldest bottleneck, meeting the newest way of building

I've coached hundreds of product teams since 2011. Plenty of them took user testing seriously and ran good research. But only a few sustained the strict version, customers in the building every single week, and the two that stayed with me are MySugr and Wooga. They did what the playbooks had recommended for years. Most teams find that weekly rhythm hard to keep.

What the playbook asks for

Jeff Gothelf put a rhythm under it in Lean UX — the 3-12-1 week in the calendar above: three users, at 12 noon, on one fixed day each week. Decide on Monday what you need to learn, then run those three users every Thursday. Teresa Torres named it continuous discovery and set the bar at weekly touchpoints with customers, by the team building the product. The advice itself was never the problem. MySugr and Wooga show it works. The question is why the weekly rhythm is so hard to hold.

Motivation was rarely the bottleneck

It wasn't that the other teams didn't care. Many of them wanted the weekly cadence and tried for it. What set MySugr and Wooga apart was logistics. Both had one person whose job was the plumbing: recruiting the right people, booking the slots, chasing the no-shows. Take that person away and the cadence tends to fade. Not through a decision, just a calendar that slowly empties.

Even the people who teach it admit this

Torres says it plainly: the biggest barrier to continuous interviewing is finding someone to talk to, week after week. Her line is, "if you have to hustle to find a customer to talk to every week, you will not do it." Gothelf budgets up to four hours a week just for recruiting and scheduling, and tells teams to outsource it when it gets untenable. The hard part of discovery was rarely the talking. It was getting people in the room.

One team that solved the plumbing

Which is exactly what makes Bolt worth a look. Bolt runs more than a hundred research interviews a week, through a program called Call Your Customers. Not in a sprint, not in a quarter. Every week. I rarely see discovery running at that level, and what makes it work is exactly what you'd expect by now: an operations function whose whole job is making those conversations happen.

A panel is not your users

Should you buy a research panel or recruit your own users? You can buy your way to volume. Plenty of platforms will recruit testers for you, and I've used them a lot. The upside is real: it's quick and easy. There are trade-offs too. You pay per participant, the quality can vary, and you have limited control over who actually shows up. A panel tends to give you people you don't yet have a relationship with.

Bolt wanted its own riders and drivers, the real users. And here's a part I think product people often underrate. Recruiting your own users isn't only about better sessions. It's a capability worth owning. Every session becomes a relationship with a customer rather than a rented hour. The testing turns into a channel. You learn how to find your people, how to reach them, how to keep them coming back, and that muscle pays off well beyond research.

That's also why the panel-or-build question really turns on one thing: whether you already have access to your own users. Bolt has them in large numbers, so building its own recruiting on top of that base is the natural move, and that build becomes the real alternative to a panel.

A startup sits in the opposite spot. It usually has few users, sometimes none yet, so its recruiting problem is a different one: getting access to users at all. Here a panel can be a genuinely useful way to get the first conversations going. But it's worth seeing what sits underneath. Finding real users for a product that has no audience yet is exactly the capability a startup has to build anyway, and doing the recruiting yourself is the proof that you can reach your market and start a relationship with it. The same question comes back for a new product inside an existing scale-up: it has no audience of its own either, so it's effectively in startup mode again. That's why, in most cases, I'd still lean toward building my own recruiting before renting someone else's.

What just changed

Owning your recruiting used to mean a dedicated ops team, the thing almost nobody could sustain. That friction, all the recruiting and scheduling, is exactly the kind of work agentic AI has become good at. A single person can now run a discovery channel that once needed a department, and the cost of running your own keeps dropping. The thing that used to need a team is starting to fit on one screen.

The case behind this: recruiting, built by the person closest to it

That is what I watched happen at Bolt. The bottleneck I described, recruiting, is exactly what they set out to automate. The no-code route came first, n8n and Zapier, and it didn't really crack the problem. What worked was different. The software composes Bolt's existing infrastructure into something new, and that only worked because the person building it already knew that infrastructure inside out. The research operations specialist built it himself, with coaching from me. This is less vibe coding than engineering, done by the person who already knew the system from inside.

A third option for building software

There's a long-running build-or-buy question for internal software, and I think there's now a third answer. For years, building your own tools meant misery. I lived it at Forto and Zalando, half-broken spreadsheets and teams near a breakdown, building tools nobody really owned. Those projects were never greenfield. They carried years of context, and that's exactly what made them brutal. That same context is now the advantage, because the person who carries it can finally build with it.

Buying SaaS or writing software from scratch used to be the only two options. There's a third one now.

Software research saw this coming

Brad Myers and Margaret Burnett's work on end-user software engineering documents what happens when a domain expert builds the tool they need: no requirements handover, no telephone game between the person with the problem and the person typing the code, and a far tighter loop between use and change.

XP saw the same pattern from the other side. Kent Beck's onsite-customer practice put the real user in the room with the engineers every day, because every step the requirement traveled away from that user cost the team accuracy.

The bet now is one step further. The onsite customer is the builder.

Shopify's Tobi Lütke runs his entire company on a version of this. Shopify itself started as the internal tool he built for his own snowboard shop, and the company never stopped building its own. He quotes McLuhan to explain why:

"First, we make the tools, and then they shape us." — Marshall McLuhan, quoted by Tobi Lütke (CEO, Shopify), Cheeky Pint, October 2025

His point goes further than efficiency. If you want to change how people work, the leverage isn't in the policy memo. It's in the tool on their screen every day.

Where this lands

Discovery's oldest bottleneck, meeting the newest way of building. I've been pondering at podojo what that means in practice. For the operator who finally builds the thing they always wanted. For the engineering org that has to figure out how to support it. For the SaaS that gets composed into something it didn't expect. I don't think it replaces the dedicated ops function everywhere. I do think it gives a lot more teams a real shot at the weekly cadence Torres and Gothelf were describing all along.

What's next

This is the first of three follow-ups I'm writing from the Bolt case.

• From inside Bolt. What it actually felt like to build the thing — from the first prototype, through the team relying on it, to the moment recruitment stopped having to go through the ResOps function at all.
• What has to be true around it. The culture and leadership conditions that let agentic engineering take root inside the organisation rather than around it.
• Where the technical edges are. What breaks when a non-engineer ships software the team depends on, and what scaffolding you need to put underneath it.

If any of that resonates already, drop me a line.