I was having a conversation a couple of weeks ago with a senior, seasoned product leader about the state of Product and how the skills and approaches will continue to evolve. What struck me as interesting was not the idea that AI has greatly increased the velocity of Product work (because it obviously has), but that there are still two primary camps of product folks: those who believe that the role of product is to identify user problems and shepherd experts to address those problems, and those who believe that the role of product is to identify user problems and work alongside those experts to solve those problems. AI tools have minimized the cost of knowing and building, and it's increasingly difficult to defend the shepherd-only approach.

Some of this difference is surely due to organization size. A director at a 5,000-person SaaS company is inevitably going to have more resources at their disposal, and therefore should be focused on team organization, process management, and vision, since execution is appropriately delegated down to teams and individuals. A 40-person company with a three-person product team is different; everyone should contribute. However, I recall having essentially this exact same conversation with a peer when I was leading multiple product teams within an organization, at a similar org size with similar resources. When discussing some cross-functional work between our teams, I asked a technical question about how a certain set of features were built on the backend so I could help my teams understand the shape of our solution. His response was essentially that he had no idea how it worked and didn't care; he just wanted to solve the user's problems. I was floored at the time, and while I've had similar conversations many times since, I don't think that deeply understanding the user's needs AND how those needs are resolved are in conflict.

I would even argue that the latter helps the former; by having at least a reasonable technical understanding of the product, you can expedite the product-design-engineering loop by speaking everyone's language more effectively, which is a primary value of good product management regardless. It also builds credibility with engineering and design: if you can show that you understand their roles, challenges, and approaches, you build trust. And when those challenges cause issues with delivery, you can better empathize with why (and hopefully, help them resolve those issues). There is commonly an argument that knowing too much about the codebase leads PMs to dictate engineering solutions. I think that's a fair concern, but not dictating is a function of discipline, not knowledge.

I readily admit to my own bias in this perspective as well. I got into product management because I love building things and could do it for a living. Identifying a highly complex and nuanced problem, working to propose, validate, and deliver solutions brings me immense joy and satisfaction.

AI tools have changed the expectations radically. Sometimes working alongside means being in the code itself to create prototypes; sometimes it just means spending an afternoon with Claude to get a good mental model. A PM can now put together a prototype in a couple of hours that helps them explore a feature request or communicate a vision to an engineering team at a fidelity that was previously economically infeasible. An executive at one of BettrData's clients was suggesting that they wanted to roll out the BettrData platform to some of their own clients, but that those users were decidedly non-technical, and he was worried that it could be too complex of a system for some. Literally the next day I walked that stakeholder through a prototype I'd built, which had a shorter flow and far fewer options, since those settings are handled on the backend by admins. It not only allayed those fears but provided a great opportunity for feedback and further problem refinement.

I am not suggesting that every product person at every level should have engineer-level understanding of your codebase. That would be a waste of focus. But I do think product folks at every level should have an appropriate understanding of how your product(s) work. To use an analogy, I think that if your car stops working, it's helpful to know whether the wheel fell off or the engine exploded or if you just left the key in the house. With AI, it's like your sleepless new roommate is a mechanic. You'll still take the car to the shop for a new transmission, but there's no excuse anymore for not knowing what broke—or for not trying to fix it yourself before you go.