A framework for empowered product teams
The practicalities of setting up people to do their best work
Empowered product teams are one of the key pillars of creating successful products at scale. However, creating and nurturing an empowered product organization that can execute effectively is one of the toughest parts of product leadership.
As I have experienced it, there is a fine balance of too little and too much space given and it takes practice and constant attention to get it right. This article is written from the product leader’s perspective and explores the practicalities of empowering teams in a consistent way.
A framework for empowerment
Empowering a team is essentially demonstrating trust in the team's ability to make decisions, even when you are not present. It is a critical component to scale a product organization, as after a point you cannot be present to all decisions. And even if you insist on being, you will quickly become the bottleneck.
The premise is simple: You set a direction, provide context and boundaries and let the team execute.
In practice though it is not that simple. There are a lot of nuances and just following the above checklist and hoping for the best will usually yield random results. Whereas as a product leader you should aim for consistent results.
In my view, a good framework for empowerment is based on the following key components:
Constraints
Context
Clear direction
Expectations and accountability
Team composition and maturity
Elements of empowerment
Constraints
A key component to make empowerment work is proactively communicating any constraints and relevant context to the team. For example, if there are budgetary or regulatory constraints, then the team will need to take them into account or they risk getting to a direction where the leader will need to come in and ‘correct’ things. Whereas in reality this could be avoided by providing the necessary information beforehand.
More experienced teams will proactively ask these questions, but I view it as the leader’s responsibility to make sure that the necessary constraints are there, regardless of who asks for them. If the team is not experienced enough to ask them, it is also a very good opportunity to coach them in doing so in the future.
Context
Another important component is providing appropriate context. Context can be about the market, about the organization or about past experience with a given initiative.
For example, if you, as a leader, are an expert in the market, it will greatly help in getting the team up to speed and not have them reinvent the wheel by themselves. Careful though, I don’t support prescribing the solution that you may already have in your head, but providing the team with all the necessary information and being available as an expert resource when they have more questions.
Context also applies to the organization. Who will they need to talk to in order to get more information? Who will help them speedrun that legal review? Who in business development will the team need to onboard as a partner from the start, so that he won’t feel left out (as he usually does) and bite back later? Some may view these as mild politics, I choose to view them as being more efficient working in an organization of people.
And finally, context applies to past experience. Have we tried this before? And how did it go? What worked well and what didn’t? What’s different this time?
Clear direction
It cannot be overstated how critical is to have a clear overarching direction. This translates to a well articulated vision, a product strategy and a strategy deployment framework that is fit for the organization. How to form and deploy a sound product strategy is subject for another article, but I will briefly touch on it in the context of empowerment.
A common mistake is having a great vision but not a suitably detailed product strategy. This causes a gap in understanding for the product teams because they cannot make a clear connection to the current state of things and the ideal reality of the product vision.
A clear product strategy answers the questions:
What are the opportunities we can capitalize on?
Why are they relevant to us? Why now?
Who are our customers?
How are we going to be different?
How are we going to generate business value?
What is not our focus?
And so on. In many cases the irony is that a high level product strategy is defined in the minds of executives or founders but there is not clear articulation and constant communication about it. You know where you need to go and how we have the best chances of making it happen. Why not make it known to everyone so they can help do so?
Expectations and accountability
On an initiative level, the team also needs to know what is expected from them and that they are accountable to deliver it. So, before teams begin work on an initiative make sure that the following are clear:
What is the ideal state we need to be when we call this initiative as done?
What are the relevant metrics to gauge success?
By when?
What are the checkpoints for progress?
The more detailed the expectations at the start, the better the chances for good results are. I remain astounded by people who give a two-liner direction to a team, but will create 200 word prompts for ChatGPT.
Also, teams should be held accountable for generating the agreed outcomes. If you give the freedom without holding people accountable for results then it is not empowerment, it is abdication. If you use OKRs, it is a good practice to incorporate these outcomes as key results on the team level.
Team composition and maturity
Something I learned along the way is that building products is actually a people problem. You cannot have the same expectations from a team consisting of junior members compared to a team consisting of senior professionals.
So, as a leader you need to ask:
Is the team properly resourced to succeed?
Do they have all the skills they need?
Do they have leadership skills inside the team, someone who will help them self-organize?
People dynamics matter, despite what your average project manager friend says.
Also, the concept of the “x10 employee” is real. You need to spot them and have them work on your key initiatives. They will help move the team forward considering that they can work with people (beware of brilliant jerks).
Beyond that though, you will need to carefully balance teams so that they are equipped to deliver but also work as an incubator for more junior members to learn and grow along the way.
Tactical considerations
On a tactical level, there are some techniques that help.
One pagers
A concept that works well is having the team craft an one pager for each initiative before they start working on it. You know, actually write down all the relevant details, the why, the connection with strategy, the metrics and any relevant information that can help align the people on why we are burning money and time on something. This way the team will be forced to ask for this information and the leader will be forced to provide them. And writing things down has the added bonus of forcing people to think more clearly.
Time plans
While empowering people to be creative is great, you will need to provide some time constraints, so that people are pushed to work efficiently. Speed matters and especially in startups lack of speed means death. So, for any non trivial initiative ask the team to create a plan with some clear milestones and put dates on them. Although it may sound too strict, it will help the team focus on good execution. Have frequent progress reviews at certain milestones and be open to reworking the plan if it makes sense as you go. E.g. “We are learning a ton during this week’s onsite with customers so it makes sense to spend a few extra days doing so.”
Product reviews and retrospectives
And finally, it immensely helps holding a review when an initiative has reached completion. This may be when it is released, or even better it may be when it has been released to a small subset of customers for some period and there are metrics available to see how well it performs.
The review ceremony is a great occasion to celebrate successes and remind people what the product strategy is. A separate retrospective of what went well and what didn’t also helps teams improve the way they collaborate and evolve their way of working.
Final words
As stated before, there is a fine balance of too little and too much space when trying to empower teams. Too little and you don’t actually empower people; too much and you risk creating chaos. Having clarity on the different elements of empowerment, their impact and the accompanying tactics will definitely help you move towards the right direction. And as with everything, an evolutionary approach is best; starting from somewhere and keeping an open eye to evolve your approach based on what works and what doesn’t.