{"id":23231,"date":"2026-08-10T12:49:18","date_gmt":"2026-08-10T12:49:18","guid":{"rendered":"https:\/\/scannn.com\/a-fresh-definition-of-the-product-role\/"},"modified":"2026-08-10T12:49:18","modified_gmt":"2026-08-10T12:49:18","slug":"a-fresh-definition-of-the-product-role","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/a-fresh-definition-of-the-product-role\/","title":{"rendered":"A Fresh Definition of The Product Role"},"content":{"rendered":"\n
\n

I\u2019m just guessing here, but I\u2019d say over the years I\u2019ve seen at least one hundred different definitions of the product role (i.e. product manager\/product owner).\u00a0 I\u2019m pretty sure that anyone reading this would have seen at least several.<\/p>\n

Part of the problem is that there are different operating models that require different responsibilities and skills from the person playing the product role.<\/p>\n

And part of the problem is that people seem to want a short catch phrase or pithy description that captures what\u2019s important.\u00a0 I don\u2019t 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.<\/p>\n

Asking a product person how they define their role can serve as a form of Rorschach test<\/a>.\u00a0<\/p>\n

I\u2019ve asked that question during interviews for literally decades.\u00a0 I don\u2019t view this as a right or wrong question, but the candidate\u2019s answer reveals so much about the product model they\u2019ve worked in, why they think the role exists, and what that role contributes to a product team.<\/p>\n

I\u2019ve personally argued for a few different definitions over the years, each version<\/a> trying to emphasize something I consider essential and distinct from the other roles on a product team.<\/p>\n

But sometimes we can be too close to a topic, and it can be hard to see the forest for the trees.<\/p>\n

Just recently I read an article that was not even attempting to define the product role, and barely even mentioned the term \u201cproduct,\u201d 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.<\/p>\n

The author is the technology industry analyst Benedict Evans<\/a>.\u00a0 I\u2019ve mentioned Ben\u2019s writing in the past as he\u2019s one of my favorite analysts<\/a>.\u00a0 He\u2019s not a product person per se, but he is product adjacent, and he does know the broader tech industry exceptionally well.<\/p>\n

The article is called \u201cMost People Aren\u2019t Tool Builders<\/a>\u201d, but it\u2019s behind his paywall so unless you\u2019re a subscriber you probably won\u2019t be able to read it.\u00a0 However, he just recently discussed this article in a podcast<\/a> that\u2019s available outside the paywall.\u00a0 It\u2019s twenty minutes very well spent, and I\u2019d strongly encourage you to listen to this.<\/p>\n

Ben\u2019s 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\u2019s 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<\/em>.<\/p>\n

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\u2019s strong at creating new tools or solutions.<\/p>\n

I\u2019ll address Ben\u2019s main point at the end of this article, but I was struck by how good his description of the strong product role was.\u00a0 I wanted to share Ben\u2019s implicit definition of the product role, and help map the language he is using to the terms my readers will recognize.<\/p>\n

Ben describes three distinct skills of effective product people:<\/p>\n

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.\u00a0 I have been doing this for so long (several decades) that it\u2019s second nature for me, and it\u2019s easy to forget that not everyone is able to spot these opportunities.<\/p>\n

Second, once a problem worth solving has been recognized, you need to have the skills to discover an effective solution to that problem.\u00a0 In Ben\u2019s words, \u201cPeople that are really good at using<\/em> the tool are not the same people as those that are really good at creating<\/em> the tool\u201d (emphasis mine).\u00a0 He sums up this point well with an example:\u00a0 \u201cYou 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.\u201d<\/p>\n

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.\u00a0 Realize that most solutions will touch people across your company \u2013 sales, marketing, finance, compliance, legal and more.\u00a0 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.<\/p>\n

To map these points to concepts product people will recognize, Ben\u2019s first point is referring to problem discovery<\/a>, his second point is addressing the value<\/em> risk<\/a> in solution discovery, and his third point is addressing the viability<\/em> risk<\/a> of solution discovery.<\/p>\n

None of these three skills is necessarily exclusive to product people, but I think it\u2019s fair to say that it\u2019s pretty rare to find these skills in most people.<\/p>\n

Reading Ben\u2019s words also made me realize that I had yet again made the mistake of assuming more people thought like product people.\u00a0<\/p>\n

About a year ago I published one of our most popular articles, The Era of the Product Creator<\/a> in which I celebrated the arrival of these new tools that make the product creation process \u2013 discovery and delivery \u2013 so much better.\u00a0 I said that I was excited to see many more people become strong product creators.\u00a0\u00a0<\/p>\n

That\u2019s been maybe a little bit true, but not anywhere near what I had hoped for.<\/p>\n

Ben is arguing that the issue isn\u2019t the tools, it\u2019s how the product person thinks and how well they understand the craft of product.<\/p>\n

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.\u00a0\u00a0<\/p>\n

These skills are what your product team is depending on you for.<\/p>\n

Back to the original point of Ben\u2019s article, I\u2019m not the only one making the mistake of confusing ourselves with our customers.<\/p>\n

So many product people today are thinking that their customers are going to use AI technologies the way that they are.\u00a0 But as Ben explains: \u201cMost people and companies aren\u2019t tool builders.\u201d<\/p>\n

He goes on to say: \u201cAI makes it easy for anyone to build tools to automate their work\u2026 except most people and most companies aren\u2019t tool-builders, don\u2019t think like that, and can\u2019t and won\u2019t do that<\/em>. This is why software companies and consultants exist \u2013 AI changes the thresholds but not the problem.<\/em>\u201d<\/p>\n

\u201cBut the core of this is that giving everyone a new way to make tools doesn\u2019t mean that everyone will make tools. Writing the code isn\u2019t the hard part, and making the tool isn\u2019t the hard part \u2013 the hard part is knowing that<\/em> it should exist, and knowing how<\/em> it should exist, and that\u2019s a different person.\u201d<\/p>\n

Ben\u2019s article serves as a great reminder of why the product role is so essential, and is likely to remain essential.<\/p>\n<\/p><\/div>\n

Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

I\u2019m just guessing here, but I\u2019d say over the years I\u2019ve seen at least one hundred different definitions of the product role (i.e. product manager\/product owner).\u00a0 I\u2019m 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 […]<\/p>\n","protected":false},"author":16,"featured_media":23232,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[143],"tags":[],"class_list":["post-23231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"_links":{"self":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/comments?post=23231"}],"version-history":[{"count":0,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media\/23232"}],"wp:attachment":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media?parent=23231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/categories?post=23231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/tags?post=23231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}