How Product Discovery changes with AI

Issue 283: Understanding the new uncertainty to de-risk

Product Discovery is the secret weapon I’ve used throughout my career. I’ve used it as the vehicle for changing the business—at One Medical when we launched new service lines, at Webflow when we needed to validate core product changes. It’s betting on your conviction with end users.

What is Product Discovery?

Product discovery is the process of figuring out what to build before you build it. It’s how teams de-risk the question mark between having a goal and deciding to build.

The key risks teams seek to understand:

• Desirability: Do customers actually want this?

• Viability: Does it work for the business?

• Feasibility: Can we build it?

• Usability: Can customers figure out how to use it?

The process operates in two interconnected loops:

Exploration of the Problem Space — the divergent phase, where you expand possibilities. You research to understand the problem space, ideate to generate potential solutions, and evaluate to narrow down which directions have merit. This loop is about opening up.

Validation of the Solution Space — the convergent phase, where you test assumptions. You prototype to make ideas tangible, test with real users to gather evidence, and learn to inform what’s next. This loop is about closing in onthe truth.

Both loops orbit around the central uncertainty: What should we build? The Goal informs where you’re headed. The Build is the outcome of successfully navigating that uncertainty.

Teresa Torres wrote the playbook on this with Continuous Discovery Habits—weaving customer input into daily product decisions rather than treating research as a phase.

---

How AI shifts the balance

In Jenny Wen’s talk at Hatch Conference in 2025, “Don’t Trust the Process,” she raises an important point: the processes we’ve established are rapidly becoming lagging indicators. Process is important, but it should work for you, not the other way around.

People worshipped the process artifacts, not the final result. We’re in a moment where the moment you document a process, it becomes irrelevant. I don’t believe it’ll be like this forever, but until software is completely rewritten with AI as a core capability, it’s going to be like this for a while.

So, where does Product Discovery change? Let’s revisit those four risks.

Feasibility: dramatically reduced. Building software used to be the hard part. A feature that would have taken a team two sprints can now be prototyped in an afternoon. I recently built the first version of Tapestry in a few hours—something that would have taken weeks before.

Viability: easier to test. When you can deploy a working prototype to production cheaply, you can get real market signals faster. You’re not guessing whether something could work as a business; you can find out.

Usability: faster iteration. You can generate multiple UI variations, test them, and refine quickly. The feedback loop tightens.

Desirability: unchanged. This is the one AI doesn’t solve. No amount of synthetic personas or simulated user research replaces the insight you get from watching a real person struggle with your product, or hearing them describe a problem you hadn’t considered. Desirability still requires humans talking to humans.

The implication: when three of four risks become cheaper to address, the remaining one—desirability—becomes the differentiator.

---

My evolving approach

Product Discovery is more important than ever, but my process, methods, and tools have changed drastically.

Sketching with code

I still start with pen and paper. That hasn’t changed. But the paper sketch isn’t what I put in front of people anymore. I sketch with code at various fidelities.

Here’s what I mean: a “low-fidelity” code sketch might be a simple HTML page with hardcoded data—enough to show the flow and get a reaction. A “high-fidelity” code sketch connects to real APIs and handles edge cases. The napkin sketch and paper prototypes are still how I think through problems, but code is how I communicate them.

At One Medical, this looked like building quick prototypes for the Labs experience during a Google Ventures design sprint. At Webflow, it was creating functional proofs-of-concept for layout features before committing engineering resources.

Prototyping in production

When I was a Design Technologist, the best prototype was one I could build off a branch of the functional app with a staging server. Now I prototype in production environments.

Take my project Tapestry. I built my hypothesis as a Replit app and deployed it to production. The first version was a traditional CRM with AI capabilities layered on top. I built it in a few hours—I would never have done this in my old approach because it would have taken too long.

Built a production app to actually use and get feedback

I invited a few people to use it. I got feedback in a production environment—real data, real usage patterns, plus their qualitative feedback. From those insights, I’m now pivoting Tapestry to be more decoupled from the CRUD app. The focus is shifting to a service and an MCP server so people can use their LLM of choice to manage their relationships.

Found the killer use case was integrating with Claude and ChatGPT

Important distinction: having something in production doesn’t mean you’re releasing the product or going to market. It can remain a closed beta. Production is just a better testing environment than staging. In the new world of Product Discover with AI, you can pivot dozens of times before you ever launch the product vs. after the fact.

Spending most of my time on desirability

Since AI compresses the time I spend on feasibility and viability, I now spend most of my time on desirability—talking to people, understanding their problems, and watching how they react to prototypes.

There are AI tools that claim to provide signals about virtual customer personas. I don’t use them for primary research. I spend my time with humans. The hard part was never synthesizing research findings; it was getting the right insights in the first place.

---

The new question

Product Discovery with applied AI is going to feel uncomfortable. It will feel like seeking a solution, looking for a problem, because the prototype and build is no longer a phase but a nearly-immediate loop.

In my talk for Maze’s Disco conference in 2022, I argued that Product Discovery is a method, a capability, a culture, and a navigation tool. That’s still true. But the emphasis shifts.

When AI can build almost anything quickly, the question changes from “Can we build this?” to “Should this exist?” And that’s a question only customer insight can answer.

As the ability to build anything becomes immediate and inexpensive, Product Discovery is more important than ever. Spend the majority of your time on understanding desirability.

---

Hyperlinks + notes

• Join our AI Design team!

• A Practical Guide for Product Teams by Tim Herbig

• Continuous Discovery Habits: Book Summary by Reshuka Jain

• This tiny pocket-friendly e-reader is packed with frustration and potential → What is this, an e-reader for ants?

• Moltbook → I am absolutely not sending my OpenClaw agent here, but this is fascinating

• Maddie Reese’s OpenClaw gets a body to create a Tamagotchi-like experience → The metaphor of a lobster is quite fitting as AIs seek their shell