I was looking at the remote control for my old TV yesterday. It has 54 buttons. I have only ever used a handful of them.

The others are just clutter, waiting to be pressed by accident while I am searching for the volume. It is a classic case of feature creep: building things because you can, not because anyone actually needs them.

Most corporate learning functions are currently building that 54-button remote.

We have all been there. We spend six weeks polishing a new feature course. We obsess over the voiceover, the branching logic, and the quiz. We launch it, and then we move on to the next project. We treat the course like a destination.

But for the person trying to use your software, that course is just a brief, potentially annoying stop on their way to actually getting their work done. If the documentation is out of sync with the video, or the login screen is a nightmare, or there is no way to ask a question three days later, the learning experience has failed. This remains true even if the video was a masterpiece.

Luke O’Mahoney talks a lot about Product Led PX (People Experience). It is a brilliant shift: treating the entire employee lifecycle with the same obsession that a SaaS company treats its user journey.

In our world, we need to be talking about Product Led LX.

Product Managers do not just care about the sign-up button: they care about the churn six months later. They look at the end-to-end journey. Product Led LX means accepting that learning happens in the gaps. It happens in the Slack threads, the help articles, the mistakes made in production, and the renewal conversations.

If we only own the course, we only own about 10% of the actual experience. To be effective, we have to own the whole circuit, not just the lightbulb. Moving to this mindset requires three specific shifts in how we design for the morning after.

First, we have to map the Total Experience (TX). Before you open an authoring tool, map the user journey through their week. Where do they get stuck? Where do they go for help first? If you understand the Total Experience, you realise that a 30-second Slack bot might be a better learning product than a 30-minute module.

Next, we need a Service Blueprint. Software teams use these to see what happens behind the scenes to support a user. We should do the same. What happens after they finish the training? Is their manager equipped with a coaching cheat sheet to help them apply it? Does the UI change to guide them? If the afterlife of your content is not planned, the knowledge will evaporate before Friday.

Finally, we have to close the loop with Feature Requests. Treat your users like a user base. If they are failing a specific hands-on task in your product, that is a bug report for your LX. Instead of saying they did not pay attention, ask how the product failed to guide them. Then, fix the experience by updating the help tip or the walkthrough.

A great product succeeds as a seamless solution to a problem, rather than just a list of features. Stop thinking about the individual learning component. We should be architecting the end-to-end journey from being stuck to having it under control.

Forget the reactive order-taking loop. It is time to start architecting the growth engine.

Keep Reading