I’m just guessing here, but I’d say over the years I’ve seen at least one hundred different definitions of the product role (i.e. product manager/product owner). I’m pretty sure that anyone reading this would have seen at least several.
Part of the problem is that there are different operating models that require different responsibilities and skills from the person playing the product role.
And part of the problem is that people seem to want a short catch phrase or pithy description that captures what’s important. I don’t think a simple phrase can capture the nuances of any complex role, but I will say that what the person chooses to emphasize can be very telling.
Asking a product person how they define their role can serve as a form of Rorschach test.
I’ve asked that question during interviews for literally decades. I don’t view this as a right or wrong question, but the candidate’s answer reveals so much about the product model they’ve worked in, why they think the role exists, and what that role contributes to a product team.
I’ve personally argued for a few different definitions over the years, each version trying to emphasize something I consider essential and distinct from the other roles on a product team.
But sometimes we can be too close to a topic, and it can be hard to see the forest for the trees.
Just recently I read an article that was not even attempting to define the product role, and barely even mentioned the term “product,” yet it provided one of the best descriptions of the responsibilities and skills of a product manager in the AI era that I have ever seen.
The author is the technology industry analyst Benedict Evans. I’ve mentioned Ben’s writing in the past as he’s one of my favorite analysts. He’s not a product person per se, but he is product adjacent, and he does know the broader tech industry exceptionally well.
The article is called “Most People Aren’t Tool Builders”, but it’s behind his paywall so unless you’re a subscriber you probably won’t be able to read it. However, he just recently discussed this article in a podcast that’s available outside the paywall. It’s twenty minutes very well spent, and I’d strongly encourage you to listen to this.
Ben’s article and podcast are trying to explain why it is that just because customers may now have access to the tools and technology to create their own solutions (whether that’s vibe-coding an application, or automating their workflows with agents, or anything else), they are very unlikely to even try, and for those that do, they are unlikely to succeed.
In the process of explaining his argument, Ben contrasts the skills and mindset of typical users and customers, with the skills and mindset of someone that’s strong at creating new tools or solutions.
I’ll address Ben’s main point at the end of this article, but I was struck by how good his description of the strong product role was. I wanted to share Ben’s implicit definition of the product role, and help map the language he is using to the terms my readers will recognize.
Ben describes three distinct skills of effective product people:
First, lots of people recognize pain, and maybe have ideas for addressing that pain, but not everyone is able to see the more general problem to be solved behind that pain or idea. I have been doing this for so long (several decades) that it’s second nature for me, and it’s easy to forget that not everyone is able to spot these opportunities.
Second, once a problem worth solving has been recognized, you need to have the skills to discover an effective solution to that problem. In Ben’s words, “People that are really good at using the tool are not the same people as those that are really good at creating the tool” (emphasis mine). He sums up this point well with an example: “You have to know a lot about sales to make good sales software, but being good at sales does not make you good at making sales software.”
Third, beyond discovering a strong solution that meets the needs of your customer, you also need to have the depth and breadth of understanding of your company to discover a solution that also works for your business. Realize that most solutions will touch people across your company – sales, marketing, finance, compliance, legal and more. The solution may depend on regulated data, or may need to integrate with legacy systems, or may need to be incorporated into many different workflows across the business.
To map these points to concepts product people will recognize, Ben’s first point is referring to problem discovery, his second point is addressing the value risk in solution discovery, and his third point is addressing the viability risk of solution discovery.
None of these three skills is necessarily exclusive to product people, but I think it’s fair to say that it’s pretty rare to find these skills in most people.
Reading Ben’s words also made me realize that I had yet again made the mistake of assuming more people thought like product people.
About a year ago I published one of our most popular articles, The Era of the Product Creator in which I celebrated the arrival of these new tools that make the product creation process – discovery and delivery – so much better. I said that I was excited to see many more people become strong product creators.
That’s been maybe a little bit true, but not anywhere near what I had hoped for.
Ben is arguing that the issue isn’t the tools, it’s how the product person thinks and how well they understand the craft of product.
There are of course many different ways to frame the responsibilities of a strong product person, but whether you choose to use his framing or not, the essential skills remain.
These skills are what your product team is depending on you for.
Back to the original point of Ben’s article, I’m not the only one making the mistake of confusing ourselves with our customers.
So many product people today are thinking that their customers are going to use AI technologies the way that they are. But as Ben explains: “Most people and companies aren’t tool builders.”
He goes on to say: “AI makes it easy for anyone to build tools to automate their work… except most people and most companies aren’t tool-builders, don’t think like that, and can’t and won’t do that. This is why software companies and consultants exist – AI changes the thresholds but not the problem.”
“But the core of this is that giving everyone a new way to make tools doesn’t mean that everyone will make tools. Writing the code isn’t the hard part, and making the tool isn’t the hard part – the hard part is knowing that it should exist, and knowing how it should exist, and that’s a different person.”
Ben’s article serves as a great reminder of why the product role is so essential, and is likely to remain essential.