As a parent, my instinct is to do whatever it takes to keep my kids safe and happy. When something happens – they fell and hurt their knee, or a friend broke their heart – I literally feel the pain with them. Many times, I wish I could take it away from them either by fixing things or by suffering instead of them. Unfortunately, life doesn’t work this way.

The former – always fixing things for them – isn’t recommended if you want your kids to become capable adults. The latter – suffering instead of them – is simply impossible. And so, I find myself having to learn to live with the fact that I can’t always save them, and that they cannot always be happy. I keep reminding myself that it’s actually the right thing to do if I want to keep them safe and happy not just now, but for the rest of their lives. It’s an investment and not just a painful reality.

As product leaders, we sometimes feel the entire organization is our kids in that situation. We keep enabling them so that they can perform their jobs best because our success (as well as the company’s) depends on that. But it’s not always possible to make things easier for others without damaging other things. Much like in parenting, we are sometimes willing to take upon ourselves more than it’s wise, just to let everyone else keep up their own pace.

I’m not necessarily talking about load here, although that’s also worth discussing. I’m talking about cases where it’s not wise to fix things for the company because you are building it on a shaky foundation that will backfire right on you in the future, and will cause more harm than good.

Here are three examples of lines you shouldn’t cross, despite the temptation to do so and keep things quiet for a while. They are all based on real stories of product leaders I work with as a consultant or in the CPO Bootcamp, and I’m sure you’ll find them as real as they are.

A Roadmap Without a Strategy

It’s this time of the year again, and everybody needs to plan their roadmaps. In many companies, especially in the current economic climate, this is also an opportunity to make major changes. Companies change their focus, their budget, and org structure. While budget and org structure are pretty clear cut, so companies usually decide and stick to their decisions in these areas, strategy and focus are much softer and easier to change on one hand, and much harder to figure out on the other. 

And so some of you might be asked to create a roadmap when the strategy is still unclear or changes frequently. If you are a product leader, maybe you are the one who needs to set the strategy, but you don’t have the time for that since you already need to provide a roadmap. You might have asked for more time, usually, the answer will be no (or something like “ok but be quick”, which essentially means no one is going to wait for you). If you are working in a larger company, your roadmap most likely depends on other teams to deliver too, and you might feel that if you don’t make your asks now you’ll never get the resources you need later.

I see many product leaders struggling in these cases and tempted to simply create a roadmap and worry about strategy later. It will make things easier for everyone – they will have clarity on what is it that we are going to do, all the plans will be in place on time, and you won’t be asking these annoying questions about strategy all the time. But this creates a false sense of peacefulness. Because without a strategy, your roadmap will either fall apart soon after you begin or even worse – you will complete it as planned but it was simply the wrong thing to do. So you might find yourself (and everyone else) working really hard and unable to achieve the results you want. As much as you want to, you can’t fix things for everyone on your own.

If doing strategy first really isn’t an option, the least you can do is be extremely transparent with everyone that a strategy is still being figured out and so anything you present is half-baked. Present what you already know and make sure they see progress, but don’t make them believe it’s all figured out. If you need time commitments from other teams, agree on a reasonable amount without too many details about what you will use these resources for.

Like anything else in roadmaps, this too might change over time. But at least you gave them the heads up and took ownership of it rather than pretending that they can rely on it blindly and taking all the responsibility upon yourself.

Sales Commitments

If your company is working with large customers you most likely deal with customer requests all the time. Not just the general, learn-from-the-field kind of requests, but rather requests that are deal breakers for some major revenue. Dealing with deal breakers, in general, is a topic for another article, today I want to talk about it as part of annual planning.

When sales teams commit to a certain quota, they often (unfortunately) rely on changes to the product as part of a deal. In some companies, it happens more frequently than in others. One of the product leaders I work with recently asked me how can they let the sales teams know in advance what they can and cannot rely on as part of this planning. My answer was that they can’t.

Generally speaking, the sales team needs to sell the product that they already have, not the product that they have plus only some changes that are specific for this customer. In reality, that’s not always possible. Some customers and some deals are worth making an exception for. But since this is an exception, it should be treated as such and not normalized as business as usual. 

In practice, this means that the sales team should know that they are asking you to make an exception, and involve you as early as needed. They should also understand that you might say no – not because you don’t want to help them, but because it’s the right thing for the company. 

So as much as you’d like the sales commitment process to be smooth and easy, you can’t do that. First, because it’s not smooth and easy. And second, because if you do so, you will make things worse. You will be the only one who suffers the consequences, without letting anyone else take some of the load off of you. 

Malfunctioning Team Members

This is an even more complicated example because of two reasons. First, since the product manager’s job is so hard, it’s not always easy to distinguish between malfunctioning product managers and environmental barriers (e.g. no one would succeed here). Second, if someone in your team isn’t performing well enough, and you manage the team, what does that say about you? If you hired them, it means admitting you failed. Even if not, you want to make sure you give them a fair chance to succeed, and together with the first reason, you might find yourself compensating for the poor performance of a team member so that others don’t suffer from it.

This is true even if the team is not malfunctioning but is simply overloaded. You have so much to do, you believe in the vision, and you know it’s all super important and needs to be done, so you will try to do that even if you don’t have sufficient resources to succeed. Your commitment to the company goals is admirable, but don’t let it go too far to the point that it hurts you.

Remember, your company needs you to succeed. In most cases, that means doing things well and not just doing them to a minimal extent. Sometimes it’s best to say no to some initiatives if you can only execute them poorly. It’s not that you can’t do anything there, but you can’t really do it well.

Here, too, you can’t take it upon yourself and work harder to succeed despite the shaky foundation. Wait, scratch that, you can, and sometimes you will. But you should save it for special and rare cases. It can’t be the method that you use regularly, because eventually you and the team will burn out, the results wouldn’t be as good as they can be with a proper team in place, and you will have a hard time doing your job as a leader when you function as a replacement or support for other people who can’t do their job.

Just like with kids, sometimes it’s ok to fix things for them when you can. But it needs to be the exception and not the rule, or it will come to haunt you down.