Episode #37: Testing Product Demand with Fake Doors and Outcome Metrics with Pancrazio Auteri
Pancrazio Auteri explains how jobs to be done, fake-door tests, metric chains, and low-cost experiments help teams validate ideas and focus effort.
Teams can spend months building a feature before learning that customers do not need it. In Episode #37, Pancrazio Auteri explains how product teams can test intent earlier, connect changes to meaningful metrics, and reserve full implementation for ideas that show evidence.
What you'll learn
Why empowered teams need clarity and alignment, not micromanagement
How jobs to be done turns customer context into a guide for product decisions
How fake doors measure adoption intent and collect feedback in context
Why product metrics should connect user behavior to company outcomes
How themes, metrics, and experiments help product managers say no
Give teams context so they can move quickly
Auteri began in telecommunications engineering in Italy as internet technologies were moving beyond academia. He founded a startup with university friends in 1996 and later moved into product management after an acquisition by a California company. Across several product roles, one of his clearest lessons came from mistakes: hiring only for a skill, imposing his own solution, and monitoring small signs of progress too closely.
His alternative is to hire for attitude, trust people, and give them authority to make the many small decisions required each day. Trust alone is insufficient. Leaders must repeatedly clarify the goal, vision, and direction so decentralized choices remain aligned. They must also support people who take measured risks.
This approach improves speed because a manager no longer has to approve every decision. It can also improve the range of ideas because the leader is not the team's only source of solutions. Empowerment becomes practical when people understand both the outcome and the context in which they are operating.
Map the job before choosing the experiment
Auteri uses jobs to be done to separate a customer's underlying goal from the current product or technology. In his theater example, ticketing, donation management, accounting, and customer communication are tools within the broader work of operating a theater and serving its community. Understanding that work helps a team identify its major steps, the outcomes users want from each step, and the measures that indicate progress.
Deep context also improves everyday judgment. Auteri recalls a team whose product and customer success people understood theater and box-office operations so well that colleagues joked they could work for the customers. That knowledge made customer feedback easier to interpret because the team understood where a request fit in the user's full workflow.
Once the job is mapped into smaller steps, a team can ask a sharper question: what behavior or outcome should this experiment change? That is more useful than beginning with a feature idea and searching afterward for a reason to build it.
Use fake doors to test intent before implementation
A theater ticketing team discovered that finance staff were moving data between the product, CSV files, spreadsheets, and accounting tools. The team did not know which integrations mattered across more than 3,000 theater customers, and email surveys produced slow, limited responses. Instead of building each option, a product manager worked with a developer to add menu choices and buttons that were visible but not yet functional.
Analytics showed whether people saw and clicked each option. After a click, a short prompt asked what the person was trying to accomplish and offered choices such as QuickBooks, Xero, or a custom CSV. People selecting the custom option could then provide more detail. The team measured interest while collecting feedback at the moment the user was thinking about the task.
Auteri says this approach let the team test far more ideas within the same time budget and reject weak ones before paying the full implementation cost. He also warns that a fake door measures adoption intent, not sustained usage. If the real feature later launches, the interface needs a renewed visual cue so people who previously found a placeholder realize that the capability now works.
User outcomes and business outcomes are related but distinct. User measures should show success or progress within a job step. Business measures can include adoption, retention, conversion, or profit. Auteri recommends a metric chain that connects high-level company indicators to behaviors the product can influence. A product change acts on behavior, and the behavior contributes to the company result.
This chain helps a team decide whether to invest another sprint. If an early iteration moves the intended metric, the team may deepen the work. If a low-cost experiment produces no advantage, it can stop. That creates a discovery track for research and small experiments alongside an implementation track for ideas that have earned further investment.
The same logic supports a professional no. A request is a stronger candidate for rejection when it falls outside current themes, cannot connect to an important behavior, or cannot be framed as a manageable experiment despite substantial cost. Explaining that reasoning gives colleagues useful context instead of a bare refusal.
Listen to Episode #37
Listen for a detailed bridge between customer context, lightweight validation, and business measurement. Auteri's examples show how teams can learn before building while still giving successful ideas a path into sustained product investment.
Continue with the workflow pages
Use the ideas from this episode inside the selector, Playwright, and bug-reproduction pages that connect content to product intent.

