One of the questions that gets escalated to me most often these days is some permutation of, “What is the difference between product management and interaction design?”   It is particularly hard to answer questions like “where does one end and the other begin?”  These are not simple questions to answer because the roles do have some overlap and it is important that both of these roles collaborate closely in any organization.

Before I answer the question, I should say two quick things:

• My goal, as a leader, is two-fold when it comes to defining roles.  First, I aim to preserve a sense of ownership between the various members of the team developing a new product.  Second, I want to ensure that there is a clear system for collaboration among the team.
• It’s important to note that my answer to this tough question is a work in progress.  I am trying to figure it all out as I go, so bear with me.

What is product management all about?

To me, product management is really about two things:  1) defining and assessing the market opportunity.  2) working with the cross-functional product development team to discover a solution.  Here are some of the core activities that come to mind:

• Assessment: Whatever product you are working on, you are typically addressing some sort of gap or market opportunity.  In this case, the first goal is to figure out if the project is even worth pursuing.  It needs to be quantified and thought through, along with the overarching product strategy, to see if it is a good fit.
• Stakeholder management: There are a variety of stakeholders, both inside and outside the organization, that should be brought to the table when working on a product.  The PM is responsible for bringing these stakeholders to the table and understand what a successful product really is from their perspective.  Another part of stakeholder management is keeping folks up-to-date with the evolution of the product, since it may effect them.
• Building requirements: As the product is being discovered by the PM, and potential solutions present themselves, requirements need to be built.  The PM is the driver of this process.  Good requirements outline the core opportunity, and what a success looks like for addressing the opportunity.
• Validating solutions: As solutions get designed and built, the PM should be validating those solutions against the initial opportunity assessment and the product requirements.

Of course, the job of a PM on a good product team becomes very iterative.  Few, if any, good products are developed linearly.  Instead, new information and insight is yielded throughout the process, which drives updated requirements and solution-validations.

What is interaction design all about?

Interaction design (IXD) is a partner organization to the product organization, much like engineering is.  (More on this later…)  An IXD’s goal is to build something that is usable and valuable for the end-user.  A good IXD gets at this goal in two ways: 1) getting to know and understand the user 2) thinking through (in detail) and ideating potential experiences for the user.  Some of the core activities that come to mind:

• Understanding the user. The IXD has many stakeholders to think about, but none is more important than the user herself.  This can be done many ways, but typically takes the form of surveys, focus groups, and competitive analysis.  Often times, these activities are taken on by a peer to the IXD known as the user experience researcher (UXR).  More on this later, also.
• Thinking through the details. The Product Requirements map out high-level definitions of the problem landscape and what success looks like.  The IXD is taking this to the next level of detail, where many unanswered questions still exist.  The IXD is the person driving these answers.
• Conceptualize solutions. While high-level requirements can typically be written out in sentences in something like a product requirements document (PRD), more detailed solutions need more than just words.  The IXD is the person who is conceptualizing detailed solutions in a higher fidelity way that can be used to gather feedback from stakeholders and users alike.  Typically, these take the form of storyboards, screen flows, wireframes, and prototypes.

The interaction designer has a lot of work cut out for herself.  The key to doing a solid job is to have the time needed to do the right kinds of discovery as well as being iterative in conceptualizing solutions.  Again, learning about the customer is not a linear process.  Often times, new information and insight is brought to light in the middle of the design cycle.  This is why being agile and iterating on design is so important.

Both IXDs and PMs have to collaborate to make it work

It doesn’t matter how detailed we are about dividing up roles and responsibilities between IXDs and PMs.  At the end of the day, they both have a lot of shared responsibilities.  They both need to be connected to customers and stakeholders.  They both need to be iterative and work with end-users to understand if needs are actually being met.  They both need to be willing to change their deliverables (whether they are product requirements or prototypes) based on new insights that are brought to light.

Product management and interaction design is a close collaboration no matter how you slice it.  I view PM as a bit higher-altitude when it comes to defining a solution.  IXD is closer to the ground, and has much more of a hand in defining how the experience comes together.  While both groups need to work to respect boundaries and allow the other group to do its job, they both need to work hard to be on the same page.  If PM and IXD cannot work together in harmony, then you are destined to have a product that just doesn’t feel right.