The PM Job That Turned Into Raising the Next Request

Most product teams assume the agent request is the difficult step. They negotiate scope, define inputs, and celebrate when the first output lands on time. The real constraint appears only after the agent meets the brief without complaint: the original request no longer represents the outcome the team actually needs.

Teresa Torres built continuous discovery on the premise that teams must keep testing their assumptions against real users even after a solution ships. When agents absorb the execution layer, that same discipline shifts from validating features to repeatedly raising the target outcome itself. The scarce skill becomes the ability to notice that the delivered result is still too modest and to press for a harder one.

This is the foundational misread that causes product teams to treat agent workflows as simple delegation exercises. They hand off a task, measure completion speed, and stop. Torres’s practice shows why that pattern collapses once the agent stops being the bottleneck.

The first time the agent finished the roster update early

A children’s ministry platform team had built a volunteer scheduling agent for mid-size churches. The initial request was straightforward: pull availability from the existing database, assign names to slots, and flag conflicts. The agent returned a complete roster in four minutes instead of the two hours a volunteer coordinator usually spent.

The first reaction inside the team was relief. Metrics looked strong. Completion rate jumped. Yet the coordinator who received the output still spent the next morning making phone calls because the assignments ignored which volunteers had led the same age group before. The agent had solved the stated problem. It had not touched the actual retention problem the church cared about.

The gap was not in the agent’s code. It was in the outcome the team had named. They had asked for a filled schedule. The church needed a schedule that kept volunteers returning quarter after quarter. Torres’s continuous discovery loop forces exactly this distinction before the next cycle begins.

What happened when the next request stayed small

The team shipped the agent and moved on. Two weeks later the same coordinator returned with a follow-up ask: add a text reminder two days before each shift. The request stayed inside the original frame. It treated the roster as a one-time output rather than a recurring relationship.

Because the agent could now generate reminders without new human input, the team could have paused to test whether the deeper need had changed. Instead they implemented the reminder and measured open rates. Open rates looked fine. Volunteer return rates did not move.

The pattern repeated across other workflows. Each new request arrived already scoped to what the agent could execute quickly. Continuous discovery, applied after the agent existed, would have required the team to re-interview the coordinator about what success looked like once execution cost dropped to near zero. No one ran that interview.

The weekly practice that forced the ambition upward

The team instituted a standing thirty-minute review every Friday. One person owned the current agent workflow. Their only job in the meeting was to state the original outcome in one sentence, then say what outcome would matter if the agent handled every mechanical step without oversight. The rule was simple: the new outcome had to be harder to measure and further from the current data.

The first time they applied it to the roster agent, the coordinator said the real goal was not filled slots but “volunteers who choose this church over three other serving options each quarter.” That single sentence changed the next three agent iterations. The team stopped adding reminder features and started surfacing historical serving patterns so coordinators could see who had quietly stopped returning.

The practice worked because it made the elevation of ambition a repeatable step rather than an occasional insight. Torres’s method requires ongoing contact with the user; here the user was the ministry leader whose definition of success had to keep expanding as the agent’s capacity grew.

Your Turn: Apply This Today

• Pick the person who owns the next agent workflow and book a 25-minute call for this week; open by reading their original request out loud and ask what outcome would be worth measuring if the agent removed all current manual steps.
• Write the new outcome as a single sentence that cannot be answered by the data the agent already produces, then share it back to them for confirmation before the call ends.
• Identify the one metric that would prove the harder outcome is moving and add it to the agent’s weekly report even if the current agent cannot influence it yet.
• Run the same 25-minute conversation with a second workflow owner inside the same product area before the end of next week.
• Document the two new outcomes in the same place the original requests live so the next person who opens the ticket sees the raised bar immediately.
• Schedule the same review for four weeks from now and treat it as recurring rather than a one-time exercise.

This pattern shows up again in The PM Who Inherited the Agent Schedule and The PM Role That Still Needs Human Judgment After Agents Ship.

I consult with product leaders on agent workflow design, continuous discovery after execution is automated, and raising outcome ambition inside mission-driven teams. Let’s talk.