How can PMs ensure knowledge actually influences future work?

In my experience, the reason lessons learned rarely influence anything is that they end their life as a document. What works for us is treating knowledge capture as a staged process rather than a single event at project closeout.
First, it's continuous and small, insights get logged as they happen, day to day, not reconstructed from memory months later.
Then there's a review step, essentially a committee that looks at what actually occurred, good or bad, and makes a judgment call: is this a one-off circumstance, or is it something worth standardizing? Most things don't survive that filter, and that's healthy.
What does survive gets piloted first (tried out on a real project or in a training session before anyone writes it into stone) because a lesson that looks brilliant in a retrospective often falls apart the moment it meets a different context.
Only after it proves itself does it become a written procedure, and then it has to be taught, not just published.
The last step is the one most organizations skip: monitoring the implementation to confirm people are actually doing it and that it's producing the effect we expected. Without that, you've simply moved the lesson from one document to another. It's slower than writing a lessons-learned report, but it's the difference between knowledge that exists and knowledge that changes behavior.

Lissette, I think the key is to design for knowledge to re-enter the work at the point where it can influence a decision, rather than expecting people to retrieve it from a repository.

A lesson about supplier selection, for example, becomes useful when the next supplier decision is being prepared.
But before reusing it, I would ask two questions: what evidence supports what we think we learned, and does it still apply in this context?

That matters because capturing experience does not automatically turn it into valid knowledge, and even good learning from the past can become a poor rule for a different situation.
Processes, communities of practice, and increasingly AI can help bring relevant knowledge back into the work, but contextual judgment remains essential.

Otherwise, organizations face two opposite risks: organizational amnesia when learning disappears, and organizational rigidity when yesterday's lessons become tomorrow's unquestioned rules.

For me, the real test is whether relevant learning reaches a future decision, survives contextual challenge, and actually changes what people decide or do.

In my experience, the reason lessons learned rarely influence anything is that they end their life as a document. What works for us is treating knowledge capture as a staged process rather than a single event at project closeout.
First, it's continuous and small, insights get logged as they happen, day to day, not reconstructed from memory months later.
Then there's a review step, essentially a committee that looks at what actually occurred, good or bad, and makes a judgment call: is this a one-off circumstance, or is it something worth standardizing? Most things don't survive that filter, and that's healthy.
What does survive gets piloted first (tried out on a real project or in a training session before anyone writes it into stone) because a lesson that looks brilliant in a retrospective often falls apart the moment it meets a different context.
Only after it proves itself does it become a written procedure, and then it has to be taught, not just published.
The last step is the one most organizations skip: monitoring the implementation to confirm people are actually doing it and that it's producing the effect we expected. Without that, you've simply moved the lesson from one document to another. It's slower than writing a lessons-learned report, but it's the difference between knowledge that exists and knowledge that changes behavior.

I get stuck on the word “ensure.” I’m not sure a PM can ensure that knowledge influences future work. We can make it more likely by putting relevant knowledge where future decisions are actually made - planning conversations, checklists, templates, decision criteria, standards, or tools - and by making it easy to find and apply, but even well-embedded knowledge can be ignored or become a checkbox.

I think the context check is important. Something that worked or failed in one project can give us useful information, but that doesn’t mean we should automatically apply the same lesson to every future project.
Also, the value is having that knowledge available when a similar decision comes up, and then deciding whether it still applies to the situation we have in front of us.

I see the 'traditional' lessons learned becoming a compliance exercise only. Tacit transfer during the project is more effective.