The year my product instincts started expiring faster

OCTOBER 2026

This past year has been a crash course in how quickly good product judgment can go stale when the technology underneath the work is changing every few weeks.

Editorial collage about product design, showing states, constraints, recovery paths, and human judgment flowing into a clearer interface.

A few conversations from the past year have lodged themselves in my brain because they changed how I work.

“Don’t be late adopters.”

That was one of the first things a leader at my company said to the product team when LLMs started taking off.

He compared it to cloud migrations. Engineers had plenty of reasonable reasons to resist them. The old systems worked, the new ones were unfamiliar, and migration was painful. Eventually the shift happened anyway. The people who waited had a lot more catching up to do.

I understood the analogy at the time. I don’t think I understood how personally relevant it would become.

My facts were a month old

Later, he warned me against letting the engineers immediately around me become my only source of technical truth. They had their own work to ship and their own corners of the technology to keep up with. With capabilities changing daily, expecting any one person to stay current on all of it was unrealistic.

The point landed during a product conversation when I said something like, “I’m not sure this is a good fit for an LLM. Aren’t they bad at math?”

My information was about a month old. The latest models had already blown past the capability level I had in my head.

That was uncomfortable. PM judgment is built from accumulated knowledge: customer conversations, technical constraints, past decisions, things you have seen fail before. Suddenly some of those instincts had a much shorter shelf life.

The job was changing too

The third conversation came when I was struggling with how to lead product direction as the old boundaries between product and engineering got blurrier.

I had learned a version of PM where Product owned the problem and Engineering owned the implementation. That model had been useful to me, and I was uncomfortable pushing further into technical direction without pretending to be an engineer.

His response was basically: spend less time worrying about the professional identity crisis and more time looking at all the new ways we can meet the customer’s need.

That one has stayed with me most.

I still care about clear ownership. I’m just much less attached to the old shape of the job. This year has taught me to stay close enough to the technology that my own experience does not become the thing slowing me down.