This is one of the pet peeves that some people working with me might have noticed: when engineers can only think of “PM” meaning “Project Manager”. There’s a role called “Product Manager” for a reason - you’re building a digital product that involves endless projects.

The reason why it triggers me is because there’s a fundamental gap between finishing a task and owning an outcome. One is project thinking, the other is product thinking. As a hiring manager representing in-house teams (like I do at Worksome or did at SumUp before), this is one of the main things I look for.

Project thinking is the tip of the iceberg: scope, budget, timeline. Clean. Measurable. Manageable. You get told what to do, you do it, you succeeded.

Product thinking is everything under the waterline. Messy. Ambiguous. Never finished. You’re never sure about what’s the best next thing you can do, you need to always second guess yourself.

Most candidates with certain experience are great at polishing the tip and delivery. But when working on something where the solution is unknown (such as trying a new business model, as startups do), I look for people brave enough to dive into the cold, dark water underneath, who dare to accept that what they do might be futile. Even if it’s done well.

A project has a start date, an end date, and a specification. You manage its risk successfully — you “win”. Success means shipping on time, on budget, to spec. Clean handoff. Move on to the next project. A typical way of working in consulting or in agencies. Or in an environment of low agency.

Product work has no finish line. The spec is a hypothesis always subject to change, based on the newest data. Success means the thing actually works in the hands of real users, and you keep iterating until it does.

How does this look in practice?

Project thinking:

  • “The feature shipped on Tuesday like we planned.”
  • “We delivered 100% of the sprint commitment.”
  • “No scope creep — we held the line.”
  • “My biggest failure was not delivering the project on time.”

Product thinking:

  • “Feature shipped Tuesday, but adoption is at 12% and retention drops at day 3. Something’s off.”
  • “We shipped 60% of what we planned, but the 40% we cut was the wrong choice — users are confused without it.”
  • “We kept scope under control, but we shipped something nobody uses.”
  • “My biggest success was preventing development on a dubious initiative and falsifying it first with a fake door test.”

Both perspectives are reasonable. One of them is dangerous alone for the kind of teams I want to lead: high agency, high ownership, high autonomy, and will probably lead to dissatisfaction. The kind of “why am I not better valued professionally, if I’m doing the things one is supposed to do?”.

I learned the difference the hard way. Early in my career, I worked for clients that had a very clear idea of what they wanted. We delivered, got paid on time. A success on the books. Predictable, safe.

The issue I had, and couldn’t put into words? Nobody checked the data. Was what we built useful? Was it used at all? Was it saving time, or helping the expected users? Nobody knew. Nobody needed to know. It was not part of the business model. When you consult, your job ends at the delivery.

I wanted more, I wanted to do something actually useful, beyond “getting paid”.

When I’m hiring now, it’s not that I am looking for people who’ve never written a project plan. Project management is a real skill (and a hard one). Delivering things on time, prioritizing and managing stakeholders is complicated.

But what I’m looking for is the reflex to zoom out and ask why.

The candidates who stand out for a product team don’t just deliver. They question what they’re delivering. The ones who don’t? They hand me a tidy list of deliverables and can’t tell me why any of them mattered. They talk about “closing tickets” or pull requests like the whole point of the job is a glorified todo list that someone hands you over.

A great developer looks for the highest return on their effort. They understand the hardest problem is rarely technical. It’s the “do we even know what we’re building and for whom” problem. Wasted effort, even when technically neat, is still wasted. The best engineers I’ve worked with don’t resist that ambiguity. They go looking for it, because that’s where the real problems hide.

As I was opening with, one of my red flags in interviews is when a developer uses “PM” to mean only “project manager” and has treated that role as their primary interface to what and why they’re building. Someone who has spent years taking tickets from a PM without questioning the user or business context is operating in project mode. They’re executing, not owning.

And they might have been conditioned to that: don’t think, don’t question, don’t delay execution. Just finish your code.

Delivery without impact is motion, not progress.

That realisation doesn’t come from a course. It comes from the things that sting: shipping something you were proud of… that nobody used. Presenting a roadmap and not being able to answer “why this one first?”

I’ve seen junior engineers become product-minded within two years because they wanted to. They followed their curiosity, they started reading usage data. They asked to sit in on user interviews. They started to ask “why do we do this now?”. They pushed back on tickets that didn’t connect to a real problem. Nobody drove them to that growth. They pursued it.

I’ve also seen senior people with fifteen years of experience who still think “done” means “deployed.” Their tickets are tidy. Their deadlines are met. Their impact is invisible.

Of course there are no silver bullets. There’s a limit to how much this matters as an individual trait. Product thinking can’t survive in a hostile environment. I’ve watched great product thinkers burn out in organisations that measure output and nothing else. If you’re a manager reading this, that’s on you. Build the culture. Protect the people who ask “why” before “how.”

But the opposite trap is far more common. I’ve watched teams burn six months on beautiful, project-managed features for problems nobody had, because nobody paused to ask whether the output matched the outcome. The skill isn’t about never writing a project plan. It’s about knowing which mode you’re in and being able to switch.

If you’re preparing for a hiring conversation or trying to make your career more product-focused, some topics that help you spark the flame on the kind of trait I usually look for:

“Tell me about something you shipped that didn’t work.”

A great experience will include data, reflection, and what they changed. Weak stories will blame the user, blame the timeline, or claim everything worked perfectly.

“What’s something you decided not to build?”

Mastery will show prioritisation with a thesis. Red flags will include “we ran out of time” without reflecting on whether the right things got cut.

“How do you know if your work matters?”

This is the one you should really reflect on. If the answer is “the client wanted it” or “we hit the deadline,” you’re bound to project territory. If you’re able to include a metric, a user behaviour, or a business outcome (even imperfectly), we’re getting somewhere.

This is difficult to fake — a couple of follow-up questions will expose you.

I don’t expect everyone to have perfect answers. I’m not looking for people who’ve never missed a deadline or shipped a dud. I’m looking for people who’ve noticed the difference. People who understand that anyone can point to the tip of the iceberg and who have shown curiosity about what they were doing (and why).

Stop polishing your list of deliverables. Start measuring your impact.