“So, what do you think?” — says the Product Manager after a product strategy presentation to his team
“Yeah, sounds good!” — says the team while thinking “whatever, don’t have enough context to discuss this anyway”
This conversation may sound familiar to many Product Teams. In this story, I’ll explore why Product Managers should prioritize sharing context with their team, how to get started and what early impact signs look like.
Taking a step back
Companies are born to solve problems that customers value to the point that they are willing to pay for them to be solved. In order to find and solve those customer problems faster, modern organizations evolved into a hybrid org. design where some functions remained centralized (sales, customer support, finance, legal, etc.) and product teams became cross-functional decentralized teams that are empowered to decide what to work on to fulfill their mission.
This trend created the Product Manager role whose main job is to make sure the product team is working on the right thing. The job includes absorbing qualitative and quantitative inputs from customers, users, the market, the various centralized teams, the leadership team as well as other product teams, and then prioritize what to solve accordingly.
Why should you care about sharing context?
The role became sexy and created a perception kept alive by some Product Managers that “doing product” is not for everyone. The statement includes a pint of arrogance as it often implies that product intuition — accurately predicting what your customers need, want and value as well as design and ship the right solution for them — is something you are either born with or not.
Product Intuition is a core skill of a Product Manager but as Paul Adams mentions in this great article, it is learned through direct experiences with customers. Some domain knowledge is transferable, but it is mostly domain-specific (rather than universal) so even if you’re an experienced product leader, talking with your customers remains your main source of insight if you start working in a new domain.
My point is that consistently making decisions that lead to product success is highly driven by having access to the right context to inform those decisions rather than simply being an experienced Product Manager.
Being a Product Manager is certainly a hard role but we’re not making it any easier by mystifying it into something that it is not. Most Product Managers were engineers, designers, data analysts, etc. that started assuming the role. So why can’t other team members learn the role if they want to?
Most importantly, your team already makes daily product decisions, even if unconsciously (e.g. how customizable and scalable a data model or a feature are) and you can’t expect good decisions if they have no visibility into what the company strategy is or what the market and customers’ needs look like.
Not sharing context is a possible path but will inevitably slow you down, which is the anti-goal of decentralized product teams. You will end up either constantly refactoring features or spending too long defining its scope.
The Trap
Even if you agree with the importance of sharing context, it may not be as easy to apply in real life.
Unless you make a conscious effort against it, you may end up being the single point of failure of your team and a bottleneck instead of an enabler by being the sole owner of context to make good decisions and unconsciously not setting your teams up for success by not providing or granting them easy access to that context.
There are 3 main drivers for this to happen.
You’re busy
Your job is never done and as the product expert you come in handy in all sorts of conversations with customers or internal stakeholders but if you can’t find the point of diminishing returns and protect your time, you will end up filling your day with endless meetings and not take the time to enable your team. At the same time, your team may not understand the value of context upfront which coupled with the fact that you’re busy may lead you to decide it is not worth your time.
You will lose power and control
It feels good to be needed, to have our opinion valued and to “know better”. It feels less good if that costs your product success or if you need to work 24/7 to do it. You may be afraid of worse outcomes, losing track of what’s happening or even becoming redundant but having the authority to define what will be built doesn’t mean it is the most effective approach every time or that you don’t need some help.
This is your job
At the end of the day, defining the team’s priorities is part of your job description and you may feel the need to emulate the know-it-all visionary product person, glorified by Steve Jobs stories, or think you’re not doing your job if the team is invited to challenge your thoughts. Although building a tech product requires conviction (and not always consensus), you should be able to articulate which customer, market, or technology insight supports your conviction and welcome your team to challenge it before the market and the customers do it.
As Martin Cagan puts it ”if you’re just using your engineers to code, you’re only getting about half their value”.
How to get started
The right balance between the time invested producing, sharing and consuming context and its benefits will vary based on the company size, target customers, team’s experience working together and so on but the most important is to get started.
1. Share your decisions’ rationale
Things change and you want to react fast but there’s no easier way to kill your team’s morale than to change your opinion on what to build every week without sharing the why.
Sharing your decisions’ rationale is the lowest friction action you can take for your team to understand the insights that are driving decisions.
Particularly if you’re making a big decision, consider writing your rationale with links to the supporting sources (customer calls, sales requests, company strategy, etc.) and invite your team to challenge it. This will not only drive better decisions but also higher motivation and accountability as the team played a role in deciding what to work on.
Doing this alone may lead to group bias around your opinions which is still preferable than a lack of shared context and understanding of the decision-making process which leads each person to make misaligned decisions.
2. Ask your team what they’re missing
Secondly, you should address your team’s needs upfront as they will be the intended consumers of whatever context is available.
Start by asking: "What context do you feel you’re missing to contribute more effectively when we decide what to work on?"
Your team doesn’t know what they don’t know and, although they are already making daily product decisions, you may get answers like the following:
- “I don’t know how our customers use what we built”
- “I don’t know how our multiple products work together”
- “I don’t know how frequently what we built is used ”
- “I don’t know how what we built makes money ”
- “I don’t know how what we built is better than other products ”
Some have clear answers while others are more nuanced or you simply don’t know. Either way, make sure you grant them easy access to your insight sources, discuss the unknowns worth learning more about and nudge them to join you on that discovery should they want to.
You should also be aware of your team’s motivations and expertise. While some care deeply about customer impact, others may be driven mostly by the technical challenge of your product — you may ask those what context they lacked on their last architecture decision for example. The more tailored the depth and type of context is for their day-to-day decisions, the more they will value having that context.
3. Enable access to data analytics
Ideally, there’s a data analytics tool in place that allows everyone to find answers to any data-related query by themselves — make sure people have access to it and know how to use it. If you don’t have any data analytics, you may want to prioritize having one.
To allow focus, create your key product team metrics and (automatically) share those periodically by email to keep customer impact on top of mind.
4. Enable access to market insights
In case there’s not one already, you can create a Slack channel (company-wide is even better) for everyone to share market insights. In case the channel gets noisy, start curating it and sending highlights by email.
5. Enable direct access to customers
Your team doesn’t need to be on every customer call but they can certainly join a few. Consider inviting the engineers or designers that built an MVP or a mockup to shadow customer calls where you’ll seek feedback on those — to get feedback directly from customers does make a difference!
Alternatively, your team can take over customer support for a few hours every once in a while to answer and deal with customer messages directly.
If that’s not possible, start by sharing insights you get from calls on the cadence you get them and keep a conversational approach to invite questions (e.g. use 2 min of the daily standup) — don’t wait to figure it all out before sharing. Got a relevant research insight by email? Forward it to your team, the worst that can happen is for them to skip it.
While doing it, be aware of your natural biases — insights that support your product vision create a nice vibe but are most likely a filtered version of reality.
Finally, while summarizing a message may save the receiver time, it may also jeopardize the message so quotes are better than your opinions, and joining a call is better than quotes — only you and your team can agree on the right format to keep getting customer insights consistently.
6. Enable them to make and influence decisions
This may sound obvious but it’s key that the team has multiple examples of when their context was actionable to either make or actively contribute to a decision — it’s nonsense if you make all this effort but continue making all the decisions alone.
Keep asking your team what they’re missing or getting too much of — you also don’t want the context to be overwhelming or a source of anxiety.
Early signs of impact
Here are a few things you may start experiencing when you keep sharing context:
- You put more thought into your prioritization process as your team is now more likely to challenge it
- You spend less time creating documentation and on tactical problems as communication is more effective within the team
- You have more time to think strategically and long-term
- Your team starts suggesting great ideas you have never thought about due to their unique expertise and background combined with the acquired context
- Your team finds out opportunities while digging into the data themselves
- Your team takes specific customer feedback too serious and is really keen to solve it (even if in the wider context it is not the most important thing to solve)
- Your team answers an external question with confidence on why we are building X and uses customer or market insights to support it
- Your team starts filtering customer problems not worth solving informed by the product strategy and company goals (and understand the strategy and goals usefulness a bit better)
- Your team makes more informed technical or usability trade-offs and shares them with the team, emulating the sharing behavior
- Your team motivation is up as they had a say into what they will work on
Ultimately, shared context is the key to enable your team to make better decisions throughout the day and ship more impactful products, faster.
Which context-enhancing process do you recommend other product teams to try?