Who should lead Product?

Jared Spool published this article that suggests putting UX Research at the helm of a product organization, and there have been a few counterposts since. This one popped up in my feed today and had some fair points, but I feel Greg Prickril missed a bit of context. I thought I'd share some perspective on why Jared's suggestion might be worth considering, at least in the Fortune 500 enterprise landscape where I have played most of my career.

Initial note: This article speaks in generalities - many people have self-trained, learned from Agile-native organizations, or had great change management and training programs which did instill the right skills and leadership cultures. This isn't meant to suggest there is no strong Product talent in the enterprisee - it's a statement of what I have seen across many orgs. This is also not an attack on or condemnation of those this does describe. Your current skills and growth trajectories are a function of your environment - you aren't to be blamed for how you are incentivized to work.

In the enterprise, many organizations have spent the last 5-10 years taking on some sort of Agile Transformation. Intending to be stewards of their employees' careers (and out of practical necessity - it's hard to rotate hundreds of workforce out and into a company in a short period of time), many people who historically held Business Analyst roles were knighted Product Owner or Product Manager and trained on Scrum (a way of working). What they weren't often trained on (or incentivized for) was product thinking: understanding business and user needs, balancing those against technical complexity, building value hypotheses for features and business cases for new solutions, and measuring impact and reporting on outcomes of work completed.

This was exacerbated as many Project Managers were similarly converted to Scrum Masters with a limited understanding of what good product management looked like. These people who were expected to coach teams on product development best practices often focused on what they already knew - managing developers (albeit through new means like standups, retros, and blocker removal) - rather than helping improve the "Agile how" (DevOps, Product coaching, etc).

Then leaders in these orgs (to whom Agile was new) were mostly only ever exposed to this type of product management. They saw the role evolve more like a BA that elicits business desires, needs, and requirements and manages stakeholders through meetings and politics (much like a BA may have in the past). They rewarded those best at this and promoted them, creating cycles of cementing the wrong practices.

Some orgs have leaders who know different, and build up the right skills and culture. In these orgs, Product Management is great to sit at the top. But many orgs look like what I just described; in these companies Product doesn't think about experiments, balancing business goals against tech complexity, or seeking to understand (then socializing) how user needs can impact business goals.

Now let's talk about design - UX has historically had to fight tooth and nail for a seat at the business table. That didn't change in initial Agile Transformations, because although UX is inherently an iterative, Agile function, it wasn't explicitly mentioned in the Scrum guide so many Scrum Masters didnt know what to do with UX. To earn thier seat at the table, UX was forced to understand business and articulate the economic benefits of their work, and to understand and advocate for how UX should fit into the Agile product development lifecycle. UX had to collaborate closely with tech teams to understand feasibility, and make tradeoffs on design decisions based on constraints provided. Over time, it became common for UX to fill the gap left by underskilled product owners in organizations around measurement, strategy, and storytelling just by nature of trying to go above and beyond to demonstrate their value to the organization.

Greg suggested in his video that putting UX research at the top would make them something other than UX research - they'd be doing business management. At higher levels, the same can be said about Product - you end up doing less Product Management at the top, instead spending you time guiding and supporting the Product team - in all its' capacities - in how to optimize value in Product investments. You might make decisions on what to invest in, but to do so you ought to be evaluating cases for value and their alignment to your organizational goals, and helping influence which product goals are worth chasing (both in terms of feasibility and value of impact) in consideration of your organizational mission and objectives. It relies on a good understanding of user needs and desires, business understanding, facilitation, and coaching. Both product and UX could lean into new skills and take that on.

But I think that is the underlying point Jared is guiding us toward. In many scenarios, it makes more sense to push people with backgrounds in UX and research to lead these organizations than those with backgrounds in product only, just because the barrier to learning new skills and supporting the cultural elements needed may be easier for UX. In many scenarios, at least within homegrown enterprise agile/product orgs, UX may be better equipped to shift into Product leadership and drive the desired outcomes than the other way around.

One caveat I would want to leave readers with - I know many UX researchers, product designers, and design strategists who can be myopically focused on user needs. If you can't translate user needs into business value in the context of your organizational mission, it doesn't mean those needs aren't worth pursuing, but it does mean this business may not be the best place to solve them (or that the mission needs redefinition - but that is a big ask to make if you are not already in a very senior role in the organization). If you can't code switch and consider both user needs and business needs, you aren't the type of UX researcher I believe should be running Product from the top.