When I was VP of Product at Twiggle, we had a management off-site with some outdoor activities. I’m sure you are all familiar with the concept – the team needs to do something together and then we see what we can learn from it. Honestly, often the learning is trivial and there is not much that I can take from it. But in this case, it was very different.

The team was split into groups that competed against each other on a variety of tasks. We didn’t do them at the same time, so we didn’t know how the other groups were doing until the end of the day. One of these tasks was to build a dome. We got all the relevant equipment as well as very clear instructions. There was nothing tricky about it, simply construction work that needed to be done according to the manual. I was the only one allowed to see the instructions and had to tell other team members what to do. They told me that the score would be calculated as follows: when we say we are done, there is a penalty for every mistake they find, but there is also a factor for the speed – the fastest we complete the higher the score is.

I’m sure you can see how this activity is related to the product leader’s role, it is very straightforward. But the learning I took wasn’t about the role or about the importance of speed. I learned something very important about myself and about people in general. But we will get to that later. For now, I’ll just tell you the bottom line: our dome was perfect. They couldn’t find any mistake. But we were the slowest to complete it. We didn’t take any risks, and we didn’t win.

Now let’s take it back to the product world. How can you encourage your team to take more risks (because sometimes that’s what you need to do to win)? You want them to be calculated risks on one hand, but significant on the other, and various guidelines apply to different cases.

Here are three things that you can do to master this.

You Do Care More Than You Think

N., the CPO of a well-known startup, described the following case to me: she gave the team high-level instructions on a certain feature and she didn’t care how they would take it from there. But when she saw the result, it was such an overkill compared to what she had expected, that she had to chime in to make the decision herself. 

I pointed out to N. that the truth is, she did care about the end result, and had a few guiding principles that she didn’t share with the team but were still very important to her. So the first rule is to share with the team what’s important for you. Specifically, which risks you would like to take here, and which not.

Of course, that requires that you stop for a minute and articulate your thoughts clearly since oftentimes we assume that things are clear when they actually aren’t – not to ourselves and let alone to others.

Note that the things that are important to you could be related to the product or the outcome itself – for example, you know that pricing pages can be complex and you want to keep yours simple. You need to communicate that as clearly as possible. But in many cases, you also have things that are important for you regarding the process or setting expectations regarding the investment. For example, when you simply want to have something out there as quickly as possible, not because you want it to work well, but because you want to use it to learn something much more important about your customers. In this case, creating the perfect pricing page is missing the point, because the speed of delivery here is more important than the delivery itself, and you wasted precious learning time in perfecting something that would change many more times.

If this isn’t the general state of mind of your team (and it can’t always be, sometimes you do need to make it perfect, or at least perfect enough), you must communicate this expectation very clearly from the get-go. Generally speaking, it’s always best to over-communicate than to assume something is clear to everyone just to find out eventually that it wasn’t.  

Everything Is Risk Management

Almost every decision we make as product leaders is related to risk management. There is a risk in delivering something that will not bring results, and there is a risk in delivering the perfect product too late. There is risk in focusing on a single use case and there is risk in building a one-size-fits-all product or feature. There is risk in prioritizing by fire drills and there is risk in not reacting fast enough to the feedback you get from the market.

While as I said this is true for almost every decision you need to make, you rarely communicate it as such. By communicating the risk (and the benefit) clearly, you are able to guide your team in finding the right balance themselves and making the right trade-offs.

To communicate the risk clearly, you first need to acknowledge that there is indeed risk involved. Even if you have a solution in mind, and you are 100% sure that you want to go with it, understand where is the risk that you are taking and say it explicitly. Say that this is a risk you are willing to take. The more controversial the decision is, the more this statement will help you.

If it is about risk management, it is no longer about opinions. And if you want to encourage your team to take risks, show them that it’s ok and lead by example. Take the risk upon yourself, it will help them feel safer in moving forward with the direction you want them to take.

Another important part of encouraging your team to take risks is to highlight the potential gain. If the gain isn’t huge, why risk ourselves? Even if you feel the gain is clear (shorter time to market, for example), take the time to explain what happens if you don’t take the risk. In other words, missing the opportunity to gain here is also a risk, and you want to explain it as such.

Don’t leave it as a high-level statement like “It’s more important to move fast than to deliver the perfect feature”. Explain for each feature why it is important to deliver it fast and what you are hoping to achieve by doing so. This will also help the team align on where they can narrow the scope or give up on scalability, but still deliver the desired outcome. Over time, you might be able to shift the team’s mindset to moving faster by default and might not need to do it for each and every feature. However, given people’s nature, it is not very likely, as I explain below.

Remember Newton’s First Law

Newton’s first law says that a body will continue to move in the same speed and direction it is already moving in unless acted upon by a force. It’s true in physics, and it’s true for people.

When it comes to changing people’s behavior, the force needs to be significant and continuously applied, as we can learn from the outdoor activity story I started with.

The reason our team built the perfect dome but the slowest one too, is because that’s my natural tendency and that’s how I guided the team. This learning was so meaningful for me because I already knew about this tendency and was already coaching myself for quite some time to move faster at the expense of delivering a perfect result. I did just fine when I paid attention to it, but my natural tendency won when I wasn’t.

When it comes to taking risks, you must understand the natural tendency of each and every one of your product managers. Some of them will need a stronger push in this direction than others.

In my case, for example, it wasn’t enough that I was already aware of my tendency. It wasn’t even enough that they told me speed was important. As far as I was concerned I moved as fast as I could! But then I realized that I had to move faster to win.

Some people in your team will need a stronger force applied than others. For some, for example, it will be enough to say that you want them to move fast even if the results are less than perfect. For others, you might need to communicate that you have set the expectation for the entire organization that speed is more important here and they understand that moving fast has a cost. But for some, especially those who see the product as theirs and feel that it reflects on their performance, you might need to be as blunt as saying “I need you to be mediocre here”.

As an ultra-perfectionist by nature, I can say that sometimes this is the only thing that would have moved me away enough from my tendency. Because when you tell a perfectionist that they are allowed to make mistakes, they will, and they will be out of their comfort zone already, but it will typically be in the small things, and wouldn’t make the difference you wanted to make – just like it was in my outdoor activity.

***

Learning a new soft skill is much harder than learning a new professional skill or domain. It takes continuous practice, not just theoretical knowledge. That’s why I built the CPO Bootcamp as a 10-week program, that allows the participants to practice the numerous soft skills they need to excel in under my ongoing guidance, support, and feedback. That’s only one of the things that make the CPO Bootcamp such a unique program, and it definitely proves itself in the results.

What about you? Have you taken any risks lately? Are you helping your team take more risks? I encourage you to choose one practice from the three I mentioned above and start practicing it right away.