A second-year student named Afnan Ahmed reached out to me recently. He had done his homework. Knew my background, had questions prepared, was clear about his goal. He wanted to get into product management.
We connected over the call, exchanged warm salams, and he got straight to it. His first real question was about understanding customers. But I could tell he was asking something else underneath. He wanted validation for a role he had already chosen. The conversation that followed changed what he was looking for.
The Setup
Afnan is 20 years old, finishing his second year, doing an internship at OPG. He is working through a double degree in computer science and business. He has shadowed product managers, researched the field, and decided this is where he wants to go.
He asked me several questions. How do I understand customer needs? What separates effective product managers from average ones? Where should he position himself in the next few years?
But when I asked him why he wanted product management, his answer was telling.
He said he liked solving technical problems. He liked finding solutions when someone had a need. He liked the cross-combination across different teams and seeing the difference he could make.
I listened. And then I told him something he did not expect.
The Pivot
I should be clear: I am not a product manager.
My background is in engineering, research, and strategy. However, I work closely with product management teams every day. I sit between the code and the customer. I see the business strategy, and I see the technical implementation. I answered Afnan’s questions based on that intersection (what I’ve observed from effective PMs and what I know from my own experience working directly with customers).
I started by asking him a question: “Do you want to stay technical, non-technical, or a combination?”
He said combination. Product management felt like the sweet spot.
Then I asked again. “So you enjoy solving technical problems. Working with customers. Helping them find solutions. Is that right?”
He said yes.
“That would not probably be too much on the product manager’s role, though.”
Product management, as I have seen it, lives mostly on the business side. Working with customers, industry analysts, strategy. The business ownership of a product. It is not that you cannot bring technical work into the role, but the core of it is not solving technical problems directly. It is defining what to build, why to build it, and for whom.
If you really enjoy working with customers in solving a technical problem, then most likely a consulting role would be more appropriate. Or there are forward deployment engineers, client engineering teams (different companies call them differently), but the common thread is the same. You are hands-on with customers, solving technical problems.
I was not trying to talk him out of product management. I was trying to get him to ask a better question.
Find the alignment between your aspiration (what you actually enjoy doing) and the role. Do not fix a particular role title first and then try to make yourself fit. See if that role is going to get you where you want to go.
The Framework
Then we got to the real question. The one he came to ask.
“How do you understand the customer needs?”
The first layer is obvious. You need to connect with customers. Talk to them. Understand their use cases. Anyone can tell you this, and you can figure it out yourself. You need to talk to people.
But the nuanced part is that oftentimes you will not hear directly from the customers what they need. You have to put yourself in the customer’s shoes. You have to think beyond what they are asking.
So how do you figure this out?
One thing is to target a specific persona or use case category. You cannot target everyone. I learned this the hard way.
My role is focused on building capabilities inside Db2 that will help customers use Db2 as a database for their AI applications. When I talk to customers, many of them are not yet building AI applications. They are thinking about it. Some of them are still not putting active thought into it. Maybe it is somewhere in their future.
So you have to look beyond what customers are asking. You look at the industry broadly. Go outside your customer base and see what the needs are. And you need to be more hands-on.
I am also a AI practitioner. Those use cases I want to support in Db2 with my team, I build them myself. I look at the industry patterns. For example, if you look at the implementation of AI use cases (I do not have exact numbers), but roughly 80% of the use cases are not getting into production. Only about 20% make it.
So what pushes things to production? Think of the completeness of the AI stack. That is the question that drives what I build.
Then you have to give a vision to the customer. Show them what you are building, what you are considering building. Get them excited. Give them those possibilities.
Show them the path. Hold their hand. Take them through the journey.
It is a combination of educating them, showing them new angles, and then building a solution that works for them. It is a journey with your customers.
The Strategy
Then I told him something more specific. Something I made a conscious decision about a few years ago.
In the customer base for Db2, there are database administrators. There are business leaders. There are application developers building applications with Db2. Even within application developers, there is a subcategory: AI application developers.
I made a decision that I was not going to target every single persona. Because then my message would be cluttered. It would not land.
I picked one. AI application developers.
Then I went deeper. I looked at their use case patterns. What are they trying to build? What is stopping them? How can we support this?
I started creating tutorials. First, a lot of beginner-friendly tutorials. I still do those. Then I focused on more advanced tutorials. What it takes to push things to production. The pain points. The gaps.
Then I reverse-engineered from there. To support those kinds of use cases and production deployments, what do we need to bring into the database? What capabilities are missing?
Once you build this, you have a vision. Then when you talk to customers, they recognize that this is coming. Even if they are not actively building it yet, they see the path to get to the finish line. To production.
You have to think the entire journey.
The Advice
By the end of the conversation, Afnan was reconsidering things. Not in a bad way. He was thinking.
I told him: if your ultimate goal is to contribute technically, maybe spend some years early in your career focused on hands-on building. Less travel, less non-technical work. You learn more, you are more hands-on, you build a solid technical edge. Then you can always add product management or move toward it later.
A strong technical base is going to pay you off long term.
He said: “I’m going to kind of deepen my understanding. Maybe I have the wrong alignment on what product management is and the consulting side. I’m just going to put some thought into everything you told me.”
Then he asked if we could talk again in a few weeks.
That is all I could ask for. Not a fixed answer. A better question to sit with.
If you are early in your career, ask yourself what work you actually enjoy. Not what title sounds good. Find the alignment first. Everything else follows from there.