Everyone in the world of modern product management is talking about empowered product teams. Every reasonable company wants them, every product leader wants to build them, everyone wants to work on them. But how does a product team become truly empowered?
One of the key jobs of product teams is to decide. Decide what to build next, decide how to build it, decide what not to build. Decide what bad looks like, decide what a solved problem looks like. Product teams make decisions every day. But how do they know they made a great decision? How does everyone else know? And mainly, what does it take to make a great decision?
The typical product team pattern
Usually, once a product team makes a decision and communicates their decision across the business and to the customers, they start getting questions: How do you prioritize? Why have you decided to do this instead of X? If you’re doing Y, will you also do Z? Are we building feature F? All the dangerous product animals will run to message them on Slack with questions and comments. Seagull managers will swoop in and try to mess around.
And suddenly, the team is frustrated, thinking: “But… we’re empowered, aren’t we?”
They move ahead. They continue with discovery and delivery, they iterate on the solution and from time to time, they share some prototypes with their stakeholders. And here we go again, the moment they send a link to their Figma file, they start getting questions and comments. Recommendations to remove some steps from the flow, move a button around, change the color of an element. But also recommendations to work on many other things, or rework this from scratch.
And once again, they are frustrated. Imposter syndrome kicks in and they are thinking about submitting themselves to a HiPPO to go with the flow and make things easier.
Do you recognise these symptoms? These are symptoms of a lack of context being shared within the company. That holds for context provided by the leadership to the teams, but also for context provided by the team to the stakeholders.
Good context begins at the top
Let’s start with company and product leadership. Your job is not only to build the teams, your job is also to enable them, to empower them. That does not happen by simply saying “I trust you”. That’s a requirement, but by itself, it leads to failure. If you have the urge to question the decisions of a product team, ask yourself what you know (and what they don’t) that caused them to make what you consider a bad decision. You did not hire a bad team, so why are they making a bad decision?
There are some basics that you need to equip your teams with in order to set them up for success:
Without product vision, product principles, company strategy and OKRs (or any other goal communication), your teams can hardly have the right context to make a good decision.
The teams need to figure out many other things to be able to decide, so if you have anything that would help, share it. Empower them. The support team needs to have inline reporting to feedback the biggest customer pains. Legislation in different countries may be almost illogical – work with your legal team. Understand your sales pipeline, which customers are considering leaving you and why. Follow the news on the market to catch the next wave. But also, communicate what’s the cost of not solving this problem (and hence solving another one) or, vice versa, what gets delayed if we prioritize this.
The importance of context reciprocity
Sharing context is, however, a two-way street. As a team, when you share progress on your work, when you talk about your decisions, you need to put them into context as well. You need to make sure that the person you’re talking to knows what you needed to know to make that decision. If you see your leaders questioning your decisions, ask yourself whether they know what made you change your mind.
Think of questions as semi-transparent lenses that you put over differently colored surfaces – these are contexts. The result is a different color – an answer. That’s how powerful context can be. With incomplete or wrong context, you will get a wrong result. A bad decision.
Give context. Ask for context. Refer to context. Why? Because behind every question asked, there’s a need to understand a broader context.
P.S. There’s also a short talk I did on this topic – watch it here:
.webp)