Blog

If you were there, hi again. If you weren’t, first of all, you missed a good, good time, and second, here’s the next best thing. Below is the full transcript from my session at the Women in Tech Global Conference 2026. I talked about why the best Product Leaders are, quietly (and secretly), Master Project Managers. The response was incredible and honestly caught me off guard.

So, here it is — unfiltered, unedited, exactly what I said on stage.

The slides are below too. TED-style, very sleek, and largely unused because I was too busy talking. Classic.

OPENING

Hi everyone. I’m Ifrah.

I need to start with a confession. Not the kind you make to HR, the kind you make when you’ve spent 15 years calling yourself something you’re not.

My LinkedIn says I’m a Product Leader. And I love that title. It sounds important. It sounds strategic. It conjures up images of me in a 2.5 inch heel, standing in front of a whiteboard, drawing circles with arrows, disrupting industries.

Makes me sound like an architect building a cathedral.

But honestly? My actual day-to-day life looks more like being a wedding planner for an elite couple who refuse to agree on the guest list, the budget, or whether they even want to get married.

I have a Master’s in Biotechnology. In a lab, if you don’t follow the protocol, things literally explode or die. I learned very quickly that the scientific method is not a suggestion.

Then I moved into tech.

And in tech, we have a special word for ‘not having a protocol.’ We call it being Agile.

I have spent nearly two decades slowly realizing that ‘Agile’ is often just a very expensive word for ‘I have a vision but absolutely no project plan.’

And THAT, my friends, is the secret I’m here to tell you today.

Great Product Management is just Project Management in a more expensive outfit.

SECTION 02

Let me introduce you to two characters. You will recognise both of them. You may have worked for one of them. You may, quietly, be one of them.

Character one: The Visionary.

The Visionary has 50 slides about the future of AI. They can explain to you, at length, at dinner, uninvited, exactly why your industry is going to be disrupted by Web 5 or whatever comes after that.

But if you ask them whether the login button is going to work by Thursday?

Silence.

That’s not a roadmap. That’s a daydream. Beautiful, cinematic, nobody can live in it.

Character two: The Treadmill.

The Treadmill is shipping features. Constantly. Relentlessly. The sprint board is full, the velocity looks great, the burn-down chart is a thing of beauty.

The only problem? Nobody asked for any of it.

You’re running at ten miles an hour, sweating, lungs burning and you’re still in the same room. You’re ‘delivering,’ technically. You’re just delivering a product nobody wants.

Now here’s where it gets interesting.

The best Product Leaders I’ve ever seen and the kind I’ve tried to be are neither of those people.

They’re the person in the room who raises their hand and says: ‘The vision is great. I love the cathedral. But who is actually buying the lumber? And when is the truck arriving?’

That person is not playing a supporting character. That person is the reason anything actually gets built.

And what they’re doing, underneath all the Product vocabulary, the OKRs, the discovery sprints is project management. Old-fashioned, unglamorous, absolutely essential project management.

SECTION 03

In my bio, which I wrote, so I can say this — I claim that the most critical API is human connection.

Let me explain what I mean.

Computers are easy. I mean this sincerely. You tell a computer exactly what to do, and it does it. Every single time. No mood swings, no Monday morning energy, no ‘I thought we said something different in the last meeting.’

Humans, on the other hand?

Humans are legacy code, jam-packed with bugs, running on systems that haven’t been updated since childhood, and they are the most poorly documented API on the planet.

They have feelings. They ‘feel things.’ They come with wildly varying levels of caffeine in their systems. Some of them have not had their coffee yet and you are asking them to approve a budget.

A great Product Manager, who happens to be a Master Project Manager in disguise, and knows how to speak three (critical) languages.

Language one: Developer.

A good PM knows how to ask for requirements without evoking deep, existential resentment. This is a skill. This is an art. If you’ve ever watched a bad PM walk into a standup and say ‘can we just add a quick thing’, you know what I mean. There is no such thing as a quick thing. There is no such thing.

Language two: Stakeholder.

Stakeholders speak in one dialect: ‘when will this make money?’ That’s their language. You need to speak it back to them without losing the thread of what you’re actually building. You’re translating a CEO’s dream into a JIRA ticket that a developer won’t want to throw a chair at.

Language three: Designer.

Why is this button 2 millimetres to the left? I’ll tell you why. Because to a designer, that 2 millimetres is the difference between intention and accident. You either respect that, or you spend the next three sprints dealing with passive-aggressive Figma comments.

Let me tell you about Pakistan’s first on-demand tailoring app. Which I built. Which is either the most niche sentence I’ve ever said, or the best opener to a war story — you guys decide.

We were building something that had genuinely never existed before in that market. No playbook, no competitor to benchmark against, no ‘let’s just see what Uber did and copy it.’

Nothing.

And very quickly, I learned that my job wasn’t Product Manager. My actual job was to be an expectation debugger.

The tailors had expectations. The customers had expectations. The investors had expectations. The logistics riders had expectations. And not one of these groups had spoken to any of the others.

We hit 10,000 downloads in 4 months. But not because of a great product vision, although we had one. We hit 10,000 downloads because someone tracked every dependency, managed every stakeholder conversation, and made sure the checkout experience actually worked before we launched.

That someone was also doing the job of a project manager. That someone was me.

SECTION 04

Scale changes everything.

When you’re building for one market, you can hold a lot of context in your head. You know the user. You know what they want. You can make fast calls.

When you’re building for 31 countries, across North America, MENA, Central Asia, and South Asia, the definition of ‘good’ becomes a moving target in 5 languages, and it is moving very fast.

I was VP of Product and Brand at a company where we built a custom CMS for over 5,000 users across 31 countries. And here’s what nobody tells you about building at that scale:

The tech is the easy part.

The hard part is that ‘simple’ means something completely different in Karachi than it does in Kazakhstan. ‘Intuitive’ in one market is ‘confusing’ in another. ‘Professional tone’ in one culture is ‘cold and offputting’ in another.

And in that environment, your roadmap is not a vision document. It can’t be. Your roadmap is a living, breathing operational tool, updated constantly, with dependencies tracked, and owners assigned because if you’re running 31 deployments and something breaks in Singapore at 02:00 AM, you need to know whose JIRA ticket it is.

The project management was not the support act. The project management WAS the product.

We also launched 9 new international brands in a single year. From the outside, that sounds like a product achievement. And it was. But from the inside? It was a scheduling achievement. A dependency-mapping achievement. A ‘please tell me this vendor in New Zealand is awake right now’ achievement.

Vision got us into the room. The structure kept the lights on.

SECTION 5

Nobody in a Product Management interview has ever said: ‘My superpower is that I maintain a very clean dependency log.’

Nobody has ever opened a conference talk with: ‘I want to tell you about the time I built a really solid risk register.’

And yet. These are the things that separate the people who ship from the people who just talk about shipping.

I teach Product Management 101 for Pakistan’s first product accelerator for women. And when I designed the curriculum, I made a deliberate choice.

I called one of the core modules ‘The Not-So-Sexy Side of Tech.’

Because everyone wants to talk about the zero-to-one journey. The founding story, the pivot, the moment of insight in the shower. Everyone wants to be the person who had The Idea.

Nobody wants to talk about the one-to-five-thousand journey. The scaling, the processes, the documentation that nobody reads but everyone needs when something breaks at 2 in the morning.

Here’s the truth I teach my students: the Agile manifesto, the AI prompts, the frameworks, the product sense — that’s the sexy stuff. And the sexy stuff gets you the interview, and yes gets you the job. But the project management stuff keeps you the job.

I currently run Payments and Partnerships. And if you want to talk about a world where structure is non-negotiable — it’s payments.

In payments, ‘we’ll figure it out’ is not a strategy. ‘Move fast and break things’ will get you regulatory action. When you’re managing 20+ processors across multiple markets, every integration has a dependency. Every partner has a contract. Every compliance requirement has a deadline.

And the Product vision, the growth strategy, the market expansion, the revenue potential, only exists because someone is tracking those dependencies.

Someone has a spreadsheet.

Someone has a risk log.

Someone is not embarrassed to say: ‘I need to map this out before we commit.’

That someone is the Master Project Manager.

And if that’s you, if you’re the person in the room who quietly opens the shared doc, adds the owners column, sets the due dates, follows up when nobody else does, I want you to hear this:

You are not doing the boring part.

You are not doing the soft part.

You are doing the most important part.

CLOSING

I want to leave you with something.

We spend a lot of time in this industry trying to be the next Steve Jobs. And look, Steve Jobs was extraordinary. The vision, the taste, the reality distortion field.

But Steve Jobs also had Tim Cook.

Tim Cook didn’t disrupt anything. Tim Cook built the supply chain that made the disruption possible. Tim Cook is the reason that when Steve Jobs said ‘we’re shipping this in 6 weeks,’ there was actually a product to ship.

Most organizations don’t need another visionary. They need someone who can sit in the meeting where the vision is announced, and immediately start thinking: okay, what’s the first dependency? Who owns the first step? What does done actually look like?

Vision needs structure to become reality.

So here’s my ask. Stop trying to be Steve Jobs just for five minutes. Try being the person in the room who makes sure the meeting has an agenda.

Try being the person who follows up on the thing everyone agreed to do but nobody wrote down.

Try being the person who, when the CTO says ‘we’re launching in Q2’, opens a blank spreadsheet and starts listing what needs to happen in Q1.

That’s not small.
That’s not support.
That is the whole job.

So, dear Product Leaders.

Go forth. Be Project Managers in disguise.

Just don’t tell the recruiters. Let’s keep the ‘Product’ title for the pay bump.