Hire the translator, not the title.

Each discipline read that finding differently. Product saw a pricing problem. Design saw an onboarding problem. The data lead saw that users were researching from the wrong starting point and leaving before anything paid them back. Our COO saw something none of us were looking at: in some countries, customers who wanted to pay could not.

All four were right, and none of them was the whole answer. We kept projects, because consultants needed one folder per client. We rebuilt onboarding to ask what each business needed before it handed them anything. We added reports a consultant could give a client.

And we built Ubersuggestions, on a lesson from games: finding what is wrong is faster than building something new. It started every customer on the fixes a site audit could find in minutes, then ranked the bigger bets, the keywords and the content, by what each was likely to be worth. Content takes months to pay back. Progress cannot wait that long.

Games taught me the arithmetic that roadmaps get wrong. A few small wins that land this week are often worth more than one bigger win that lands next quarter, because the gap between the value someone feels and the value they eventually get is where they leave.

With our COO, we fixed the commerce underneath it, so customers could pay from where they were. There is nothing worse than wanting to pay for something and not being able to. Monthly voluntary churn went from about 14% to 5.4%, and involuntary churn, the payments that fail, halved.

The decision was only possible because those people, product, design, data and operations, trusted each other enough to say "I think the problem is actually something else."

This year the industry found a new complaint. AI writes the code now, engineering is fast, and teams sit waiting for someone to decide what to build. Leaders are starting to say the bottleneck is them.

The instinct is to make the decider faster. More process, a tighter cadence, a better template. I think that misreads where decisions come from. They are made when the people who each hold part of the picture can put it on the table and be heard. That runs on trust, and trust has an order.

First, where I am standing. I started as a designer, so I am biased, and I will try to show where.

In the agencies I came up in, and at the first software company I worked for, strategy calls were made by UX strategists and creative directors. Then the product manager arrived, in agencies, in software, everywhere. Often it brought a hierarchy with it, the same tension games have always had between a creative director who owns the vision and a producer who has to get it shipped. That tension is healthy. What happened next was not. In too many companies the role drifted from weighing trade-offs to managing the project.

That was not product managers' fault. Companies measured delivery, so delivery is what the role learned to produce, and the tools were built to track it. It is what always happens when you measure output instead of outcomes: you get very good at shipping, and less sure what any of it was for.

AI is taking some of those hats now: the tickets, the breakdown, the status. It can analyse trends faster than any of us. It cannot predict the future, and the bet still has to be somebody's. I prefer data-informed decisions to data-driven ones, because they leave room to discover something a customer needed and did not know to ask for.

Of all the hats, two matter most. The first is the loop with everyone else: why this decision, why it matters to the customer, and why we think it moves the business toward where the market is going, not toward what the market did last quarter. It is not a status update. It is confidence and foresight, offered without building a process so rigid the company cannot turn when the market does. It is translation, done every week.

The second is the portfolio. How much have we spent on onboarding over the years, and is it paying back? Which user paths are expensive to change? Where is the UX debt, next to the technical debt? These are bets, and bets need permission.

The order is the point. Nobody hands their budget to a person they do not trust, so the portfolio is out of reach until the loop has earned it. You earn it by serving the people around you first: explaining, listening, changing your mind in public when the data lead is right. That trust buys the right to place bigger bets. Bets that pay back build more trust. Each turn makes the next one easier, which makes it a flywheel, and whoever wears the hat owns it.

It is the same design as Ubersuggestions. A customer stays for the slow wins because the fast ones came first. A team trusts the bigger bets because the small ones paid back. I learned that in games before I had a name for it: design the progression, and people will stay long enough to get somewhere.

If I were starting a company today and had to choose between a product manager whose record is running production and a senior designer who has sat through the ceremonies of software development, I would hire whoever can show me translation, and in my experience that is more often the designer. Here is my bias again, so weigh it. The production hats are the ones AI is taking. What is left, deciding what deserves to exist and how it ought to feel, is where a good designer starts. A minimum lovable product is judged by how it feels to use, and that is a designer's craft.

The same is true of tech leads with real business sense. I have worked with many designers and engineers who could do this job and did not want it, because of the politics. That part is real work, and it is the first hat, not overhead. Where designers are weakest is the second hat: pricing, saying no, betting on where the market is going instead of polishing what is in front of them. So hire the designer, and make sure someone wears the commercial hat beside them until the loop has earned them the portfolio.

Most product software is built for the second hat and assumes the first one happened. It is very good at the hierarchy: themes, epics, features, stories. It is weak at translation, showing a trade-off so that the CFO, the designer and the tech lead each understand what is being given up. Until it can, know which hat your tool is wearing, and which one is still yours.

One item to a sticky note, and under each one write the sentence the customer would say about what they are trying to do. Bring product, design, data, engineering and whoever runs operations. Sort the wall twice: once by value, once by how hard each item would be to change. The two orders will not match, and the gap between them is the conversation you have been missing.

Then go around the room with one question: what do you need from the others to make the top of this wall work? Anything nobody can explain in the customer's words comes off the wall. Before anyone leaves, have each person say what the top of the wall means to them. A wall makes it easy to agree on the picture and read it differently. If the answers do not match, you are not done: the same understanding, not the same preference.

If your team is distributed, do not try to copy the room. Run it distributed-first, and you may get a better result. Put the wall on a shared board. Before anyone meets, each person sorts it on their own, both ways, and adds one line on what they need from the others. Separate sorts mean nobody anchors on the most senior person's order, and the board shows you exactly where the disciplines disagree. Then meet only for those disagreements. Close in writing: each person posts one line on what the top of the wall means to them. If the lines do not match, you are not done.

That is the first hat, worn for an afternoon. Do it every few weeks and the second starts to come to you.

People decide at the speed they understand each other. Design your team's progress the way you would design a player's: small wins first, bigger bets once they are earned.