The Product Manager isn’t a manager. Here’s the real job.

Mina Sami got his first PM job before he graduated — thanks to a four-day competition at a beach resort in El Gouna. Twelve years later, he’s built products at P&G, Microsoft, and Procore. He says almost everything students think about Product Management is wrong, starting with the word “manager.”

Mina Sami didn’t set out to be a Product Manager. He went to Cairo University to study Computer Engineering, did Google Summer of Code as a developer, took a Facebook scholarship in deep learning, and assumed he’d end up writing code somewhere — possibly in AI. Then, in his last year, he signed up for a four-day case competition in El Gouna run by Procter & Gamble. Mostly because he wanted to spend a long weekend by the sea.

P&G offered him an Application Engineer role: half developer, half product manager. He took it and never left the product side. (A fact he loves: P&G is widely credited as having invented modern product management in the 1970s, under the name “brand management.” The discipline is older than most software companies.)

A Product Manager doesn’t manage people. That changes everything.

The first myth Mina dismantles: the title. A PM doesn’t have direct reports. The developers building your feature don’t work for you — they work for an engineering manager. Designers report to design leadership. Sales has its own chain.

Which means: your only tool is influence. You can’t order anyone to do anything. You convince them. You argue with data. You build a case. You earn trust over weeks and months. If you can’t persuade without authority, you can’t product-manage. That single fact reshapes the entire job.

The language of product is data — not English

When asked what language a PM needs, Mina laughed and gave a slightly mischievous answer: data. Yes, English is useful (most international companies operate in it). But the actual language of every product meeting is data: market research, user metrics, conversion funnels, A/B test results.

Everyone walks into a product meeting with an opinion. The PM’s job is to dissolve opinions into something you can measure. “I think users would love this” isn’t a sentence in product. “Our funnel drops 38% at step three; here’s our hypothesis and how we’ll test it” is.

Domain expertise: needed eventually, not at the start

Should you wait until you have deep domain knowledge before applying for PM roles? Mina’s answer is clear: no. When he joined P&G in supply chain, he didn’t know what the three-letter acronyms in his meetings meant. He picked up an MIT MicroMasters in supply chain after he was hired, not before. The skills that transferred — thinking like a PM, structuring problems, communicating with stakeholders — got him in. Domain came on the job.

At a senior level, domain matters more. At entry level, what matters is that the PM-shaped neurons in your head fire correctly. He’s seen PMs come from development, UX design, sales, supply chain operations — every path is valid as long as you bring the way of thinking.

How big-company PM actually works (the reality vs. the meme)

A common misconception: that Mina, as a PM at Microsoft, was “in charge of all of Office.” The reality of any large company — Microsoft, Google, Procore — is that products are decomposed into smaller products, each with their own team, each effectively a startup inside the company. When he worked on Microsoft SwiftKey (the mobile keyboard), there were 4-5 PMs assigned to that single product.

This is good news for anyone aspiring to break in. You’re not interviewing to run a multi-billion-dollar product on day one. You’re joining a focused team that operates with startup-like speed inside a larger structure.

The portfolio question — and what the CV can’t fake

For aspiring PMs, the CV vs. portfolio debate has a real answer: the CV gets you the interview; the portfolio gets you the offer. Courses, books, certifications — nice references, but they don’t prove anything by themselves. What you’ve actually built does.

If you’ve never been a PM before, build your own product the way a developer would build a portfolio project. Don’t have a product? Take an existing one you use and dissect it. Why does the user open this app every day? What’s the worst thing about it? If I had a quarter to fix one thing, what would I fix and how would I measure success? That kind of thinking on paper, with numbers, is what hiring PMs are screening for.

AI and the PM — not a replacement, a force multiplier

Mina’s analogy for AI is the industrial revolution: when machines entered factories, the worker’s job didn’t disappear — the worker who refused to learn the machine did. Today, a PM who doesn’t use Cursor, Claude, ChatGPT, or specialized tools like ChatPRD is competing with both hands tied.

He personally uses Cursor (yes, the developer tool) for product work — for source-diving into the codebase, summarizing engineering RFCs, drafting requirements. The goal isn’t to look impressive; it’s to compress days of work into hours, then spend that recovered time on the parts of the job AI can’t do: stakeholder management, the politics of priorities, and product judgment.

The skills that transfer across every product you’ll build

Mina has worked on keyboards (Microsoft SwiftKey), construction software (Procore), and supply chain optimization (P&G). He’s emphatic that the products are different but the skills are the same. The thing he carries from job to job:

Stakeholder management. Knowing who in the room cares about what, and shaping your story for each of them.

Pattern recognition across implementations. Growth strategy in B2B SaaS isn’t fundamentally different from growth strategy in a mobile keyboard — only the surface tactics change. If you’ve solved it once, you can adapt it.

Early-and-often testing. Showing rough versions to your own team first, then to people outside the team. The earlier you find out what’s broken, the cheaper the fix.