Shared Context in Product Development and the How of “Why”

Product development doesn’t come without its fair share of strong points of view, impassioned debates and occasional yelling.  These disagreements don’t result from team members wanting to do the wrong thing.  Instead, arguments about priorities, features and timeframes are typically caused by the lack of shared context about “why”.  Whether you’re a product manager, engineer or designer, if you’re the “decider”, your job is to make sure that everyone on the team has a clear understanding about why the goals, priorities and decisions are what they are from the very beginning of your work together.  Without shared context there can’t be shared purpose, shared risk or shared outcomes.  Here are some tips for making sure you and your team are operating from the same base knowledge and set of assumptions.

Don’t assume.  Even if you think that everyone knows the priorities, has been looking at the same data or been privy to the same conversations, don’t assume that the team has shared context.  Leaving it to each person to interpret conversations, make sense of data and draw their own conclusions inherently leads to misalignment and lack of buy-in regarding decisions.  Not surprisingly, as teams begin to work, the absence of shared context has severe costs – lost time and productivity, finger pointing and discouraged team members.

Write it down.  If you force yourself to write down the “Why” behind decisions that are being made, it will both clarify and improve your thinking.  You’ll be able to understand how others might react to the explanation of why and what issues they may have.  Sharing that written explanation of why with your team will allow all of you to have a common language with which to talk about problems, solutions and goals.  It will also provide a reference document that can be used by the team after the why has been discussed and you’re all no longer in the same room.

Repeat early and often.  The why is not something to be shared once and then be forgotten.  Talking about why at the very earliest points of product development lays the foundation for close collaboration and tight alignment.  Repeating the why during each step of the development process ensures that the team continues to have a common understanding and shared goals and allows the group to reaffirm or change the why as new data, requests and issues emerge.

Seek understanding, not agreement.  Assuming it’s clear that you’re the “decider” and that you’ve already gathered input from the team, the purpose of sharing the why is to help everyone understand the reasons for the decisions that are being made, not to have everyone agree that those are the right decisions.  That said, team members need to feel that their points of view were incorporated into the thinking that led to the why (writing it down helps provide evidence of being heard!).  The right outcome is to have a collaboration amongst team members based on shared context, not to be consensus-driven.

While establishing the why is critical in product development, it’s an equally important behavior in nearly all professional and personal contexts.  Next time you’re working on a project with your team, friends or spouse think about whether there is shared context and how setting that context might help you work together more effectively.

2 thoughts on “Shared Context in Product Development and the How of “Why”

  1. Pingback: Know what you’ve learned, not what you’ve done | Venture Generated Content

  2. Pingback: What makes a great product manager? | Venture Generated Content

Leave a comment