In March 2025, Teresa Torres broke her ankle playing hockey. Three weeks on the couch, surgery, and painkillers later, the world’s leading voice in product discovery (the research phase where a product team confirms it is tackling a real problem before building anything, much like an architect surveys the ground before pouring foundations) had no idea that this forced stillness was about to turn her into a software creator.
A skeptic among the LinkedIn evangelists
Torres has taught the craft of the customer interview for nine years. Her book, Continuous Discovery Habits, has shaped how thousands of product teams work, around one simple idea: talk to users regularly instead of trusting your gut, a conviction she had already argued in an earlier piece on product proof. Stuck on her couch, she opened LinkedIn every day and kept running into posts praising artificial intelligence applied to user research: hundreds of hours of interviews synthesized in seconds, personas generated by language models (AI systems trained to produce text from an instruction). She resisted. She had, in her own words, a million reasons why AI shouldn’t change the work of listening to customers: nothing replaces the fine-grained understanding that comes from a real conversation. But the fear of being left behind crept in, and in Torres, fear usually turns into curiosity.
From prompt to product
Rather than look for a shortcut around interviews, as she saw so many practitioners doing around her, Torres picked a narrower problem: could she teach a model to judge the quality of an interview, the way she had been doing with her students for years? She turned her teaching rubric into a prompt (a plain-language instruction that steers a language model’s response). The results surprised her. Three weeks after her first experiment, she launched the Interview Coach, an MVP (minimum viable product, the simplest version of a product built to test an idea before investing further) built into her own training program. But a prompt is not a product. To turn that experiment into reliable software, she had to learn error handling, work inside a development environment, and version her code with Git. Vistaly, a partner company that builds product-mapping software, lent her its engineers.
The habit product discovery was missing: evals
One question nagged at her quickly: how could she know whether her AI assistant was giving good advice? She discovered a discipline borrowed from AI software engineering, popularized in particular by a course from Shreya Shankar and Hamel Husain: evals (short for evaluations), a feedback loop that consists of spotting what a model gets wrong, systematically measuring those errors, then fixing the system through small iterations, rather than judging its quality once and for all. Torres saw it as the missing piece of her discipline: just as a poorly run interview produces a useless synthesis, a poorly evaluated AI produces recommendations nobody can vouch for. This is precisely where the real transferable skill in this story sits: you don’t need to know how to code to apply the habit. You only need to describe what a good answer looks like before you trust the ones a system gives you.
Four tools, one year, and a bug that nearly ruined it
The pace picked up. In December 2025, with her collaborator Hope Gurion, she launched a Business Fundamentals Coach that grades her students’ homework in seconds. That same month, Anthropic published the results of an experiment in which 1,250 people were interviewed by its Claude model, results Torres judged shallow. On a dare, she prototyped her own AI interviewer, not to replace the human interview but to enrich thin feedback, like a half-hearted customer comment left on a form. In January, with Vistaly, she launched two formats she had herself popularized in her book: the interview snapshot (summarizing what one customer said before comparing several interviews against each other, so a single story doesn’t get diluted into an artificial average) and the opportunity solution tree (a diagram that links a product goal to the problems identified in customer interviews, then to the solution ideas worth testing), now generated automatically by AI from real interview transcripts. In March, she built an Outcome Coach that instantly tells a business outcome apart from a plain activity metric. Then, in April, a code fix introduced a bug in the logic that compares successive versions of an opportunity solution tree. The fix took two straight weeks of work, from the moment she woke up to the moment she went to sleep. “One of the hardest engineering problems I have ever tackled,” she would later say, she who had not called herself an engineer a year earlier.
What this year says about the profession
Torres’s story illustrates a shift larger than her own path: everywhere, traditional product trios (the classic pairing of product manager, designer, and tech lead) are being reshuffled as non-developers learn to run code in production, a dynamic already documented in our piece on the real leverage AI gives product managers. Some already call this shift the builder PM: someone who ships working pieces of software themselves, rather than only specifying them for someone else to build. But a single account should not be mistaken for general proof. What is established: with a rigorous evaluation discipline and a technical partner willing to help for free, an experienced professional can learn, within a few months, to ship software that genuinely runs in production, in front of real customers. What remains a promise: that anyone could reproduce this path just as easily. Torres herself benefited from a paying community willing to tolerate the rough edges of a young product, from partner engineers willing to help, and from a rare kind of availability: two full weeks devoted to a single bug. For an organization, letting non-engineers ship customer-facing AI features without the usual guardrails of code review and security review, the kind discussed in our piece on why shipping code faster won’t make an organization faster, is not a minor detail: it is a governance question to settle before the first incident, not after.
The concrete takeaway fits in one sentence, and it requires no code at all: before trusting what AI produces for your team, first write down, using the criteria you already use to judge a good interview or a good synthesis, what a correct answer looks like. Then test the system’s actual answers against that yardstick. That is the evals habit, transferable to any line of work about to hand a task to a language model. Torres closed her account with an image borrowed from a podcast she had listened to the week before: adventure, said the host Michael Easter, is “joyously wandering into the unknown.” She does not know where her own story leads. The reader only needs to know one thing: what their own tiny first step looks like.
Sources
- The Call to Adventure · Teresa Torres, Product Talk, August 5, 2026
