How to Lead a Product Team With Context

Everyone hates old school, micromanaging bosses, who tell people what to do and how. The type who makes you ask for permission for every little thing.

Even the old school “bosses” hate their way of working because they quickly become overloaded. They get most of the recognition, but they also have to be involved in everything, which is super tiring and often leads to stress, burnout, and bad health.

Today there is a new school of leadership emerging to remove this frustration. It’s called empowering leadership. This leadership style encourages leaders to give freedom and responsibility to people and stop controlling and micromanaging them.

If done right, empowering leadership can free up a lot of time for managers. They don’t have to make every decision and double-check everything done by their teams. They don’t have to figure out what needs to be done by each person.

In empowered teams, people are able to figure out what needs to be done and then do it in great quality and in a reasonable timeframe. All without their manager.

But it’s not easy to switch to this leadership style, even with the best intention in mind. In my previous story, you can read how I screwed it up.

The most important tool empowering leaders can use is context. In this article, I will share what it is and how to use it.

Context: the most important tool to empower your team

To create an empowered team, leaders should give up control, and they should create an environment where their team members can decide what needs to be done and how. The most important tool leaders can use to empower their team members is context.

Context is all the information people need to make the right decisions on what to work on and how.

Old school management bosses are the people who know the most; they receive all the information. Some of this information is even kept secret from other employees.

In the empowering leadership style, instead of owning all the information, leaders share the information they have with their teams. In this setup, the leader's job is not to make decisions but to make sure the team has the right context, so they can make decisions on the go, without turning to the leader all the time.

Even in empowered teams leaders might be the people who receive most of the information because of their position. The main difference is that empowering leaders actively share information to create context and empower people to make their own decisions.

Empowering leaders also try to build an environment where people continuously receive the most important insights directly, so the leaders don't have to play the middleman.

In this article, I will share how I create context in our product teams and what is the most important information you have to share as a product manager with your team.

The two jobs everyone has to do in a product team

In a product team, everyone has two jobs. First, you do your original profession. You might be an engineer writing code, a designer drawing easy-to-use interfaces, or a marketer promoting what you build. Besides this original job, there is another one you actively have to work on: figuring out what would be a great product for your customers.

Thinking about what a great product would be for your customers is an ongoing task that is never finished. As long as you have a live product, everyone in the product team is thinking about this.

The role of the leader is to provide the necessary context to this thought process about what would be a great product and to provide recurring occasions when this question is discussed between the team members.

The magic happens when people are thinking about not just their own profession, but they also think together about the product. If they prioritize their common goal — to build a great product for their customers — they will become a great product team, and not just a group of individuals.

In my opinion, you need the following things to work better as a team:

• Everybody knows about what the others are doing, and everybody is actively sharing what they created
• A lot of honest, but friendly and supporting feedback
• Everybody understands the business
• Everybody has a real and lively relationship with the customers
• Everybody is thinking about how to make the product better for the users all the time
• Common ideation and discussions about what to build or revamp next and how

So let’s check what is the contextual information leaders should share, so their team will be able to think about what to build and how.

There is a business context, a strategic context and a customer context, and ech of them are important.

Customer context: everyone in a product team should know the customers

You can only build great products if you know your customers. Period.

And when I say you should know your customers, I mean you should personally know them. All product team members — designers, engineers, marketers, everyone — should have a real relationship with the customers they serve.

As a product team lead, it’s your job to make sure all team members can talk with customers frequently. There are many different ways to make this happen:

Support

In our product team, everyone does support. Everyone is responsible for answering support messages for a few days every four to six weeks. This makes a huge difference.

When we talk about a new feature we are planning to build, team members often try to predict what support requests we would get after the release. And it's a good sign for me because it shows they have first hand experience with our customers and they try to see our product with their eyes.

Answering support messages helps everyone to see what people understand and what they don't. It also helps us understand what level of complexity is too much for our users and how they try to solve things.

Doing support is actually my favorite tool to create customer context. Our experience is that somehow the person who is on support is exactly who is needed to fix a problem. You can be sure the server will die off when the backend developer is doing the support, and the browser glitch will come up when the frontend dev is taking a turn.

Once people have to answer these support questions, you don't have to ask them to solve different issues; they will do it on their own because they don't want to answer the same questions all the time.

But it was not easy to introduce doing support in our teams. You'll probably also feel resistance if you decide to try it, but believe me, it's worth the struggle.

When we introduced doing support together, I said I would also do support as a CEO and took the first round. Once they saw their leader was doing it, there was no objection. I also highlighted later many times that doing support and having a real relationship with our customers is one of our core strengths. It is now written in all our job ads, so people who come to work with us will know about it upfront.

And to be honest, I’m not doing support myself just to make my team do it, but it’s a good feedback mechanism for me as well. Steve Jobs was also famous for reading all the support tickets and the feedback emails people sent him (although he never replied).

Doing support is a great way to create customer context because your team members will communicate with real customers directly, and they will get first hand experience in what they like and don’t like.

User tests

The first time you see people struggling to use your perfect app is eye-opening.

Attending usability tests and observing how real people use your product is something everyone should experience.

Designers and UX researchers should run usability tests with people from your target audience frequently. Our designer conducts at least one user test per week, and there is always someone else from the team joining these test sessions. This means everyone attends a user test every four to six weeks.

From a leadership perspective, it’s also important to make sure the learnings from these tests are shared across the team. Many teams use robust research libraries and build huge knowledge base systems to store research findings. While I respect the scientific precision behind these efforts, I prefer to go lean and use lightweight methods to circulate information.

Our designers usually send a short summary to the product team’s Slack channel on the day of the test, and at the beginning of our weekly product meeting, the designer or researcher also sums up the learnings from last week’s test.

Attending user tests and sharing the learnings from tests is a great way to create customer context because your team members will see real people using your product and how they deal with it.

Checking user-generated content

You can learn a lot about how people use your product if you check what they create with your product.

When we release a new feature to UXfolio, the responsible designer always goes through the public portfolios of the people who used the new feature. Designers usually collect some screenshots on a Miro board and have a quick recap about what they saw at the product team's weekly meeting. It’s important for the whole team to see these examples.

We are happy when we see people using our new feature to make great things. And we learn when we see the user-generated content is not so great. We always spend some time thinking together about how to improve the new feature to make sure more people can get the most out of it.

Checking user-generated content is a great way of creating customer context, because it ensures your team members see what people are able to achieve with your product.

Usage numbers

This is the obvious thing most people know about. Quantitative data is the final truth. It always tells you how real people behave using your product. Despite being the most popular source of information, data and analytics are not easy to process at all.

To mine out meaningful information from your usage data, you have to get a lot of things right, from the technology background to asking the right questions and analyzing the raw data you see. And even if you do it right, data is a stubborn creature. In many cases it doesn’t help you to learn why things happened. It just tells you what happened and leaves you with even more question marks.

This doesn’t mean you don’t need data; you just have to use it combined with the qualitative methods above.

As a leader who wants to make sure people have the right context to make decisions, you have to provide the necessary data sources and tools to your team members, so they can dig into them and find the answers to their questions.

Big companies often have dedicated data science teams. Some of them work like internal agencies, where everyone can go if they have a question they want to answer with data. For data-intense work, they also often appoint data scientists to work in a cross-functional product team as well.

In smaller teams, it’s usually a developer working together with UX or marketing people to set up the right analytics tools. Once you have a few tools set up, it’s important to teach your team members when and how to use them.

It’s also worthwhile to introduce some team habits or rituals when you look at data together. For example, before we release a new feature, we always ask ourselves first what we should measure. Then after the release, the designer creates a short report about the usage numbers for the next product meeting, so all team members will be aware of how the new feature performed.

B2B: customer visits and sales meetings

Product teams working on B2B products are often in a special situation, with more constraints but also more opportunities. You can rarely check what your customers do inside an ERP system. On the other hand, you can do customer visits and sales meetings, which are super exciting.

If you want to make sure your team has the right customer context, it’s worth it to let them visit customers time-to-time. These trips are often great opportunities for some team building, but they will also learn a lot.

I was designing a call center software once, and I was able to visit one of these call centers. You can imagine a huge hangar with hundreds of people talking on the phone all the time. It was quite an experience, and it changed how I see these people and their jobs completely. It also helped a lot to design much better interfaces for them.

Another source of great input is attending sales meetings. Business applications always have two customers: the people working with them, and the people who buy them. However you want to focus on end-users, the reality is you have to take into account the purchase manager as well.

Joining some sales meetings can help your team members see how the software is sold and what do customers seek from it when they make their decision. It’s just as eye-opening as user tests.

By getting all team members to visit customers and join sales meetings occasionally, you can make sure your product team will stay grounded in reality.

The methods I listed above are all about being in touch with customers. But there is one thing team members can’t learn from customers, and that is the vision and the long-term goals behind a product.

Strategic context

When you start building a new product, everything is fluid and uncertain. Later, when things start to work out, you will have more clarity about what you do and why.

Besides making sure everyone in the team has an ongoing relationship with customers, leaders should also summarize and clarify the learnings and provide a big picture. One of the tools to achieve this is to define product vision, values, and strategy.

The product vision is how you see your product in the long term (in software long term is around five years). Marty Cagan advises us to make a good-looking video about this future. That tip might work well in big teams, but for smaller ones, an enthusiastic leader talking about the future version of the product with a twinkle in the eye is also great.

Your product strategy is a high-level plan that explains how you want to achieve your vision.

The product values are often the qualities that are important for people when they use your product to solve their problems. For example, many designers say to us that they want to build their portfolios quickly, so one of UXfolio's product values is speed.

As a leader, you should make sure you have a clear vision, values, and strategy for your product.

It is a good idea to craft these together with your team so that they can own them from the beginning. It’s also important to share this with everyone who joins the company.

As a leader, you don't just create a context by crafting vision, values, and strategy. You also have to make sure these are alive by repeating them again and again until everyone remembers them and they become part of the common culture of the team.

Obviously, it helps a lot if these are not just a collection of made-up buzzwords but a representation of what you really want to achieve with the product. You should also take them seriously while making decisions. People will see if you do so, and they will follow along.

Business context

Unfortunately, it’s not enough to know your customers well and build a useful product for them. You also have to make some money on the go.

If you want to trust your team members to make the right decisions, you have to make sure they understand your business.

I have worked with some big companies where brilliant engineers were doing magic every day, but even these super-smart humans were not allowed to look at some basic financial facts about their own workplace.

The only way to build trust and inspire people to be engaged is to share the necessary background information, so they can see the full picture of the product and the company.

One month after someone joins our product team, we give them a short training where we look through the basics of our finances, like where our revenue comes from and how we spend our money.

We also talk about our business model and pricing with newbies. It’s important for them to understand how we make money. We tell them our marketing strategy as well, so they know how we get more customers.

We also have numbers we check frequently. Our marketers send weekly reports on Mondays to our product teams' Slack channels containing the six to eight most important numbers, such as the number of users, the number of paying customers, customer growth since last week, and some stats about our key marketing channels. This weekly report ensures everyone in the product team will have a feeling about how the product is doing.

Our team members also have access to our financial analytics tools, like our Stripe dashboard and our own internal admin panel. So whenever they want to look up something, they can.

Besides the financial and marketing numbers, product team members should also know about the company’s plans with the product and the business. It’s an important task for team leads to share the company objectives and explain the product team’s role in achieving these goals.

The company's objectives should be translated into product team objectives. The teams could also have some target numbers to reach. You can use OKRs, for example, but it's not the only way you can set goals and measure progress.

To sum it up, as a leader, you should make sure your team members:

• Understand the business model, the marketing strategy, and the basic finances behind your product.
• Get frequent updates about the key business numbers and have access to business data.
• Understand the business goals of the whole company and how the product team fits into this bigger picture.

Conclusion: make sure your team is exposed to reality

I know this article covered a lot. If you would want to implement everything you read today, well... Good luck with that. :D

Here is a quick summary though.

You have to make sure your team members have all the information to make even important decisions without you. To achieve this, you have to tell everything to your team, but you also have to make sure they are continuously exposed to reality. There are many nice methods to achieve this, from doing support to getting updates about important numbers.

If I were you, I would spend a few minutes thinking about what is the thing missing from your team the most and how you could introduce that one thing to your team during the next few days.

I’m sure it will help you make your product team even better.

Searching for the right UX agency?

UX studio has successfully worked with over 250 companies worldwide.

Is there anything we can do for you at this moment? Get in touch with us, and let’s discuss your current challenges.

Our experts would be happy to assist with the UX strategy, product and user research, or UX/UI design.