Some super talented developers were part of this team and I hand-picked the best product designer from our 25-person UX team for this role. Once the dream team was ready, I stepped out of their way and gave them the freedom to do things as they wanted. 

After a few months, I felt that something was off. I did everything as I read in the textbooks. Management consultants would have a hard time finding any mistakes. But it was not working as I expected. As it turned out, the best programmers paired with the best designers don’t necessarily make the best product team.

In this blog post, I will tell you what I learned the hard way: why it’s not enough to select awesome people, give them freedom, and let them figure things out. This lesson I learned will also help you to understand what is the most important responsibility of leadership in a product team.

Why professional excellence is not enough to build great products

I love when we start something new, and I can feel the excitement in the air. This time was not different.

The programmers chose the best new technology stack, and they were excited about how this would make them more productive. Our designer and our marketer immediately started interviewing our target audience. The team set up a state-of-the-art design system to ease the collaboration between coders and designers. And oh boy, when I saw the first designs, I immediately knew this thing would look cool.

The first difficulties arose after a few months. I had a feeling that something was not okay, and it took me several weeks to figure out what exactly it was.

Even though we did state-of-the-art engineering and design work, as a product team we were not good enough.

A product team is measured by two things:

• How much value it creates for the customers, the people who use the product
• How much value it creates for the business

Professional excellence (i.e., being great in the engineering or design professions) helps as long as they add value to the users or to the company. It’s fine to do things to get better in coding or design, but if it doesn’t help the end-users or the business, it’s just a hobby.

In a product team, there is not so much place to do design or coding for the sake of design or coding. The goal is not to look cool for other programmers or designers. The goal is to build something that helps customers solve their problems and create profit for the business in the long term.

Everybody was focused on doing excellent engineering and design work in our team, but we somehow forgot the main goal along the way. This misalignment came to the surface during feature prioritization discussions.

Feature prioritization brings issues to the surface

One of the most difficult things in a product team is to decide what to work on: what features to build or revamp next. There are so many blog posts and books on this topic; it’s impossible to read them all.

During the years, I learned that it’s not selecting the next feature that is difficult. Feature prioritization is just a proxy that brings issues of your product team to the surface. Because these team issues come to the surface during feature prioritization, many people falsely think they have a feature prioritization problem.

My product team also had difficult discussions about what to build next. It wasn’t easy to choose between features because we had so many ideas on how to make our users’ lives better. It was also challenging to balance between the features that are useful to the users and the ones that are important for our business, such as payments or analytics. And while we wanted to build awesome things, we had to slow down, again and again, to do the necessary groundwork for engineering and design.

As a product manager, I haven’t shied away from making the calls. Sometimes I had a hard time explaining my decisions, and I felt that the team would have made different decisions without me. I also felt there is a wide gap between my thinking and the perspective of other team members.

Having different views is healthy and necessary, but for a team to be effective, these different views have to be discussed, and the team should arrive at a common understanding in a reasonable, often quite short, timeframe.

If you notice a thinking gap between you and your team, that’s always a sign that something is off. As I said, it took me several weeks until I could explicitly tell what was wrong.

Although people were excellent professionals in my team, they were not aligned to create the most impact for both the end-users and the business.

Don’t explain decisions; set a context, and let them decide

Once I knew what was wrong, I tried to solve the situation. First, I tried to spend more time explaining my thoughts. It was tiring because I had to explain things in detail repeatedly, and once I shared my point, people always started arguing.

People arguing with you is perfectly okay, but I felt there was an essential difference between how we saw things in my team. I thought once we could overcome this difference, we would become much more effective.

When I saw my explanations didn’t really work, I came up with another idea. Instead of making decisions and explaining them, I tried to make sure they see our situation as I do, and then I let them make decisions.

In other words, I tried to set the context.

At one of our meetings I almost shocked our product team: I told them that on the 1st of May we would evaluate the performance of our newly built product and decide if we will continue developing it or start doing something else.

Nobody’s job was in danger, but we had to prove to our company that our new product was worth the investment and the best way to do that is to show them the number of paying customers.

I saw the surprise on people’s faces. They knew we had to show some results sooner or later, but suddenly this thing became a reality. They also felt there was a chance their beloved product would die, which would be a huge loss as they were working on it for almost a year.

Once I told them about the product performance review, suddenly everything fell into place.

Our designer immediately proposed changes on our roadmap to prioritize features that would get us more paying customers by May. Everybody agreed with his suggestions.

Engineers started to look at their own work differently. They started talking about the “MVP of the features” we were building, and they searched for ways to release important features faster.

Marketing proposed reviewing the quarterly goals to prioritize some marketing efforts we knew would acquire more new users by our deadline.

It was not only the team that was surprised. I was also shocked that a few short sentences could suddenly solve all my struggles. It was like magic. Introducing the May product performance review aligned everyone, and we became a much better product team.

Suddenly everyone was focusing on user value and business value.

And I learned how important it is to set the context.

Why leading with context works better

By introducing the May product performance review, I created context. The team became aware of the consequences of their work. They understood the business needs (paying customers), even if we haven’t set any exact KPIs. They understood the timeline.

They started looking at their work from the same perspective I did, and they were able to make great decisions because this new context created a straightforward way to evaluate ideas: does this idea help us get more paying customers by May or not?

Being aware of the business context, they were able to prioritize user needs on their own. I needed to talk much less in meetings, and I didn’t need to explain things that often.

If you do your job as a leader well, your team will be able to do great work without you. Having a team with great people and giving them freedom is not enough. For me setting up this context was the last piece of the puzzle, and now I believe that as a leader, your most important responsibility is to create context.

Leading with context is so much easier. Once your team understands the context, you don’t have to explain things anymore. You will trust your team much more, and you won’t need to take part in all the decision-making.

According to my estimations, leading with context can free up about 20-40% of management time.

Why leading with context is not always easy

It’s not always easy to lead with context. Once your team faces an issue, your first instinct is to dive deep and help people to solve the problem. It takes time to zoom out, see the big picture behind the issues coming up, and figure out what context you need to set.

If you feel tired of solving issues, there’s a good chance you should take a step back and focus on setting context instead of solving individual cases.

The typical signs of the need for sharing more context:

• Repeated and long arguments about things
• Too much time spent on making decisions
• Decisions made by the team members are almost always different from the decision you would have made on your own

Signs of a great team with the right context set:

• Team members almost always agree about what’s important and what’s not
• Team members can make decisions quickly together
• Less drama, fewer arguments

Leading with context can be difficult because sometimes you have to make people face the harsh reality. It’s not always easy to make people face reality because that reality might be frightening. But your job as a leader is to make your product team successful, and you can’t do that if they are living in a dream.

For me learning to lead with context was an important milestone.

In my next blog post, I will collect the different types of contexts you can and should share with your team as a leader. I will also tell you how to set up a team culture that ensures your team members always stay grounded in reality.

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.