There is a quiet lie designers get sold.
The promotion track suggests product leadership is just design leadership with a better title, more meetings, a larger calendar burden, and maybe a small bump in equity.
It is not.
The transition from design to product leadership is a loss of innocence. You stop being the person asking whether the experience is good and become one of the people deciding what “good” even means when the business is leaking cash, engineering is at half-capacity, the customer is impatient, the team is tired, and the founder still wants the thing shipped by Friday.
That sounds dramatic. It is also the most honest description I have.
I remember exactly when this first became obvious to me. It was at Farmcrowdy, sometime around 2018. I had moved from founding designer into a role that did not quite have a clean name yet, though it eventually became Head of Programs and Product, and we were facing a problem the design team alone could not solve.
Sponsors were funding farms, but the journey from money-in to harvest payout was full of opacity. No progress bar, dashboard, or prettier status update could fix that. The interface was only where the anxiety became visible. The deeper issue was that we had built a marketplace promise without fully designing the operational machinery required to keep it true.
My CEO, Onyeka, our COO, Tope, Blessing from marketing, and I would sit on calls with farmers, operators, and sponsors, and the same pattern kept repeating itself. Every painful question was downstream of a decision someone had not made early enough.
Where exactly is the farm?
What stage is the cycle in?
Who has confirmed the update?
What happens if weather shifts the expected harvest date?
What does the sponsor see, what does the operator know, and what can the business responsibly promise?
These were not interface questions. They only arrived at the interface because the system had failed to settle them earlier.
That was the year I stopped being a designer who happened to lead and became a product person who still designed.
Since then, the work has kept changing shape on me.
At Earlybean, the question was never simply, “How do we build a better financial learning experience for young people?” That phrasing is too clean. The real question was messier. How do you build a product parents can trust, children can understand, schools can adopt, and a small team can realistically operate from Lagos while serving families across different markets and time zones?
How do you make financial literacy useful without turning it into homework? How do you design around family dynamics, different income levels, different ideas of responsibility, and the quiet anxiety parents carry around money in a country where one bad scheme can take a household down?
When we got into Techstars in 2023, I thought the hardest part would be the product. The harder part was the model. Designing the model so the product could exist at all.
At Mular, the design problem was not, “Can users send money?” That is the easy phrasing. The actual problem was: can Nigerian users trust a crypto-to-fiat product enough to move value through it repeatedly, without feeling like they are about to be scammed, delayed, exposed, or punished for misunderstanding one small detail?
We moved more than $1.9M in transaction volume across 17,000+ transactions for 5,000+ users and 70+ business accounts. None of that happened because the UI was clean. The interface mattered, obviously. But the product worked because the system behind the interface gave people enough truth, timing, proof, and reassurance to act.
That is not a UI problem. It is a trust, operations, compliance, liquidity, support, communication, and product problem wearing a UI costume.
At Learning Equality, working on Kolibri, the question kept expanding outward again. Not “How do we improve the dashboard?” but how do we design learning and administration tools that survive real conditions across countries, devices, connectivity levels, classroom structures, and institutional realities?
Kolibri runs in places where the internet is a guest, not a host. Where the same laptop may serve twenty children. Where the person who set up the system is often not the person teaching with it the next morning. Thirteen million learners across more than two hundred countries and territories will quickly cure you of romantic ideas about “global” design.
Somewhere along this stretch, from Farmcrowdy to Earlybean to Mular to Kolibri, design stopped being a department in my head. It became a way of seeing the full organism.
That is where product leadership begins.
Not when you start managing people. Not when you own a roadmap. Not when someone gives you permission to sit in more meetings. It begins when you are no longer satisfied with making the visible layer better while the underlying system stays confused.
This was the uncomfortable shift. I had to stop treating “quality” as something that lived mainly inside the interface.
A clean flow built on a confused business rule is not quality.
A polished dashboard that does not match how operations actually works is not quality.
A beautiful onboarding sequence that collapses at KYC, support, reconciliation, or fulfilment is not quality.
A product that tests well in a calm environment but fails under pressure is not quality.
Designers often talk about “user needs” as if the user exists in isolation, floating somewhere outside engineering capacity, operational cost, regulatory anxiety, founder ego, customer support bandwidth, growth targets, and the occasional chaos of a Nigerian bank transfer deciding to behave like a moody deity that day.
Product leadership forces you to hold all of it.
You still have to care about the user. Deeply. But you also have to care about the machine that must serve the user every day.
So the questions change.
What has to be true operationally for this promise to hold?
Where will support get overwhelmed?
Which part of the experience depends on human intervention pretending to be software?
What breaks when volume doubles?
What are we asking engineering or marketing to absorb because product has refused to make a decision?
What are we calling “MVP” because we are disciplined, and what are we calling “MVP” because we are avoiding the harder conversation?
That last one matters more than people admit.
A lot of bad product work hides inside respectable language. Lean. Agile. Iterative. Fast-moving. All useful ideas. All frequently abused.
In startup environments, especially venture-backed ones, there is a temptation to confuse motion with progress. A team ships a lot, changes direction often, has a busy Slack, and somehow still avoids the fundamental question: what are we actually trying to learn, prove, or unlock?
The product leader in me has had to learn that clarity is sometimes a negotiation, sometimes a fight, and often a decision made with incomplete information.
This is the unglamorous part.
You become more accountable for trade-offs. You cannot simply point at the flaw and say, “This experience is broken.” You have to decide whether fixing it matters now, what it costs, what it delays, who needs to be involved, and what risk the team accepts by postponing it.
You also become more aware of sequencing.
Designers, especially good ones, can see many layers of a problem at once. Useful. Also a curse. You see the whole mess. The broken information architecture. The weak mental model. The unclear permissions. The missing admin tools. The support gaps. The reporting debt. The copy that sounds like it was written by a committee trying not to offend a spreadsheet.
Product leadership asks a more brutal question: what is the next necessary move?
Not the perfect move. Not the most elegant move. The next move that changes the team’s ability to learn, ship, support, or sell.
My design background has helped me here more than anything else. Design trained me to notice friction. Product leadership forced me to classify it.
Some friction is accidental and should be removed.
Some friction is protective and should be designed properly.
Some friction is organisational and cannot be solved by interface changes.
Some friction is strategic because the product has not yet decided what it wants to be.
In fintech, removing the wrong friction can destroy trust. In education, optimising for speed can punish comprehension. In operational software, hiding complexity can make frontline work harder because the system stops reflecting reality. A sleek product that ignores the rhythm of the people and processes behind it is basically decoration with a login screen.
The work stops being about making software feel simple. It becomes about deciding which complexity the product should absorb, which complexity the user must understand, and which complexity the organisation has to fix before software can help.
That is the job.
There are days product leadership feels like standing in the middle of several half-built bridges, arguing with gravity. Design wants coherence. Engineering wants solvability. Business wants momentum. Operations wants fewer disasters. Users want the thing to work. Founders want evidence that the future is arriving fast enough to justify the burn.
Your job is not to make everyone happy. That is a child’s ambition.
Your job is to make the work more true.
More true to the user’s context.
More true to the team’s capacity.
More true to the business model.
More true to the constraints nobody wants to name.
That is the part I did not fully understand earlier. Product leadership is not the abandonment of design. It is design under heavier consequences.
The craft still matters. The screen still matters. The words still matter. The flow still matters. But they matter as part of a larger system of promises.
Every product is a promise with machinery behind it.
Design can make the promise visible. Product leadership has to make sure the machinery can survive the promise.
That, more than any title shift, is what the transition actually looks like.
Less glamorous than people think.
Also much more interesting.