Blog

Product management salary surveys from late 2025 put AI-titled PM roles at a 47 percent premium over generalist PMs with identical years of experience and scope. That gap is the compensation split no playbook prepared product managers for. The surface reading points to straightforward supply and demand for scarce model-tuning skills. The actual pattern shows experienced product people exiting roles that force repeated exposure to messy constraints and moving into lanes where the title itself signals value before any shipped outcome does.

That split does not just change bank accounts. It changes the inputs that shape judgment. People who once spent weeks inside volunteer workflows or global translation queues now optimize inside environments where the feedback loop rewards speed of model iteration over durability of the underlying choice.

Teresa Torres built continuous discovery on the premise that product decisions stay honest only when teams maintain weekly contact with the people who will live with the output. The compensation split severs that contact for a growing group of practitioners before they ever develop the habit.

The Compensation Split When the Offer Letter Becomes the Product Decision

The first decision many PMs now face is whether to accept the AI-labeled role before they have run a single discovery loop inside the domain. Offer letters arrive with equity grants sized for model work, not for the slower work of understanding why a children’s ministry volunteer abandons a lesson plan at minute seven. Accepting the letter becomes the product decision, and every later choice inherits its assumptions.

Teams that hire on title rather than demonstrated discovery practice quickly discover the gap. The new hire ships prompt refinements that look elegant in demos yet fail when the actual user prints the output on a shared church copier with no color cartridge. The compensation signal masked the missing exposure to that constraint.

Continuous discovery requires repeated contact with the constraint before the compensation decision locks in. Without it, the builder optimizes for the environment that paid them to arrive, not the environment the product must serve.

Discovery Habits That Survive the Move Into the Premium Lane

Torres’s framework demands at least one customer conversation per week that can still kill the current roadmap. In the premium lane this habit collides with calendar pressure that treats model experimentation as the only visible output. The builders who keep the habit block the same two hours every week and protect them the way they once protected sprint planning.

One PM who moved from curriculum tools into an AI platform role kept the habit by running weekly calls with the exact volunteer segment he had served before. The calls surfaced that the new summarization feature created more work for users who needed to annotate the summary for doctrinal review. The model team initially dismissed the finding as edge-case; the PM’s prior constraint knowledge let him show the usage volume was not edge at all.

The habit only survives when the PM treats the conversation as non-negotiable output rather than optional research. Compensation that rewards model velocity makes this harder, not easier, because the visible metrics inside the new role rarely track whether the constraint was ever encountered.

Surviving the Compensation Split When the Market Owns Your Title

Once the title itself carries market value, ownership of outcomes becomes harder to claim and harder to lose. The organization assumes the AI PM will deliver model improvements; everything else can be delegated. The builder who wants durable ownership must explicitly contract for the discovery work that sits underneath the model work.

This shows up in roadmap reviews. A generalist PM once had to justify every shipped feature against user retention data. The AI-titled PM can point to token reduction numbers and stop there. Continuous discovery pushes the PM to keep the second slide that shows whether the token reduction changed any user behavior that actually mattered.

Ownership also requires refusing certain promotions. The next title increase often moves the person further from the constraint surface. Several builders have started declining the title bump and negotiating scope and compensation inside the current lane instead. The market still pays, but the builder stays inside the feedback loop that produced judgment in the first place.

Your Turn: Apply This Today

• Pull the offer letters or role descriptions from your last two compensation conversations and list the three constraints each role explicitly required you to encounter weekly.
• Map the last three product decisions you owned and mark which ones would still hold if your title and comp changed tomorrow.
• Block two recurring hours this week for a customer conversation that has the power to kill the current initiative; put it on the calendar before any model experimentation time.
• Write the second slide you would need in the next roadmap review that connects model output to one user behavior that matters outside the model.
• Identify the next title or scope increase being discussed for you and list the three constraints you would lose access to if you accepted it.
• Choose one prior role where you learned a durable constraint and schedule a 30-minute call this month with someone still working inside that constraint.

The same compensation pressure that rewards narrow model skill also makes the broader discovery habit appear optional. Two earlier posts on this blog examined how retention metrics in volunteer tools and enterprise PM patterns in global platforms both depend on repeated contact with constraints that never carry premium pay.

I consult with product leaders on compensation-driven scope decisions, continuous discovery under title pressure, and ownership structures that survive market valuation of roles. Let’s talk.

Adding AI features without visible trust logs does not accelerate ministry work. Trust logs, not the next feature, are what keep users accountable. It trains users to treat the system as unaccountable by default.

Church tech teams often assume that faster generation or smarter agents will increase adoption. The opposite pattern appears once volunteers encounter an output they cannot trace or reverse. The absence of a record signals that the tool operates outside the same standards of responsibility expected from every other part of their workflow.

This is the foundational misread that causes product teams to ship capabilities users later refuse to rely on. John Wesley’s three rules offer a clearer test: do no harm, do good, and stay in love with the people served. Applied to product decisions, the first rule requires that no change increase risk to the volunteer or the people they serve. The second demands that every addition demonstrably helps. The third insists the relationship itself remains intact after the feature is used.

Trust logs protect the volunteer handoff, not the model card

A children’s ministry volunteer opens an AI-generated lesson plan on a Thursday night. The content looks usable, yet she needs to know whether the scripture references were pulled from the same translation the church uses, whether prior edits from her team were overwritten, and whether any suggestion came from an outside source that might conflict with her pastor’s guidance. Without a visible log of sources and changes, she cannot decide in the seven minutes she has before the kids arrive.

The log is not a compliance document. It is the only artifact that lets her confirm the plan still belongs to her context. When the log is missing, the volunteer either spends extra time rewriting from scratch or accepts the output while carrying quiet uncertainty into the classroom. Both outcomes reduce completion rates, the metric that actually predicts whether she returns next week.

Teams that treat explainability as a later toggle miss this protection. The feature is not about satisfying an auditor. It is the mechanism that keeps the volunteer’s decision authority intact when the system proposes material she will deliver in person.

Shipping an agent before the trust logs exist creates silent breakage

An agent that schedules follow-up messages or assembles a small-group curriculum operates across multiple steps. When it acts without writing a record of what it changed and why, the next person who touches the same group inherits an altered state with no explanation. The original leader receives no notification of the change. The relationship between the tool and the person responsible for the group is broken at the point of the handoff.

Wesley’s first rule is violated here even though no one intended harm. The agent did not set out to undermine trust. It simply lacked the required record that would have let the original leader review or reclaim ownership. Over repeated cycles, leaders learn to double-check every automated action or to stop using the feature altogether. Either response raises the effective cost of the product.

The pattern repeats across volunteer coordination tools. An agent that books rooms or assigns curriculum without a reversible log produces the same outcome: the person who should remain in charge quietly steps back from relying on the system.

Rollback preserves the relationship only when the record is already public

A mistaken agent action needs reversal. The technical rollback is rarely the difficult part. The difficult part is restoring the volunteer’s confidence that the product will not repeat the error without their knowledge. When the original action left no visible trace, reversal itself becomes another opaque event. The volunteer receives a corrected state without ever seeing what went wrong or why it was fixed.

Wesley’s third rule surfaces here. Staying in love with the people served requires that the relationship survive the correction. A public, queryable record of the action and its reversal allows the volunteer to verify that the issue was addressed and will not recur without notice. Without that record, the correction feels like another autonomous change rather than a restoration of shared control.

Products that add rollback capability after launch discover the cost in support tickets and lost usage. The record must exist before the first agent action ships, because the first failure determines whether the relationship is recoverable.

Frameworks like the NIST AI Risk Management Framework exist because trust logs, not feature counts, are what make an AI system accountable.

Your Turn: Apply This Today

• Pick the single AI feature closest to release and list every data source, edit, and decision point it touches.
• Build a read-only log view that any logged-in user can open from the same screen where the output appears.
• Add one explicit “revert this step” control that writes the reversal to the same log and notifies the original owner.
• Write the three Wesley-rule questions into the acceptance criteria for the next sprint: does this change risk harm, does it produce clear good, and does it keep the volunteer in control.
• Run the feature with three actual volunteers this week and require each to explain what the log shows before they accept the output.
• Remove any agent capability that cannot meet the log requirement before the next release ships.

Two earlier posts on the same theme examined why volunteer completion rates matter more than generation volume and how product teams lose ground when they optimize for model performance instead of handoff clarity.

I consult with product leaders building AI tools for ministry contexts on audit trails, rollback processes, and volunteer handoff records. Let’s talk.

Quick answer: When you let an AI model’s approval define “finished,” you quietly outsource the judgment that should stay human. Write a testable definition of done — grounded in a real past failure — before opening any AI tool, then hold the model’s output to that human standard instead of letting its polish become the bar.

For nearly a year I let a model own my definition of finished. I treated the model’s green light as the real one for nearly a year. On three separate products I would write a short prompt, generate a spec or a flow, run it past the team once, and mark the ticket done when the output looked coherent. The first time it cost us was on the children’s ministry curriculum tool. We shipped a lesson-planning flow that the model had declared complete after three iterations. Two weeks later the volunteer completion rate dropped twelve points because the flow assumed every user could read a dense settings panel in under a minute. I had never sat with an actual volunteer to watch them stall on that panel; the model had simply never flagged it.

The second cost showed up in the analytics review. We had defined “finished” as “all core states rendered without error.” By that metric the feature passed. By the metric that actually moved retention it failed. I had outsourced the definition of finished to a system that had no stake in the outcome and no memory of the last five times we had made the same mistake.

How the First Prompt Loop Replaced My Own Taste Test

Industry guidance on a clear definition of done exists precisely because a definition of finished cannot be outsourced to a tool. Charlie Munger’s circle of competence is simple: know the perimeter of what you can judge reliably and stay inside it when the stakes are real. I had started treating the model as an extension of that circle rather than a tool that sits outside it. The first prompt would produce a v1 that looked plausible. Instead of running my own quick test against the actual user constraint I had observed before, I would ask the model to refine its own output. Each loop made the artifact smoother and moved me one step further from the raw edge where judgment is formed.

After four or five loops the artifact felt finished to me because it felt finished to the model. The competence boundary had quietly shifted outward to include whatever the model would sign off on. Munger warned that the biggest losses come from people who do not know where their circle ends. I was not violating the circle through overconfidence in my own knowledge; I was shrinking the circle by refusing to exercise the judgment that defines its edge.

The pattern repeated on the sermon resource platform. I let the model decide when a content-tagging system was ready for beta. It declared the taxonomy complete after we had covered the top thirty sermon topics. What it could not see was that children’s ministry volunteers tag by emotional tone and length, not topic. I had the data from earlier research but never re-checked it against the model’s structure. The model had no circle; it simply extended mine until I stopped noticing the boundary.

The Quiet Handoff of the Definition of Finished to the Model

Once the loop felt efficient, the final call moved without announcement. I stopped keeping a private note of the three things that still felt off before I opened the chat window. The model’s version became the baseline, and my remaining objections had to clear a higher bar than they used to. If the output addressed the original prompt, the objections sounded like nitpicks rather than signals that the prompt itself had missed the real constraint.

This handoff is easy to miss because nothing dramatic happens. The ticket still moves through the same stages. The only change is that the last human who could have said “this is not finished yet” now waits for the model to say it first. Munger’s framework makes the cost visible: you have stepped outside the circle and are using an instrument that cannot tell you when you have done so.

The cost appears in the data weeks later. Retention curves flatten where they should rise. Support tickets cluster around flows the model had called elegant. By then the decision to treat the model’s verdict as final has already been locked into the shipped artifact.

Rebuilding a Human Definition of Finished

The repair started with a simple rule on one small feature: I would write the acceptance criteria in a private note before the first prompt. The criteria had to be testable by a human in under ten minutes and had to reference an actual past failure. Only after the note existed would I open the model. The model could then generate options, but the note remained the standard. If the generated work met the note, it passed. If it did not, the work was not finished regardless of how polished it appeared.

The second step was to keep the note visible to the team. The model’s output became one input among others rather than the default definition of done. Over six weeks the practice spread to two other product areas. The change was not dramatic in velocity; it was dramatic in the quality of the objections that surfaced early.

Munger’s point is not that tools are dangerous. It is that competence is a perimeter you maintain by deliberate use, not a territory you expand by delegation. When the model handles volume, the remaining human work is precisely the work of knowing where the perimeter sits on each decision. That work does not scale with prompt speed; it shrinks when it is not exercised.

Your Turn: Apply This Today

• Pick one open ticket this week and write the three-sentence definition of finished in a note before you open any AI tool.
• Run the simplest possible human check against that definition within twenty-four hours of writing it, even if the model version is not ready.
• Share the note with one teammate and ask them to flag any criterion the current draft still misses.
• Refuse to mark the ticket ready until the note’s criteria are met, regardless of model polish.
• At the end of the week, list which criteria the model never surfaced on its own and keep that list for the next planning cycle.
• Repeat the same sequence on exactly one new decision the following week; do not expand the scope until the habit is automatic.

The same pattern shows up in how teams set completion criteria for AI-assisted discovery work and how they protect early-stage judgment when metrics are still thin. Both are worth reading next if this landed.

I consult with product leaders on AI-assisted decision boundaries, early-stage completion criteria, and protecting judgment when data is thin. Let’s talk.

Frequently Asked Questions