It is trivially easy to create better products for your customers
Better products do not require more frameworks, but empathy in the problem space, imagination in the solution space, and trust in the organization that is to deliver them.
It is trivially easy to create better products for your customers.
It only requires 3 "for some" simple things: Empathy, Imagination, and Trust. Some companies have all 3. Others have 0.
Can one be "product-led" even if they deliver haystacks where customers have to find the needle themselves?
If one merely follows processes and recipes from a book instead of having a holistic approach to digital relevance and a commitment to creating the best user experience, one can easily end up there. The biggest obstacle to delivering "the needle on a silver platter" is rarely a lack of frameworks. It is political and organizational. Culture.
So if you "follow the recipe" from Cagan, Torres, and Herbig and still create haystacks, you may have misunderstood product-led. Or maybe not. Perhaps product-led in some places has become process over product and process over people?
For you do not arrive at the best result solely by using models and frameworks. You can user-test as much as you want on mediocre ideas and solutions driven by low imagination and low taste. And you will still be able to conclude that the test was a success and come home to document your OKRs and OSTs with progress and action plans for management.
The operation was successful, but the patient died.
This does not mean that frameworks are bad. On the contrary. Good simple frameworks with open parameters can help people ask better questions and think in more constructive ways. But frameworks cannot replace the three things: Empathy in the problem space. Imagination in the solution space. Trust in the operating space.

Empathy — Curiosity
Problem Space
Google already stated as number 1 in their *10 Things We Know to Be True*: "Focus on the user and all else will follow." It sounds almost trivial. But there is something quite fundamental in it.
Empathy is not just about interviewing users or having a research phase in your process. It is about care. Genuinely care. Not because someone has figured out that better UX leads to higher conversion and therefore empathy is a good business case. But because you actually care about whether the people using your product succeed.
If you truly care, you automatically start to lean in. You do not just accept the first problem you are presented with. You start to ask: Why do they have the problem? When do they have it? Where are they when it happens? What are they really trying to achieve? What happened just before? What happens afterwards? What other people, systems, or artifacts are involved? Is this even the right problem we are trying to solve?
That is why I still think that something as old as Design Thinking hits something fundamentally right by starting with Empathize. Not ideate. Not build. Not solution. Understand first.
Of course, it is yet another framework. But perhaps precisely an example of a framework that has survived so long because the foundation is hard to argue against. If you spend most of your energy truly understanding the problem, the solution itself often becomes significantly easier. And if you actually care, this becomes less something you do because the process says so. It becomes natural behavior.
Care creates curiosity. Curiosity creates better questions. Better questions create a better problem formulation. And a better problem formulation makes it far more likely that you find the needle, rather than just making the haystack a little easier to search through.
The opposite happens when motivation and care are lacking. Then we take the easier path of least resistance. We solve the visible problem. The feature request. The ticket. The data point that is right in front of us. We still get something done. We can still demonstrate progress. But we may never have investigated whether we even solved the problem that matters.
Empathy is therefore not just a phase in a workshop. It is the willingness to care enough to keep investigating until you understand the right problem.
And care alone is of course not enough either. One can care a lot and still be wrong. Empathy also requires curiosity and evidence. Otherwise, you risk projecting your own opinions onto the customer. But when those things come together, the problem space suddenly becomes something other than a checklist.
Imagination — Creativity
Solution Space
Once we have spent time understanding the context, the person, and the problem, the work changes character. Now comes the solution space. And this is where imagination comes in.
Imagination is a bit harder. Because it is not as easy to write a recipe for. It is difficult to standardize, hard to fit into a process, and hard to measure objectively. Some people just have an extremely strong divergent thinking. They see multiple directions, more possibilities, more connections. They do not necessarily accept the first plausible solution.
But imagination is not just about generating 100 ideas. You can be extremely divergent and still come up with 100 bad solutions.
For me, imagination is about at least three things: Divergence. Judgement. Refinement. The ability to envision alternatives, the ability to recognize which direction actually has quality, and the ability to keep massaging a solution when you can feel: It is not there yet.
That is one of the strangest things about design. When you have sat with solutions long enough, you can often feel whether it is there. And you can feel when it is not. Not necessarily explain why right away. But you know that there is still something that needs to be worked on. And when it suddenly falls into place, it can almost be a physical sensation.
It sounds fluffy, of course. And that is precisely the problem. It is very difficult to create a framework for. But that does not make it any less real. It is about judgement, experience, taste, pattern recognition, and imagination.
It also means that creativity is not just: "I would use this, therefore I think we should build it." That is not imagination. That is preference.
The solution space still needs to be tightly bound to what we learned in the problem space. Otherwise, we just get pretty ideas without relevance. Empathy tells us which problem is worth solving. Imagination determines how much better than the obvious answer we are able to make it.
And taste obviously plays a role as well. Taste is tricky. Because everyone can subjectively feel they have good taste. A bit like one can think they sing well without necessarily doing so. So we need to be careful not to make "I can feel it is there" a quality stamp in itself.
Therefore, you may not be able to measure imagination directly, but you can look for some signals: Is the solution actually different from the existing one? Does it fit extremely well into the specific context? Does it remove real complexity? Does it feel almost obvious afterwards? Does it still hold when other skilled people challenge it? Can others recognize the quality, even if the idea did not come from them?
That is probably closer to what imagination should be able to do. Not creativity for creativity's sake. But the ability to take a really strong problem understanding and arrive at a solution that feels like: There is the needle. Not yet another layer on top of the haystack.
Trust — Autonomy
Operating Space
And then comes Trust. Trust is the internal part. It is the operating space. The organizational conditions that determine whether empathy and imagination are even allowed to exist.
For one can hire extremely skilled people, have fantastic research, and have strong ideas, and still smother it all with organization, governance, and processes.
Organizations often spend an extremely large amount of energy hiring people. Interviews, cases, tests, references, multiple conversations. One may spend months finding the right person. And as soon as the person is hired, one begins to build systems around them as if the entire hiring process never took place. Excel sheets, status reporting, approvals, processes, frameworks, and metrics, so management can keep an eye on what the person is doing.
But if you have spent so much energy finding the right person, why then start designing their work based on an assumption that you cannot trust them?
Trust means for me: Autonomy over control. Not no control. Not no structure. But a fundamental trust that the people you have hired are actually assets. They have superpowers. They can do something the organization needed. And if you want access to those superpowers, you also need to give them space to use them.
This also applies to junior people. A junior should of course receive help and feedback. But there is a difference between feedback and constantly correcting their work until it looks like what you would have made. If everything always has to be as good as the most experienced person could have made it, then the less experienced will never be allowed to become the most experienced person.
Sometimes you have to accept that an asset grows. That something could have been 10% better if you had taken over, but that it might make the person 20% better next time. Trust is not just about freedom. It is also about growth.
And it is about relationships. Across an organization, something quite interesting also emerges. If stakeholders, sponsors, and teams have relational trust in each other, they need far less governance between them. They know who each other is. They have seen each other deliver. They have had honest conversations. They understand each other's intentions. They may even have something human in common.
This is not something that is emphasized much in product books. But it has enormous significance. Two people who trust each other do not need to renegotiate their legitimacy at every meeting. There almost arises a form of trust gateway. And the more trust there is, the less need there typically is for micromanagement.
This does not mean that we can just remove structure. Organizations need transparency. Management needs to see if there is progress, they need to manage finances, and they need to spot problems. That is legitimate.
And some people also love structure, systems, numbers, and clear processes. There should be room for that. If you are less experienced or in a new domain, a framework can be an enormous help. It can create structure, a common language, and a place to start.
But the more experience, professionalism, and domain knowledge a person has, the more problematic it becomes if the organization still tries to tell the person exactly how the work should be done. There was a reason you hired people for their judgement. So let them use it.
This does not mean that senior people should be above process. But one must be careful not to standardize judgement out of the organization.
And this is where metrics become interesting.
Goodhart's Law:
When a measure becomes a target, it ceases to be a good measure.
The problem is not measuring. The problem arises when the measurement becomes the work itself.
If we measure teams on velocity, number of interviews, number of experiments, process compliance, or how nice their OST is, then people will of course get better at exactly that. It is rational. But that does not necessarily mean that the product gets better.
A team can be green on all dashboards and still deliver a haystack.
That is perhaps one of the most problematic aspects of large organizations. Each part can optimize its own area. Everyone can show progress, everyone can have their own metrics, everyone can have followed the process, and still, the end result can be worse for the customer.
That is why trust is so difficult. Because trust is easy to write on a slide. It is harder when it means letting go of some control.
And at the same time, we must of course be careful of the other pitfall. Full autonomy without a common direction also creates chaos, inconsistency, dependencies, duplication of work, and lack of transparency.
So the point is not: Process bad. Autonomy good.
The point is: Use as much structure as the situation requires. And no more.
Repeatable operations can greatly benefit from standardization. Innovation and work with high uncertainty require more wiggle room. Less experience may require more structure. More experience may require more judgement. Some people function best in clear frameworks. Others are hired specifically because they can think outside of them.
A good organization should be able to accommodate both. That is where trust becomes interesting. Not as an absence of control, but as the ability to create frameworks without stifling the people you have hired to think.
Empathy. Imagination. Trust.
So perhaps it is really that simple.
Empathy = Problem Space / Curiosity. Do we understand the person, the context, and the right problem?
Imagination = Solution Space / Creativity. Are we able to envision something better than the obvious answer?
Trust = Operating Space / Autonomy. Have we created an organization where the first two are actually allowed to function?
Process can help. Frameworks can help. Metrics can help. But they are tools. They cannot replace any of the three.
And if you lack one of them, the risk is quite high that you still end up serving the customer a haystack.
When what they actually needed was the needle.
6 views