Product Management Isn’t One-Size-Fits-All
Not every Product Manager is cut from the same cloth.
Listen to this AI-generated podcast discussing this issue. Maybe it will inspire and intrigue you to dive into the entire article!
Note: Since this is AI-generated, it adds its own 'salt and pepper'—otherwise known as hallucinations. While it may have added a little extra flavor, I generally agree with the AI’s discussion overall.
#beyondAI
Only two things shape the role of Product Manager like nothing else: the type of solution required and the customer type having the problem.
Not every Product Manager is cut from the same cloth.
Each role demands something different. Have you ever wondered why some PM roles feel completely different from others? Or why a PM who thrives with end consumers might struggle with internal teams? And why we have so many different PM titles—Data PM, Platform PM, or AI PM?
Understanding these differences could be the missing link in aligning your skills with the right opportunities—or finding the right person for the role.
Over the years, I’ve served different customer types, each peeling back a different layer of my skills as a PM. Every experience shaped me, making me a better PM for the next role. And yet, they felt so different.
Today I’m diving deep into how these two factors – solution type and customer type – define the unique role of a PM. From internal teams to B2C markets, from AI solutions to security protocols, each combination demands a different approach, mindset, and specialization.
Happy reading 🛋️
Why Solution Type Shapes the PM Skill Set
I think it’s pretty straightforward why the type of solution defines the type and required skill set of a Product Manager. But let me explain this a bit.
When we’re talking about different kinds of solutions – say, a platform, an API, a security system, or an AI product – each one comes with its own demands, requiring a Product Manager who can go beyond just knowing the product’s user-facing aspects. Some solutions are highly technical by nature, needing someone who not only understands the problem but also has the technical fluency to navigate the solution space effectively.
For instance, a Product Manager working on APIs or developer-focused platforms must have a deep understanding of how systems integrate, communicate, and scale. You’re not building for end users; you’re creating tools for developers who have specific expectations around reliability, efficiency, and documentation. Here, the PM needs to be comfortable diving into technical specs, understanding backend requirements, and working closely with engineering on the architecture. A generalist PM might struggle to keep up in this environment because they’re missing the technical fluency needed to make informed decisions.
Then, there are products like AI solutions, where the technical complexity – let’s not call it another level but different – requires a distinct skill set. An AI PM has to be familiar with concepts like data pipelines, model training, and performance metrics. They don’t need to be data scientists, but they do need to know enough to ask the right questions, understand trade-offs, and communicate effectively with a highly specialized team.
Product Managers who specialize in a specific technology must have a deep technical and conceptual understanding of that technology – this is not just beneficial but mandatory. Even within AI product management, there are different areas of expertise:
Natural Language Processing (NLP) – working with language data to build conversational agents or text-based insights
Image Recognition and Computer Vision – creating applications that interpret visual data
Predictive Analytics and Recommendations – building models that predict behavior and trends
These are distinct subfields but fall under the broader umbrella of AI. An AI PM fluent in core concepts can more easily navigate from one subfield to another with some upskilling, while a generalist might struggle to gain the needed depth.
When the solution is this technical, a PM who lacks foundational knowledge is going to have a hard time driving the product forward.
The more complex or specialized the solution, the deeper a PM’s technical understanding needs to go. But I'm not saying you have to write code or be an engineer – it’s about having enough technical grounding to make sound decisions, build trust with technical teams, and guide the product in a way that aligns with its technical demands.
While solution type determines the technical abilities a PM needs, the customer type reshapes the mindset required to thrive. To explain this, let me give you a short overview of my own experiences and then dive deeper into my current role as an internal AI Product Manager.
Why Customer Type Shapes the PM Mindset
B2C: Creating for Users with Endless Options
Starting my Product Management career in the B2C space and it was an eye-opener to the world of user-driven innovation. My “customer” wasn’t just one person or even one type of person – it was a vast, diverse mix of end consumers, each with unique needs, backgrounds, and motivations. This was a space where functionality alone wasn’t enough to win users over. Products here had to be intuitive, engaging, even delightful. I quickly realized I wasn’t building for a captive audience; I was building for users with endless choices at their fingertips, users who could walk away at any moment. Feedback was immediate, direct, and often public, creating a pressure that was as exhilarating as it was relentless. But in B2C, the relationship was also somewhat indirect. Feedback came in through reviews, ratings, or analytics – aggregated data that guided our decisions. Unlike B2B or internal roles, I wasn’t interacting with individual users directly, and I had to rely on broad trends rather than personal relationships to shape the product.
B2B: Getting Personal with Business Clients
After navigating the consumer world, I moved into B2B Product Management, where the focus shifted significantly. Here, I was no longer dealing with a wide array of anonymous consumers but rather a select group of business clients with specific goals. My role became more personal, requiring me to understand and align with each client’s unique business needs. Every conversation in B2B was about building trust and delivering value that justified the client’s investment. Unlike in B2C, where feedback was often an aggregated view, B2B feedback came directly from clients in meetings and check-ins. These interactions had a different kind of weight because each client’s satisfaction was tied to measurable business outcomes. Here, there was little room for experimentation; clients expected predictability, transparency, and tangible ROI. Success wasn’t about user delight as much as it was about ensuring our solution became a valuable part of their business operations. But even in B2B, the relationship had its limits, often defined by the terms of the contract. Once a solution was deployed and accepted, the frequency of direct interaction tapered off, and any ongoing feedback or updates followed a more structured process.
Internal PM: Working Side-by-Side with My “Customers”
Then came my role as an internal Product Manager, focusing on solutions for colleagues within the company. This shift introduced a whole new layer of complexity and interdependence. Unlike in B2B, where interactions were regular but bounded, and B2C, where interactions were broad but indirect, being an internal PM meant I was in continuous, close collaboration with my “customers.” My users were my colleagues – people I saw daily, who had direct access to me and weren’t afraid to voice their needs, concerns, or frustrations in real time. Unlike external customers, internal users had a direct line to me, which created an ongoing loop of feedback that wasn’t just immediate; it could even sometimes become personal. This dynamic required an entirely different approach to handling feedback, as it wasn’t just about improving the product but also maintaining strong, respectful relationships with those I worked alongside every day.
Managing Expectations: A New Twist in Each Role
One of the first lessons I learned as an internal PM was about managing expectations. Internal teams often see the product team as a resource at their disposal, expecting quick turnarounds on features they believe will make their jobs easier. In B2C, the pressure to deliver was certainly present, but the demands were dispersed and driven by data, not individual expectations. In B2B, the pressure was to meet client requirements within agreed timelines. But in an internal role, the pressure was different – it was more immediate, more constant. I had to be transparent and set boundaries in a way that didn’t alienate colleagues. Here, managing expectations became a daily challenge, balancing the need for quick wins with the reality of limited resources and technical constraints. And unlike in B2C or B2B, I found myself frequently needing to explain why certain requests weren’t feasible or why they might not be worth the effort.
Practicality: Where Creativity Meets Real-World Needs
Practicality was another area where internal Product Management set itself apart. In B2C, the market is highly competitive, and with alternative solutions just a tap away, user experience is crucial; users expect products that not only work but are intuitive, visually appealing, and engaging. There’s more room for creativity here – adding delightful features that enhance the experience can set a product apart, and often, a polished, enjoyable interface is as important as functionality itself.
In B2B, the focus is still on usability, and clients appreciate a well-designed interface, but features generally need to directly support specific business goals. If the product solves the problem effectively, that’s often enough. Sophisticated capabilities or a polished interface can be valuable additions but aren’t necessarily expected to the same extent as in B2C. That said, bringing a clunky, outdated user interface wouldn’t go over well in any setting – B2B clients and internal teams still need solutions that feel modern, accessible, and user-friendly.
However, in an internal environment, the demand for practicality is relentless. Internal teams aren’t looking for cutting-edge features or fancy extras; they want tools that are simple, reliable, and save them time. This forced me to rethink my approach entirely, realizing that, in an internal environment, “good enough” is often better than “innovative.”
The “Beast” of Internal Product Management: Navigating Company Politics
And then there’s what some might call the “beast” of internal Product Management: navigating company politics. In B2C, my focus was the user experience, and in B2B, it was about meeting client needs within agreed terms. But in an internal role, the landscape is layered with departmental interests, each with its own priorities. Unlike external products, which serve a singular user group, internal products often span multiple departments with different objectives. You sometimes even find yourself unintentionally competing with other internal Product Teams if they add a feature similar to your core offering. In these moments, it becomes crucial to coordinate quickly to avoid redundancy and explore potential synergies.
Saying “no” or “not now” became a diplomatic exercise, requiring me to communicate how each decision served the company’s broader strategy. This internal negotiation wasn’t something I had faced so intensely in either B2C or B2B; it was a uniquely internal challenge that required both tact and strategic foresight.
Reflecting on my Journey
Looking back, each role peeled back a new layer of what it means to be a Product Manager. Internal PM roles taught me pragmatism and adaptability within the organization. B2B work emphasized the value of partnership, negotiation, and delivering measurable business value. And B2C? That was all about empathy, design, and creating something that resonated on a human level. Each transition challenged and shaped me, building a more versatile and adaptable skill set that, I believe, has made me a stronger AI Product Manager today.
And these are just some of the differences. There’s an entire set of nuances and shifts that come into play – all because the customer type changes. It’s fascinating how a single variable, the type of customer, can completely redefine the way you approach Product Management. It’s an important differentiator, yet one I’ve found is rarely discussed in depth.
So, if I could start over and choose only one of these paths, where would I begin? It’s a tough question – maybe even impossible to answer because each journey was essential, each experience irreplaceable in building the PM I am today.
But maybe you can help me decide: which path would you choose?
Besides that, do you now get why “If the solution calls for a specific skill set, the customer calls for a specific mindset”?
JBK 🕊️
P.S. If you’ve found my posts valuable, consider supporting my work. While I’m not accepting payments right now, you can help by sharing, liking, and commenting here or on my LinkedIn posts. This helps me reach more people on this journey, and your feedback is invaluable for improving the content. Thank you for being part of this community ❤️.
From the outset, your initial statement resonated with me, but as I delved into the description, I uncovered nuances about the audience that I had experienced but never considered in such a structured manner. EXCELLENT post! Thank you for sharing.