Blog

The printer spat out the third schedule while the denominational operations lead smoothed the pages flat on her kitchen table. Her eight-year-old leaned against the counter and asked why the church still used the old system that never matched what actually happened on Sunday. She pointed at one column and said the dates were already wrong.

That single mismatch sat at the center of her week. The new agent tools produced clean outputs, yet none of them carried forward the one correction that mattered most to her volunteers.

This scene shows the exact point where broad platforms lose. Teams keep adding features that look like the old system but faster. They miss the narrow, repeated regret that actually drives the switch.

Teresa Torres calls this continuous discovery. She argues that real product direction comes from repeated contact with the people who use the work, not from backlog grooming or roadmap votes. The operations lead already knew the gap. The tools simply never asked her about it.

The specific regret that made the switch inevitable

The old scheduling system failed every time a volunteer called in sick on Saturday night. The printed calendar showed the original name, the app showed the original name, and the email reminder still went to the original person. Someone had to stand at the door Sunday morning and fix it by hand.

That fix happened in every location the denominational lead oversaw. It took five to seven minutes each time, and it always fell to the same two or three people. The agent tools she tested could generate new schedules in seconds, yet none of them surfaced the previous correction as the starting point. They treated every week as clean.

The regret was not speed. It was continuity. Once she saw an agent that remembered the last manual override and asked whether it still applied, the old platform became unnecessary. Feature parity no longer mattered.

Why custom agents win when the pain is narrow and repeated

Broad platforms optimize for the average user across thousands of churches. That average hides the exact pattern this operations lead faced every weekend. A custom agent built for one workflow can store the correction history, the volunteer preferences, and the last-minute substitution rule in one place.

The agent does not need to do everything the old system did. It only needs to do the one task that previously required a human to intervene after the system finished. When the pain repeats at the same point in the week, the agent that owns that single loop pulls the rest of the workflow along with it.

Torres would recognize the pattern. The team stopped asking what the platform should include and started watching the moment the correction happened. That observation produced a narrow agent that replaced the contract.

How discovery changes once you own the workflow end-to-end

When the team controls the full sequence from schedule generation to Sunday morning printout, discovery becomes continuous by default. They see the eight-year-old question in real time. They hear the volunteer call on Saturday night. They measure whether the correction from last week carried forward.

Ownership also changes the metric. Instead of counting new features shipped, the team tracks how often the manual override still occurs. Each reduction in overrides becomes evidence that the agent now holds the institutional memory the old system never captured.

The operations lead no longer prints three versions. She prints one, checks the single highlighted change, and moves on. That shift only appeared after the team stopped trying to match the old platform and started tracking the regret that never left her kitchen table.

Your Turn: Apply This Today

• Pick one operational task your current tool forces a human to correct every single week and write down the exact correction that repeats.
• Shadow the person who makes that correction for two full cycles and note the moment they reach for the workaround.
• Build a one-page prompt that feeds the last correction back into the next run of the agent and test it with the same person.
• Measure only whether that specific override drops by half within four weeks; ignore every other feature.
• Remove the old platform’s export step for that single task and force the agent output to become the source of truth.
• Schedule a fifteen-minute weekly check-in with the same user for the next six weeks and log whether the regret has moved or simply changed shape.

The pattern shows up again in The Five-Year Roadmap the Agent Schedule Made Irrelevant and The Night the Voice Agent Forked Three Ministry Schedules at Once.

I consult with product leaders and ministry operations teams on continuous discovery loops, narrow agent design, and replacing broad platforms with workflow-specific tools. Let’s talk.

I was two paragraphs into updating my own five-year plan when the agent pinged me about a meeting pattern I’d kept for three years. It had already moved the block, updated three other calendars, and left a note explaining why the old rhythm no longer made sense for anyone involved.

I stared at the document on my screen—titles, timelines, the quiet assumption that progress still looked like the next role on the ladder—and felt the gap between what I’d written and what was actually happening in the work.

The plan kept treating time like something we still controlled. The agent had already started spending it differently.

The plan that assumed linear titles

Most career documents still list steps like associate product manager to product manager to senior product manager to director. Each step carries an implied increase in scope and a required demonstration of impact through visible deliverables. The assumption is that human managers will notice the progression and approve the next box on the chart.

In practice the agent handling schedule reconciliation already owns the data that determines whether a deliverable actually moved ministry outcomes. It logs every time a volunteer slot goes unfilled because the curriculum file arrived in the wrong format. That log sits outside any performance review cycle. The linear title plan has no column for the constraint the agent now owns.

Teams that treat the title sequence as the goal keep building artifacts that look good in the next planning meeting. They miss the moment the agent starts routing around a bottleneck that the next title was supposed to solve. The result is a roadmap that describes a career no one is actually living inside the current tooling.

How thread-forking exposed the actual constraint

The agent began forking its own follow-up threads after the third time the same volunteer cohort failed to receive updated materials. One thread handled the file conversion. Another thread checked the print queue status across three different church campuses. A third thread opened a lightweight ticket only when the conversion failed twice in a row. None of these threads required a human to request them.

What surfaced was not a skill gap in the product team but a handoff gap between the curriculum system and the volunteer management system. The five-year roadmap had listed “improve cross-team collaboration” as a senior-level competency. The agent made that competency visible as an automated rule set that already ran every Tuesday night. The constraint was never the absence of a title; it was the absence of a persistent loop that noticed repeated failure.

Cagan’s framework emphasizes that empowered teams define success by the problems they own rather than the features they ship. Thread-forking made the ownership question concrete. The agent did not wait for a promotion to start treating the repeated failure as its problem. The human roadmap still required a title change before anyone felt authorized to address it.

Writing the next role around what the agent already owns

The next useful move is not to invent a new title but to describe the boundary the agent now enforces. In one observed case a ministry product manager rewrote their own role description around the three constraints the agent had already made visible: file-format drift, campus print-queue latency, and volunteer confirmation lag. The description listed the agent as the first responder and the human as the owner of the rule changes when the agent logged a pattern.

This approach aligns with Cagan’s insistence that empowered teams receive problems, not solutions. The agent already receives the schedule data every day. The human role becomes the design of the feedback loop that turns agent logs into rule updates. The title on the org chart matters less than the documented agreement that the agent owns detection and the human owns intervention design.

Teams that make this shift stop measuring progress by the number of reports they review. They measure it by the number of agent-detected constraints that receive a permanent rule change within a week. The career path becomes a record of constraints owned rather than titles collected.

Your Turn: Apply This Today

• Pick the single agent thread that runs most often in your current workflow and export its last ten logs into a shared document before Friday.
• Write one sentence that names the constraint the agent surfaced most clearly in those logs, then send it to the two people whose work the constraint touches.
• Replace the next line item on your personal career doc with the name of the agent rule you will change if that constraint appears again in the next thirty days.
• Schedule a thirty-minute review with yourself next month where the only input is the agent’s log file rather than any title or promotion checklist.
• Identify one task you currently perform that the agent could fork tomorrow and document the exact condition under which you would let it own that task without review.
• Send the resulting three-sentence role description to your manager with the subject line “Constraint boundary update” and no additional context.

The pattern of rigid plans meeting live agent constraints shows up again in The Agent That Kept Running the Schedule While No One Was Watching and The Refactor That Finished in Two Days and Then Sat for a Week.

I consult with ministry product leaders on agent boundary design, constraint logging, and rewriting role definitions around owned problems rather than title sequences. Let’s talk.

Last night the ping came through at 11:17. The agent had booked a volunteer who’d already said no twice, then fired off the curriculum link to the entire wrong list. Three replies landed before I even opened my laptop.

I kept staring at the thread and wondering what I actually owned now. Not the clicks or the approvals—I’d already handed those off. Just the quiet gap between what the agent did and what should have happened.

That gap is where every PM ends up living once the first agent ships.

Where the regret actually showed up

In one children’s ministry tool rollout, the agent was given the narrow job of matching volunteer availability to upcoming events. It worked for the first two weeks. Then it started routing new volunteers to the same three sites because those sites had the cleanest data in the system. The other sites, with messier records, got zero new people. No one had written down what “fair distribution” actually meant when the agent had to choose.

The regret did not appear in the logs. It appeared three weeks later when two site leaders called the same week to say their teams were collapsing from lack of help. The PM had to stand in front of the directors and explain why the distribution looked the way it did. That conversation was the place the regret landed.

Schön would have called the moment the PM realized the data skew the “surprise.” The reflective move was not to add another approval step. It was to name, out loud and in the product spec, the exact outcome the team refused to accept even if the agent executed perfectly.

Shifting from gatekeeper to the person who names the failure mode

Most PMs still see their job as keeping bad things from shipping. After agents arrive, that posture becomes impossible to sustain. The agent will ship something unexpected because that is what agents do when they operate on live data. The PM’s new job is to name the failure mode that matters before the agent ever runs.

One team I watched tried to solve this by requiring every agent action to route through a human reviewer. Usage dropped to almost nothing within a month. Volunteers did not want to click through another screen. The PM eventually removed the gate and instead wrote a single sentence into the requirements: if the agent assigns a volunteer to a role they have never done before, the system must surface that fact to the site leader within twenty-four hours. That sentence became the owned regret point.

The shift is from “I approve this” to “If this goes wrong, here is the exact signal I will be measured against.” It is narrower and harder to hide behind.

Hiring senior ICs who already carry that regret

The strongest senior individual contributors I have seen in these environments are the ones who have already lived through an agent or automation decision that produced real damage. They do not need training on reflective practice. They already feel the weight when they look at a proposed handoff.

In interviews I now ask a single concrete question: tell me about a time an automated system you shipped created a problem you had not named in advance. The candidates who pause and then describe the exact person who had to clean it up are the ones who already carry the regret. The ones who pivot to process improvements or “lessons learned” slides usually do not.

Those ICs become the people who can sit with a product spec and point to the sentence that is still missing. They do not need permission to name the failure mode because they have already paid the cost of leaving it unnamed.

Your Turn: Apply This Today

• Pick the agent that has been running longest without daily human review and list the three outcomes the team has explicitly said it will not accept even if the agent executes its instructions perfectly.
• Write one sentence that names the single human who will be asked to explain the outcome if any of those three things happens, then add that sentence to the requirements doc this week.
• Schedule a thirty-minute meeting with the senior IC who has shipped the most agent work and ask them to mark the current handoff map with the exact place where regret would land if the agent ran for a full month unsupervised.
• Review the last three support tickets or ministry leader complaints that mentioned the agent and trace each one back to the missing failure-mode sentence rather than the missing approval step.
• Change the next hiring debrief to include the regret question above and score candidates on whether they describe the human cost or only the process fix.
• Identify the current handoff point in your largest agent flow that still carries no single name and attach one owner by the end of this sprint, even if the title on the org chart stays the same.

Two earlier posts on this blog walked through similar handoff problems: “The Agent That Kept Running the Schedule While No One Was Watching” and “The Three-Person Pod That Still Needed a Fourth Set of Eyes.”

I consult with product leaders and ministry technology teams on agent oversight, regret mapping, and handoff protocols. Let’s talk.