Tag Archives: Product manager

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

Posted on by

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.

We are Product Managers

Posted on by

When I joined Twitter, one of my key responsibilities was building the product management organization to keep pace with the growth of our engineering and design teams and to lay the foundation for scalable product development going forward.  In less than a year, we more than tripled the size of the team (total company headcount grew even faster).  As you might expect with that kind of employee growth, there were many questions about how various functions should work together, especially the product development-oriented functions of engineering, design and product management.  At Twitter, we evangelized an operating model where project teams were constructed with product, engineering and design leads, each representing three equal legs of the product development stool (with other functions also providing input and feedback throughout the development process).  However, as the teams began working under this model, it became clear that each function was struggling with defining its role relative to the roles of other functions.  Who should be involved in what conversations?  Where were the lines drawn?  Who was the “decider”?  And like many companies, we were faced with the oft-asked existential questions of “Is product management needed?” and “What role does product management play in product development?”

Given all of these questions, my product team needed a reminder about why they were all there as individuals and as a product management function.  Fortunately, the web offers many excellent write-ups and conversations about what it means to be a great product manager.  But I also wanted to share my personal views on product management, developed through years of product success and failure, particularly because I believe that product management is more an attitude than a set of skills.

Below is the description of the product manager’s mentality that I shared with the team at Twitter.  I was told that it proved helpful to many of them (hopefully it still is!) as they worked with their engineering and design peers and I’m hopeful that it will be equally useful to product people (current and aspiring) who are trying to do the difficult but incredibly gratifying job of product management.  In one way or another, it’s a job I’ll always have and love.

—

As Product Managers, we are the CEOs of our products.  We love products.  We focus first on delivering value to our users.  We know who we are building for and what we are building.  We know why we are building it and where we are building to long term.  We communicate the who, what, why and where clearly, concisely and frequently.  We communicate with anyone and everyone who is interested, but most importantly to our teams.  We let our teams determine how to build.

We pursue excellence by thinking bigger and bolder than is comfortable.  We don’t settle for good enough.  We choose right over easy.  We choose simplicity over complexity.  We don’t make excuses.  We take responsibility.  We are tirelessly curious.  We respect our competitors, not fear them.  We understand why we win and what we must do to keep winning.

We lead by example.  We succeed by making others successful.  We listen first and make certain that others feel that they’ve been heard.  We pursue diverse opinions.  We rally our teams behind a vision that yields passion and commitment.  We value and foster strong team relationships.

We are determined and positive.  We use words and take actions that embody a can-do attitude.  We trust others to do their jobs well but we verify that they are done right.  We are honest, direct and empathetic.  We adjust to our audiences and situations.  We are decisive when needed, but always collaborative.

We know the definition of success.  We hold ourselves and our teams accountable to it.  We set the bar high.  We provide focus through prioritization.  We increase quality through iteration.  We don’t like surprises, so we prepare for them.  We pay attention to the details because we care.  We fill in the gaps and do whatever it takes to get the job done.  We don’t wait to be told what to do.  We leverage data but aren’t slaves to it.  We are honest.  We seek the truth.

We take time to reflect.  We don’t fear failure.  We strive to improve.

We are Product Managers.

—

Thanks to Hunter Walk and Josh Elman for reading drafts of this post.