The Year I Treated Experience Like the Asset

I spent the better part of a decade treating experience as an asset, the main thing that made my product decisions reliable. At teams building tools for children’s ministry volunteers and global Bible readers, that experience let me spot the same failure patterns in new interfaces or content workflows before most people finished their first user interview. It felt like an edge that only grew stronger with time.

Then agents started handling the repeatable parts of discovery, spec writing, and initial testing. The same track record that once accelerated decisions began to close off questions I no longer felt I had time to test. The cost showed up in two missed releases where we shipped patterns that worked for veteran users but collapsed for the next generation of volunteers.

This is the foundational misread that causes product teams to treat experience as an asset that only appreciates, even once automation absorbs the routine work. Charlie Munger’s circle of competence describes the boundary where real skill exists and outside which confident guesses turn expensive. When experience stops being updated by direct contact with new conditions, the circle contracts even while the person inside it feels more certain.

The Moment Experience as an Asset Stopped Helping

The shift showed up in a review of a new volunteer onboarding flow for curriculum resources. I had run similar projects three times before and knew the drop-off points after the first print-and-prep step. I signed off on the revised screens based on that history.

Three weeks later the completion data showed the new cohort abandoning at a different step entirely—one that only appeared once agents generated the first-round content variations. My prior runs had never included that variable, so the pattern I trusted no longer matched the actual system.

The circle had narrowed without me noticing because the inputs I used to gather myself were now being produced faster by models I reviewed only at the end. The seniority that once compressed review time now compressed the questions I bothered to ask.

Where Gen Z Chutzpah Actually Compounds Faster

A newer teammate on the same project kept pushing for live observation of volunteers using the agent-generated lesson drafts in real time. She had none of the historical comparisons I carried, so every session produced fresh variables instead of confirmation of old ones.

Her questions surfaced a constraint around token limits that directly affected how small churches could customize material without extra cost. I would have caught the same issue eventually through the slower path of post-launch metrics. She reached it in two moderated sessions because she treated every output as new ground rather than another instance of a known category.

The difference was not raw intelligence. It was that her shorter track record left more room for direct observation before the circle of what she considered settled tightened around her.

Keeping Experience as an Asset Without Faking Beginner Status

The practical problem is not whether experience as an asset still matters. It is how to keep the boundary moving outward when agents now own the first pass on tasks that once forced repeated contact with users. The answer is not to pretend the years never happened or to manufacture beginner exercises that everyone sees through.

Instead the work becomes deliberate insertion of new variables into the loops that used to run on autopilot. That means choosing projects where the agent output cannot be reviewed without fresh fieldwork, then protecting the calendar space for that fieldwork even when the review itself could be done in a fraction of the time.

It also means tracking which decisions still rely on patterns formed before agents arrived and forcing at least one new data source into each of those decisions. The goal is not humility theater. It is keeping the competence boundary from freezing in place while the surrounding environment keeps changing.

Your Turn: Apply This Today

  • Pick one recurring product decision you currently close from memory and add one live observation session with a user type that did not exist when you first learned the pattern.
  • Review the last three specs you approved that relied on agent-generated content and list the variables you did not test because prior experience said they were stable.
  • Block two hours next week for fieldwork that cannot be summarized by an agent and treat that block as non-negotiable the same way you treat revenue reviews.
  • Ask the newest person on your team to name one assumption in the current roadmap that would change if their shorter history were the only data source, then run the test they describe.
  • Document which decisions in your area still carry the highest cost if the circle has already narrowed, and assign the next one to someone whose track record is shorter than yours.
  • Set a recurring calendar reminder every six weeks to re-test one previously stable metric against a fresh cohort rather than assuming the old baseline still holds.

The pattern shows up again in the way teams handled early agent routing for content specs and in the career questions that surface once the old accumulation model no longer matches how competence actually grows.

I consult with product leaders and ministry technology teams on preserving experimentation capacity after automation arrives, updating decision patterns that predate agents, and designing feedback loops that keep competence boundaries from contracting. Let’s talk.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.