Conduit started as an AI-driven scheduling product for QSR and retail. The thesis was straightforward: shift scheduling consumes 5–10 hours of managers' time per week, the resulting schedules don't match what workers actually want, and the cost shows up as turnover. A product that produces better schedules in less time should sell itself.
The product worked. We hit 96 NPS in pilot deployments, drove a 95% reduction in time-to-schedule (from 5–10 hours to under 20 minutes), and achieved a 35% reduction in turnover among design partners. Users loved it. The unit economics didn't.
Our required ACV was about twice what the next-cheapest scheduling tool charged. In a market with thin margins and high CAC, that gap was structural. We tried penetration pricing, larger-customer outreach, and multi-product positioning. None closed the economic gap. The product had real PMF on the product side and a real ceiling on the GTM side.
What the customer conversations surfaced
During the GTM exploration, I ran roughly 150 customer interviews with franchise operators, store managers, and frontline workers. They surfaced something the original thesis hadn't accounted for. Workers in QSR and retail often work multiple jobs. Operators in the same neighborhood often have complementary shift gaps — one needs morning coverage, another afternoon. Neither could close the gap by hiring more aggressively without incurring costs they couldn't justify. And the workers, asked what they wanted from a scheduling tool, kept describing a state in which they could move fluidly between employers based on who needed help that day.
The structural insight: workers wanted access to more total hours across multiple employers; operators wanted access to a larger labor pool than their own hiring could produce; and the constraint was that no neutral third party existed to ensure fairness across employer boundaries. This wasn't a feature request. It was a different product.
The pivot
We pivoted Conduit from a single-employer scheduling tool to a cross-business labor-sharing platform. Workers kept their relationship with a primary employer but became visible to neighboring operators when that employer couldn't fill their preferred hours. Operators got access to a larger pool of available labor without expanding their own headcount. The platform handled the fairness logic — who got priority access to gaps, how hours were allocated across employers, how worker preferences were respected.
The cross-business labor-sharing model became the key differentiator from incumbent scheduling tools. The insight from the research changed not just the feature set but the underlying economic model of the product — and it was the basis for the subsequent acquisition by a strategic partner, where the combined scheduling-plus-hiring product was meaningfully more compelling than either standalone.
What this case shows about how I work
The original thesis was correct on its own terms. The product worked, the metrics validated it, satisfaction was high. The pivot wasn't driven by failure — it was driven by user research that revealed a structural insight pointing to an entirely different product. The senior skill on display isn't "I listened to customers and adjusted features." It's recognizing, during a routine GTM exploration of an apparently successful product, that the customer was describing a different product than the one I'd built — and being willing to redirect the company on that insight rather than defend the original thesis.