The PM Layer That Disappeared Once Engineers Owned the Regret

I still remember the look on our backend engineer’s face when the first support thread came through. A volunteer in Manila had tried to update the service schedule and the whole thing locked her out during the one hour she had between shifts. He had written the migration. He saw her name in the logs.

He stopped asking the product channel for clarification after that. Instead he started calling the users himself before the next deploy, then quietly rolling back anything that still felt shaky.

The PM role we had hired six months earlier never got replaced when she left.

Why the ‘regret that PM exists’ test fails in faith-tech contexts

Ministry tools rarely produce the clean failure signals that force engineers to feel the weight. A children’s ministry volunteer prints a lesson at 9 p.m. on Saturday, notices the activity page is missing a key instruction, and simply skips the activity. No ticket arrives. No usage metric drops. The engineer ships the next feature without ever learning the volunteer adapted around the gap.

This pattern repeats across curriculum platforms. The people who absorb the friction are part-time leaders who treat the software as one more unreliable volunteer rather than a product they can influence. Because the cost stays diffuse, the team concludes the feature set works and adds another layer of coordination instead of removing it.

The test therefore misleads. It assumes regret travels back through usage data or direct complaints. In practice the data stays clean while the real ministry outcome quietly degrades. Teams then reintroduce a product manager to interpret the silence, recreating the very distance the minimal structure was meant to close.

How discovery loops break when the person who feels the outcome never talks to the user

Continuous discovery requires the builder to hear the user describe the job in their own words before any wireframe appears. When an engineer never joins that conversation, the first version already encodes assumptions that only surface after launch. The product manager becomes the single point of translation, and every subsequent iteration passes through the same filter.

Over time the engineer learns to wait for requirements rather than seek the original need. The volunteer who once would have shown the broken flow now speaks to someone whose job is to summarize. The detail that would have changed the implementation gets lost in the handoff, and the next release solves a slightly different problem than the one the user described.

The loop does not fail because the product manager lacks skill. It fails because the person who will later defend or refactor the code never experiences the mismatch between intention and result. Torres’s framework collapses without that direct exposure, regardless of how many discovery meetings the middle layer schedules.

The handoff pattern that actually survived when we removed the middle layer

One small team kept a working rhythm after dropping the dedicated product role by requiring the engineer who would implement a change to attend the next two user conversations and own the decision to ship or rework. The rule applied even to small curriculum updates pulled from third-party sermon resource libraries. The engineer heard the volunteer explain why a certain age group needed the story repeated twice before the activity began.

That single change altered the definition of done. Instead of handing a spec to another person, the engineer carried the user’s phrasing into the implementation and later checked whether the printed page matched what the volunteer had described. When it did not, the same engineer adjusted the template without reopening a planning meeting.

The pattern held because the regret stayed attached to the code author. A missed detail on a children’s lesson now meant the engineer would field the follow-up email from the volunteer the next Sunday. Over months the team shipped fewer features but completed more of them in ways that actually reduced the volunteer’s Saturday-night scramble. The structure worked only while the engineer remained the owner of both the change and its consequences.

Your Turn: Apply This Today

• Pick one upcoming change to the print export flow in your curriculum tool and schedule a 25-minute call with a current children’s ministry volunteer this week; have the engineer who will code the change sit in and take notes without speaking for the first ten minutes.
• After the call, require that same engineer to write the acceptance criteria in the volunteer’s own words before any code is written and share the draft with the volunteer for one round of confirmation.
• Set a calendar reminder for seven days after the feature ships so the engineer must review the actual printed output with the same volunteer and record what still required workarounds.
• Remove any product-manager-only review step for changes under a certain scope and replace it with a required user conversation log that the engineer must attach to the pull request.
• Track the number of post-release adjustments that originate from the engineer rather than from support tickets for the next four releases and compare the count to the prior four.
• If the engineer reports that the user conversation changed the original plan, document the specific sentence from the volunteer that triggered the shift and keep the note visible in the next planning session.

The handoff patterns described here connect directly to the constraints visible in The Refactor That Finished in Two Days and Then Sat for a Week and the bottleneck analysis in Faster Code Does Not Move the Real Ministry Bottleneck.

I consult with product leaders in ministry tools on continuous discovery practices, regret ownership in engineering teams, and sustainable handoff patterns without added layers. Let’s talk.