If you’ve spent any time building products - whether internal tools, customer-facing apps, or the latest machine learning feature - you’ve probably seen this movie before: a burst of creative energy, a flurry of prototypes, and then…silence. The product sits unused, gathering digital dust while the team wonders why adoption never took off. I’ve lived this cycle more than once, and its taught me that the real challenge isn’t technical.

It’s structural.

The core problem? Most teams blur the line between two fundamentally different phases of product work: the laboratory and the factory. If you want your products to actually get used, you need to rethink how you move ideas from one phase to the other.

The Lab: Where Ideas Are Born

Think of the lab as your team’s creative playground.

Here, you (or your “skunkworks” teammate) are free to experiment, prototype, and chase down wild ideas. There’s a lot of “what if we tried XYZ?” energy, and that’s a good thing. In the lab, failure is cheap and expected. You want to move fast, break things, and see what sticks.

In my experience, this is where data-savvy PMs, engineers, and performance marketers shine. They’re great at spinning up proof of concepts, conducting user interviews, and sketching out new ways to look at web data or customer problems.

The problem? Lab work is rarely production-ready. Prototypes aren’t built for scale, security, or long-term maintenance. And when the lab is left in charge of the whole process, you end up with a graveyard of half-finished tools and “cool” features no one uses.

The Factory: Where Ideas Become Reality

The factory is where things get real.

Here, you take those promising lab experiments and turn them into robust, reliable, and scalable products. This is where you make hard decisions about what gets built, what gets cut, and what the MVP really needs. The factory is all about process, documentation, and follow-through. It’s less glamorous, but it’s what separates a prototype from a product people actually depend on.

Engineering teams thrive in the factory when they have clear requirements, defined success metrics, and a single decision-maker. Ambiguity kills team momentum. If you hand engineers a menu of “maybe A, B, or C,” pathways you’ll get nothing but confusion and delays.

The factory needs clarity.

Where Product Initiatives Go Wrong

Most product initiatives fail because they don’t respect the boundary between the laboratory and the factory. Either…

  • The lab runs wild: endless prototyping, no clear path to production, and users get confused by ever-changing features.
  • The factory takes over too soon: rigid processes squash experimentation, and you end up shipping something “safe” but irrelevant.

I’ve seen both.

At Uber, we once built a beautiful prototype for campaign analytics that marketers loved in the lab. But I’ve seen the same pattern play out with customer-facing features and data science models: great ideas that never make it across the bridge to scalable, reliable delivery. Sometimes, the data pipelines weren’t ready, or the UI couldn’t handle real-world usage. The project would stall for months while we tried to retrofit “factory” processes onto a “lab” experiment.

How to Make the Lab vs Factory Model Work

Here’s what worked for us - and what I now recommend to teams building any kind of product:

  • Keep the lab and factory distinct: Let your “innovation” PMs and teams run wild in the laboratory to prototype, test, and validate ideas with real users. But set a clear boundary: once an idea is validated (ex: 10 users say they’d use this weekly), it moves to the factory.
  • Formalize the handoff with a checklist: What’s been validated? What are the must-haves? What’s still unknown? The factory (usually you, if you’re the bridge) takes over, writes requirements, makes judgment calls, and owns the execution with engineering.
  • Protect engineers from ambiguity: The factory phase needs a single decision-maker. No more “we could do A, B, or C” - pick one, explain why, understand the trade-offs, and move forward.
  • Schedule regular reviews: Every couple of weeks, review what’s in the lab, what’s moving to the factory, and what’s stuck. This keeps both sides honest and helps spot bottlenecks early.
  • Treat users like real customers: Just because they’re a captive audience doesn’t mean they’ll use your product. Bring them into the lab, gather feedback, and keep iterating even after launch.

Wrapping Up

Product development comes with its own headaches: legacy systems, limited resources, and users who already have a “good enough” workaround. The lab vs factory model isn’t just a process hack - it’s a mindset shift that helps you balance creativity and execution, no matter what you’re building.

Most products fail because teams inadvertently blur the line between experimentation and delivery. Build a clear bridge from lab to factory, respect what each phase does best, and you’ll finally ship tools that actually get used.

It took me a few scars to learn this, but once you get the balance right, the difference is night and day.