Product management and Design can look very similar from afar. Both disciplines are interested in the process of building products that satisfy their users and customers, and unsurprisingly, this results in day-to-day workflows that feel analogous. As an exercise, let me jot down a non-exhaustive list of work items here. Dear reader, please tell me which belongs to who.
Roles and responsibilities between Product and Design
It’s not that easy, is it? With a few exceptions, for most of the work here you can find organizations where they are performed by different roles1.
Having spent significant time in both, very often the who-ends-up-doing-what reflect the evolution of their organizations. The Product, Engineering, and Design triad structure started solidifying around the early 2010s. Google’s success launched the popularity of the Product function2, which traces its roots to Microsoft’s Program Management. The swift ascension of iPhones brought along Design’s stature with them. Recall the days when no one can shut up about how Design Thinking is going to change the world.
Around that time, technology teams began to adopt this organizational structure en masse. Companies and teams wanted to hire and emulate the processes that made these tech companies successful. The influx of tech veterans and the popularity of thought leadership disseminated the various school of ideas throughout the industry. Leaders with Human-Computer Interaction (HCI) backgrounds started building robust research programs. Leaders growing up with A/B testing and metrics driven development started to build new data-driven organizations3. Both Product and Design teams evolved in the direction of better serving their users, and the specific mix of methods and process reflects the zeitgeist and their principals who import them.
That said, there is one crucial difference between Product and Design. At the very core, Product Management is a business function; Design is a technical capability. The Product role is not separable from from the business itself by definition, especially those that profit through the selling of said products. This reciprocal relationship provides the contrast. The success of a product leader must be dutifully tied to the success of the business. What the product manager cares about need to reflect the priorities of the business writ large. A common way that product management teams are organized – retention, acquisition, feature performance – reflect this dependence. These are all factors that directly affects business’s key metrics and bottom line.
This is not to say that Design does not serve business needs. It must, of course. However, Design practitioners are not often business savants. The discipline itself comes from an academic legacy of HCI, visual design, psychology, computer science, and various other humanities disciplines and the practice reflects that. The first order of concern for the Designer is the User. The Best Possible Design is one that best serves the needs of the User. The tools and methods that the Designer wields points in this direction as well. This is not dissimilar to the concerns of Engineering teams around good coding practices, software maintainability, and so on.
A good product is finding the best business, design, and engineering balance that best satisfies the user and customer
Many will argue that the Best Possible Design should be perfectly aligned to the needs of the business. This may sound true in the abstract, but Design is not free. It may require time to fully realize. It may make the product more expensive to produce. It may require forgoing profits. Businesses may not be able or willing to pay its price. We see this tradeoff in action all the time: subpar experiences in hastily built products and worse of all, dark patterns because they know they can get away with them. After all, the pure business rationale is not to make the best version of the product, but the most money within their constraints4. Sometimes, but not always, this happen to be shipping the best product on the market.
For that reason, people with Design backgrounds make for fantastic Product Managers. As a senior Product leader once told me, “all good product managers are good interaction designers”. His reasoning was straightforward: for a product manager to be successful, they have to have a vision of how the product makes the user successful as well, and can thus lead the team in defining and pursuing that product vision. The Design training and background provides a Product Manager candidate with that skill set while working to the demand of the business. In the end, there are very few durable strategies that make for good business other than making sure the customer is happy.
This is not to say that Design and Product are fungible. On the contrary, both these fields are young and their paths will continue to evolve. I forsee Product management continuing on its trajectory towards mastering business oriented outcomes. And for Design to find its seat at the table, the discipline will have to take on additional business burden while maintaining the pursuit of good design. Ultimately, these are roles within a capitalism context that we are talking about. The Product, Engineering and Design trinity is a business construct, and its relevance will continue as long as the times are good.
-
It may be useful to be a bit more precise here. This is of course most applicable when the product in question is a screen-based software. We would not expect the Product Manager to be able to produce a pixel perfect Figma file, but a lot of times there are other methods that can achieve business results which is close enough. One can argue that this assertion will not hold for non-screen based products and services. This may be true, but Design as a discipline is broad as well, and adjacent specialties such as Service Design might provide such equivalency. ↩
-
In practice, Product Management across different organizations can look vastly different, and much more varied than how Design is practiced. A detailed discussion of Product Management is out of scope for this article. For the sake of this discussion let’s assume a more purist form as dictated by books like Inspired and Escaping the Build Trap. ↩
-
The examples above are distinction without differentiation. While the tactics are different, the goal is to get to customer understanding. ↩
-
This does not have to be necessarily true, but is more often true than not. ↩