Become the Product

Paul Graham’s most quoted advice to founders is probably “do things that don’t scale.” I read that essay years ago and recognized something we were already doing by instinct. What I didn’t expect is that, eleven years and three products later, it would still be the only product-discovery method we use.

Except we practice a more extreme version of it. We don’t just do unscalable things. Before we build anything, one of us becomes the product.

It has happened four times now. Every product, every market.

Doutore: I was the patient

In 2014, stress from a failing startup broke one of my teeth, and I ended up in my dentist’s chair while her terrible practice software failed her in the background. I asked what she paid, mocked up a replacement that night, and validated it over lunch the next day. One month later, the first version of Doutore was live in her clinic - our first paying customer. (The full story: The Dentist Who Started Two Companies.)

I didn’t interview a market segment. I was in the chair. The product question wasn’t hypothetical - it was “what does the person currently looking into my mouth actually need?”

SantoDoc: I was the intern

Eleven years later, we could see that document signing in Brazilian healthcare was broken - the standard process demands a digital certificate most patients don’t have. Instead of speccing a solution, I asked that same dentist, customer #1, to let me work her reception desk as an unpaid intern.

I handled the paperwork myself: contract by contract, patient by patient. I felt where the process stalls, what patients don’t understand, what a secretary improvises when the waiting room is filling up. SantoDoc - legally valid e-signatures without the certificate - came out of that chair, built for her first.

Dr. Assistente: I was the AI

When OpenAI released Whisper, I knew typing was the single biggest burden in our doctors’ lives, and that we finally had a shot at eliminating it. Whisper took several minutes per audio on my laptop - too slow for a product, fast enough for an experiment.

So before the product existed, I hand-picked a few doctors from our base and made them an offer: record your consultations, and I’ll return a well-structured record within 24 hours. Behind the curtain there was no product. There was me - running transcriptions on my own machine, structuring the records by hand, delivering them one by one.

The experiment famously failed - doctors didn’t want a higher-quality record tomorrow; they wanted a good record before the patient left the room - and that failure taught us that speed, not quality, was the actual product. We would never have learned that from a focus group. I learned it by being the slowest version of the product, personally disappointing real doctors.

The vet hospitals: I was the staff

When a university’s veterinary hospital became our path into a new market, I flew to a city I’d never set foot in and spent seven days inside the hospital - 7:30am to 9:30pm, every day. We discovered within hours that our product, decent for solo vets, was useless for hospitals: a hospital is not a bigger clinic, it’s a relay race between shifts and teams. We rebuilt the product live that week - me shipping quick fixes from the hospital floor, Gustavo going deep from home.

Why this works (and why almost nobody does it)

Every standard discovery tool is a proxy. Surveys are proxies. Dashboards are proxies. Personas are proxies that lie politely and in great detail. Proxies are popular because they scale - you can survey ten thousand people.

But here’s the thing about understanding: it doesn’t need to scale. It needs to be true. One founder sitting at one reception desk for one week produces more product truth than a thousand survey responses, because the reception desk can’t lie to you. You feel the stall points in your own hands.

The reason almost nobody does this isn’t that it’s hard to think of. It’s that it’s embarrassing and slow and doesn’t look like leadership. A founder at a front desk looks like a demotion. A founder manually transcribing audio at midnight looks like a failure to automate. A founder spending fourteen-hour days in a vet hospital in a small city looks like someone who can’t delegate.

It’s none of those things. It’s the cheapest, fastest, most reliable instrument ever invented for finding out what to build. The software scales just fine afterward - that part was never the problem.

The org chart says founder. The job has always been: patient, intern, AI, staff. Whatever the product needs me to be, until I understand it.