Product Discovery at the Speed of Code: Prototyping in the Age of AI

Ian Pilon spent two years running product design at Input Output, the company behind Cardano, then moved into the field as a forward-deployed engineer, embedded with customers. Today he builds VoiceClaw for owner-operators in trades and trucking, people who mostly run their business on pen and paper because pen and paper works. I sat down with him for an hour to ask what product discovery looks like once building stops being the hard part.

You can build now at the speed of clarity. Clarity is the new bottleneck.

Webinar video

Follow us on LinkedIn to get invited to our monthly webinars →

Follow our YouTube channel for past webinar recordings →

TL;DR

• The discovery loop is now daily. Watch the customer in the morning, prototype in the afternoon, go back the next day. Ian calls it compression of time, and it's the biggest change AI made to how he works.
• A prototype you're testing should stay rough on purpose. Ugly wireframes get more honest reactions, and fake data keeps you thinking about the idea instead of fighting edge cases.
• The field shows you what calls, tickets, and surveys never will: the dusty bottom drawer, the serial number too faint to scan, the mechanic lying under the trailer.
• Talk to people one on one before you ever run a group session. The thing nobody says in the room is usually the thing you need to know.
• AI finds patterns across hundreds of conversations. Judgment, knowing what people actually intend, still belongs to the person who was there.

The discovery loop is now daily

Ian's background is UX research and ethnography. For most of his career his job ended at the handoff: gather the field intelligence, pass it to an engineering team, wait. Now he builds with Claude himself. He goes on site, watches how the work actually gets done, builds something that afternoon, and brings it back the next morning.

The rate of learning is daily. I can learn today, go build something, go back the next day, learn, and I could never do that before. - Ian Pilon

His first lesson in the trades was humility. The people he builds for often met AI through a single ChatGPT session, and they don't feel behind. So he stopped pitching tools and started asking what was actually standing between them and the business they want to run.

Playbook move: put field visits and prototyping in the same hands, so the gap between what you saw and what you built is hours, not a sprint.

Keep the test prototype ugly, and keep it fake

I asked Ian how real a prototype should be, since Claude can now make it completely real. His answer had two parts. As a designer, an ugly wireframe is a tool: when something looks unfinished, people tell you what hurts instead of polishing your button colors. As a solo founder, he runs two systems for his client, a stable production system on site and a synthetic clone where he can try rough ideas without breaking anything the customer depends on.

Sometimes wireframing an ugly thing is done intentionally, because it allows you to invoke other intelligence out of the person using the thing. They don't take it too seriously. - Ian Pilon

We learned the same lesson the hard way on a code-based design sprint. We wanted the prototype running on real customer data, and we were up until 3am the night before user tests fighting data edge cases instead of thinking about the idea we were supposed to be testing. Real data belongs in the thing customers rely on, not the thing you're learning from.

Playbook move: separate what you're testing from what has to work. Learning prototypes get fake or synthetic data. Anything a customer depends on gets its own stable environment.

What the field shows that no transcript will

Ian works from Bob Moesta's approach: people first describe a problem at the surface, and you earn the real answer by building trust and asking why until they start enjoying talking about the friction. But the environment carries clues people can't put into words at all.

His favorite example is from early in his career, at an insurance company. Stakeholders were fighting over what went above the fold on a broker portal. Following Steve Blank's advice to get out of the building, the team visited broker offices and found the brochures sorted across about 25 drawers: the popular ones on top, the ones nobody used at the bottom, literally dusty. That drawer settled the information architecture, and the argument, because the answer came from the field instead of from the loudest opinion.

The stories from his current client, who leases more than 300 refrigerated trailers in Ontario, were even more concrete. Inspections ran on paper, so Ian built a throwaway inspection app and told the client to tell him everything that was wrong with it. On site he learned that:

• The AI vision scanner he'd planned for serial numbers couldn't work. The numbers were stamped with so little contrast that a person could barely read them.
• The mechanics climb under the trailers to read suspension serials, an attribute that wasn't on anyone's list.
• The client wanted rub rail height tracked, and only explained why (his customers ask for it) while they were walking the yard.

That's what these systems cannot get. You've got to go figure out what humans' intentions are. - Ian Pilon

Playbook move: take a disposable prototype to the site and watch it fail. The failures are the requirements. When stakeholders argue over priorities, go find the physical traces of what users actually do and bring those back.

One on one first, then the room

I'm about to start visiting AI-heavy product teams in their offices, and I asked Ian how he'd run those sessions. His tactics were specific:

• Never ask for more than 20 minutes the first time. Frame it as "I don't know anything, help me see if this is even a thing for you."
• Quietly block another 30 minutes on your own calendar, so you can offer to go a little over when it's going well.
• Make people co-creators. "I'm only talking to five people," and the early ones get first access.

He also warned about group sessions. At Input Output he interviewed each executive separately, because a room full of executives carries its own politics. I've seen the same pattern in my own interviews: in one on ones, people will tell you an executive's pet AI project is going nowhere, and nobody says it in the group. Ian's point was that the silence is itself the signal. Get at least five perspectives, and watch for the highest-paid person's opinion quietly setting the answer.

Playbook move: run discovery one on one before any group session, and compare at least five perspectives so the undercurrent has somewhere to show up.

AI finds the patterns. Judgment stays with the person in the room.

The title of Ian's book, Cultivating Clarity, gave me the line I keep repeating: clarity is the new bottleneck, because you can now build at the speed of clarity. So I asked what AI had changed in his thinking since he wrote it. He'd started out trying to use AI to speed up the whole process. His update:

The one thing I would update now that I know is you cannot get judgment out of the AI. - Ian Pilon

He tested it. He gave an AI five interview transcripts from the same company and asked it to read between the lines. It did some creative work, but it couldn't match someone who had been in every one of those rooms, heard every perspective, and caught the change in someone's voice when they weren't telling the whole story. Transcripts are words on a screen, and they're still valuable. They're just not the whole signal.

My own view comes from studying Buddhist philosophy: thought and feeling aren't separable. AI can imitate the steps of thinking, and I believe it will eventually handle almost anything practical. What it doesn't do is believe or care about anything, and judgment runs on exactly that. Here's the test I use. Ask it for a blog post on a generic topic and it does fine. Ask it to write the post about something you believe and most people don't, and it can't, because it doesn't believe it.

So this was never AI versus the field. It's a division of labor: the human goes under the truck, and AI finds the patterns across the hundreds of calls, tickets, and emails that nobody has time to read.

Playbook move: use AI to synthesize transcripts at scale, and give the final call on what matters to the person who was in the room.

Context is infrastructure, so own it

For the record, Ian and I are two of the most AI-pilled people I know. He runs his models locally, on hardware in his client's building, because the client wants the data to stay in Canada, and he calls the LLM for as small a step as possible inside a deterministic flow. I'm building an agent harness we plan to open source, where the agents' conversations with each other are visible to the human and where any folder or database can be handed to specific agents as context. We both came back to the same place: memory comes from context, and context you can't see or inspect isn't really yours.

Playbook move: treat customer context as infrastructure you own. Keep sensitive data where the customer wants it, and make sure you can see what your agents were given before you trust what they tell you.

Where Evermuse fits

Evermuse is the context layer for product teams: it ingests the calls, tickets, and emails you already have, captures the signals that matter (needs, friction, tension between teams), and finds the patterns you've been missing, with every answer traced back to the conversation it came from. It won't replace getting under the truck and seeing your customer's world for yourself. It will make sure the hundred conversations you didn't have time to reread still count.

It takes about 30 seconds to try. Install the Evermuse MCP from evermuse.com/mcp, then type "setup Evermuse" in Claude and it does the rest.

Want to go deeper?

• Ian's book, Cultivating Clarity: The Art of Discerning What Matters Using Contextual Intelligence, draws on interviews with nine experts including Jeff Jonas, Nick Shackleton-Jones, and Bob Moesta.
• See what Ian is building for trades and trucking at VoiceClaw.
• Put real customer signal behind your product agent with the Evermuse MCP.

About the speakers

Ian Pilon is the founder of VoiceClaw, a voice AI system that gives mid-market owner-operators, in trades and trucking, a second brain they can talk to. Before VoiceClaw he spent three years at Input Output (IOHK), the company behind the Cardano blockchain: two as Head of Product Design leading a 10-person team across its decentralized identity, wallet, and governance products, then as a forward-deployed engineer and Senior AI Solution Architect embedded directly with customers. He is the author of Cultivating Clarity: The Art of Discerning What Matters Using Contextual Intelligence. He also founded the AI Agents Waterloo community and co-founded ETHWaterloo, the world's largest Ethereum hackathon.

Eran Dror is the Co-Founder & CEO of Evermuse, an AI product intelligence company. He is also the Managing Partner of Remake Ventures, a venture studio focused on building human-centered startups. He has helped 40+ startups raise $300M+ by finding product-market fit, including his first exit SetJam, a smart TV startup that sold to Motorola in 2012. His master's thesis examined AI safety from a Buddhist perspective.

Want to learn more?

• Install the Evermuse MCP and put real customer signal behind your product agent
• Follow Evermuse on LinkedIn for monthly webinars
• Subscribe to our YouTube channel for past webinar recordings