Sesame: Proving Market Demand Before Building the Infrastructure

Why Sesame

I left Taxfix for Sesame. Both were in Berlin. I joined for the team more than anything else -- the calibre of people across product, design, and engineering was exceptional. I reported to Natalia Volgina, Head of Design, who reported to CPO Gerard Murphy. Sesame was remote-first with product, design, and engineering based in Berlin and the commercial team in New York.

I was initially assigned to the growth team -- conversion optimisation and market expansion. Sesame was concentrated in the Northeast US and needed to prove it could scale. Later I also picked up work on the commercial team, focused on the provider side -- onboarding more healthcare practitioners to increase supply. This was peak Covid, and telehealth demand was enormous.

The growth team was a single squad: two front-end engineers, one back-end engineer, one PM, and myself, with occasional support from engineers on other teams. Gerard and the leadership team set strategy through OKRs -- the CPO presented vision and objectives to the product org, then each squad broke the vision down into what we believed were the right targets. We'd present our plans back to the group and get challenged in sparring sessions before committing to a direction. My role was execution, not strategy setting -- but the process meant I understood the strategic context for everything I was building.

I joined for the team more than anything else. The calibre of people, the working relationship between product, design, and engineering, the respect for quality -- it was my favourite job.

The Growth Problem

Sesame had product-market fit but needed to prove it could improve core metrics and expand geographically. The company was in a bridge funding round, and Google Ventures was interested -- but their investment was conditional on demonstrable metric uplift: signup conversions, retention, time to value. They also wanted to see that Sesame could actually expand beyond the Northeast.

The user journey had too many steps. A patient would land with one of two mindsets: 'I know what I need' (a specific specialty or practitioner type) or 'I'm feeling this and I don't know who can help.' We designed two routes to accommodate both -- a specialty path for patients who'd already researched, and a symptom path that translated what patients felt into practitioner recommendations.

Across both routes, we applied Hick's law systematically. When users face too many options, decision time increases dramatically and drop-off follows. We didn't hide options -- we distributed them across detail pages so each decision point had fewer choices. We also reduced the end-to-end flow from roughly seven steps (land, search, find match, select practitioner, find time, checkout, confirm) to a tighter sequence. Later, we added pre-fill for returning users -- if you'd previously checked out with the same details, we populated your information automatically with a consent checkbox, similar to how a medical office keeps your details on file.

How We Measured Everything

We ran A/B tests religiously. The stack was Mixpanel for product analytics, Hotjar for session recordings and heatmaps, UserZoom for moderated testing sessions, and SEMrush for SEO. We were constantly refining the site, validating hypotheses, and measuring outcomes against the metrics GV cared about.

The real accelerator was the design-to-experiment pipeline we built with engineering. Design components were built as React Storybook components, then connected to Contentful so that content, card conditions, tags, button labels, and routing were all CMS-controlled. Anyone -- product, marketing, operations -- could modify the site and launch experiments with no additional front-end work required.

This changed how we designed. For any given problem, we'd typically explore three approaches, build out two of them, and deliberately reuse components between the two concepts. When it came time to A/B test, swapping between variants was a CMS configuration change, not an engineering ticket. It reduced our time to market significantly -- we were shipping and measuring at a pace that would have been impossible with a traditional design-to-dev handoff.

For any problem, we'd explore three approaches, build two, and reuse components between them. Swapping A/B variants was a CMS change, not an engineering ticket.

The Provider Side

On the commercial team, I ran discovery research with healthcare providers to understand what was limiting their willingness to join the platform and refer more patients. The pattern was clear across GPs, nurse practitioners, and specialists: the majority of appointments resulted in a lab or imaging order being placed -- bloods, X-rays, MRI, CT scans. This was a gap in our product and a gap in the market.

Sesame operates as a cash-payment platform, bypassing the insurance system entirely. That's the core value proposition for patients -- transparent pricing without insurance complexity. We designed a feature that let practitioners order labs directly through Sesame during telehealth appointments. The order was sent to the patient as a cash-pay transaction, keeping the entire workflow within Sesame's ecosystem. It strengthened the platform play -- practitioners had a reason to bring more of their workflow into Sesame, and patients could get labs ordered and paid for without touching their insurance.

Most appointments ended with a lab order. We built it into the telehealth flow so the entire transaction stayed within Sesame's cash-pay ecosystem.

The GrubHub Play

To prove geographic expansion, we took inspiration from GrubHub's early strategy. GrubHub listed restaurants before those restaurants had signed up -- you could order, and GrubHub would call the restaurant to place the order on your behalf. We did the same thing with healthcare practitioners.

We targeted Southern and Western states -- Houston was one example. We scraped healthcare practitioners in the specialties we supported, listed them on the Sesame site, and let patients book appointments. When someone booked, our operations team would call the practitioner, make the appointment for the time the patient selected, and act as the middleman.

We listed practitioners before they'd signed up. When a patient booked, our ops team called the practitioner and made the appointment on their behalf. It was GrubHub for healthcare.

This let us measure real demand in new markets without investing in operations infrastructure, technology integrations, or commercial relationships upfront. We could see exactly how many patients in Houston wanted to book a dermatologist before we'd spent a dollar building the supply side.

What Went Wrong

The unlisted provider model hit a wall. The back-and-forth between patient and practitioner took too long when mediated by an ops team. Patients would book, but by the time we'd confirmed with the practitioner, many had cancelled. The demand was real -- the fulfilment couldn't keep pace.

Telehealth had its own problems. During peak Covid, teleappointments were critical to Sesame's offering. But there were no charges for rescheduling, which meant practitioners couldn't onboard new patients because existing ones kept moving their appointments. It created a bottleneck for revenue growth. We explored ways to reduce rescheduling -- including concepts for appointment reminders across devices -- but the fundamental incentive problem remained unsolved during my time there.

The demand was real. The fulfilment couldn't keep pace. Patients cancelled because the back-and-forth with unlisted practitioners took too long.

Why It Worked Anyway

Internally, the expansion experiment was seen as a success despite the cancellation problem. We'd validated market demand before investing in any infrastructure. We hadn't committed to operations, technology, or commercial relationships -- and we had real data showing which markets wanted what specialties.

That data became a sales tool. When we approached unlisted practitioners to formally onboard them, we showed up with web traffic, booking attempts, and analytics from their listing. The conversation shifted from 'would you like to join our platform?' to 'here's the demand that already exists for your services.' It made provider acquisition dramatically easier.

The combination of metric uplift through A/B testing on the core product and the market expansion proof-of-concept convinced Google Ventures to invest. It was a team effort across product, design, engineering, and operations -- but the work we did on both growth and expansion was central to that outcome.

We showed up to practitioners with traffic data and booking attempts from their listing. The conversation shifted from 'would you like to join?' to 'here's the demand that already exists for you.'

What Carries Forward

The measurement discipline at Sesame shaped everything I did afterward. Running A/B tests religiously, building a component pipeline that made experimentation cheap, and validating demand before building infrastructure -- these became foundational to how I think about product work.

It's also where I met Bishesh. He was the lead front-end developer on the growth team, and his ability to implement designs to exact spec was unlike anything I'd experienced. That working relationship led directly to co-founding Strike Analytics together.

What made Sesame different from every other role was the culture. Gerard Murphy's leadership set the tone -- there was genuine respect for every person in the room regardless of their role or background. The trio between product, design, and engineering worked the way it's supposed to work. Everyone was exceptionally good at their job and cared about quality. We worked hard and we played hard as a team. I've been chasing that environment ever since.

The best professional partnerships come from shared standards, not shared ambitions. Bishesh and I co-founded Strike because we'd already proven we could build together.