My youngest daughter just turned three. Can you believe it? I had already been blogging for a while when she was born, so some of you might remember me writing about how I applied product management practices in the many decisions I needed to make around her birth, for example. I feel nostalgic 🙂

Anyway, back to the present. As her birthday was approaching we needed to coordinate the two parties that we throw every year: one at her daycare, and the other one at home, with the family. The family party needed to wait for two weeks after the date itself because of family travel. But in her daycare, we decided to celebrate on the actual date. 

Her birthday was on Wednesday. The previous Friday, she started to run a fever. I thought it was going to pass in a couple of days, but on Monday afternoon, when the fever was still here, I called her teacher and we decided to postpone the party. 

On Wednesday morning when she woke up, she felt better but still needed to stay at home. Everyone sent her birthday wishes (including her daycare friends in a video call with the teacher!), and we tried really hard to explain to a three-year-old the difference between your birthday as a date and your birthday party. It went okay, or at least so I thought.

On Thursday morning she was healthy and finally going back to her daycare. When we were about to leave home, she suddenly remembered that the party is due. She wanted her birthday party, today! I explained to her that we need to prepare, but she continued to cry. True to my advice to product leaders in these situations, I made it more realistic for her: I said that we need to bake a cake, but she just continued crying and asked that we bake it now. 

She was right, you know. She really wanted that party. She had waited patiently for months, talking and asking about her birthday, until it finally came, and now she could no longer wait. But unfortunately, she had to wait still, because I couldn’t give her what she wanted. 

It’s much easier, of course, when that happens with your young kid compared to when it happens with your boss. When your boss wants something now and you simply can’t give it to them, it typically cannot be resolved by telling them that we will schedule a new date for the party today and that’s it.

One of the common situations where this conflict arises is when you take a new product leadership role. In many cases, you will be joining a company that didn’t have a product leader for a while, or even at all, and if it’s a good company they would want you to come and figure it out quickly. They want you to lead right away. Typically, the CEO will ask for a strategy or a roadmap. The development team would ask for an organized plan as well, wanting to know what to do and not just wander around from feature to feature. All of that, while you still haven’t really landed in your chair yet, and perhaps don’t even know enough about the product or the market to say anything meaningful.

When your explanations about how crafting a good strategy takes time don’t work, you know it’s time to do something else. So here is my best advice on how to approach this delicate situation, where you are still in the “make good impression” period of your new role, but what they ask of you simply can’t be done.

Show Them That You Are on It

Think about it from the CEO’s point of view for a minute. They have been going without a product leader for a while. They have probably been extremely busy recruiting you on one hand and running the team (since there was no one else who could do this) on the other. They didn’t want to make major strategic decisions because they knew that they would want you to do it. So they lived in a strategic void for a while, but now you are here. They no longer want to live in the void, and its impact is probably starting to show. Developers might not know what they will be working on next, and things start to feel a little chaotic.

Your first win here would be to take over. More than they want your conclusions and strategy, they want to see that you are on it and that they can trust you. They want to know that you understand them and that when they sleep at night you think about what’s important to them. They want to know that you are taking it seriously.

After having listened to what they need, share your understanding. What did you get that bothers them? Why do they need things rights away? What are the most worrying concerns? This will also help you focus on the things that will make the most impact for them first (not necessarily business impact, but if they need certain answers quickly you can probably give them exactly that).

Conduct a Quick Analysis

To build a good strategy, you need to start with analyzing the current situation. Don’t confuse analysis with having answers. Your analysis is the approach you take. For example, you can use the pirate metrics framework to quickly understand what areas work well and which areas are problematic. It is perfectly fine to conclude the initial analysis by saying that you have identified these certain areas that don’t work well, and you are going to dive deeper into each to understand what causes the issues.

It’s crucial that you share your insights even if you don’t have clear conclusions yet. The difference between “I’m working on it and I’ll let you know when I’m done” and “here is what I have up until now and what I’m planning next” is immense.

When they see that you are approaching it systematically and that your plan makes sense, 80% of the problem is solved. They know you are on it and they see you are doing good work.

The remaining 20% might be an actual burning need for a strategy, for example, if there is a board meeting or semi-annual planning. If you have these constraints, make sure you give them something to work with. For example, share this initial analysis with the board so that they, too, know that you are on it. It might need to be more concrete in terms of a good plan for the next steps, but it’s not a full blown strategy that you need to build right away. 

Apply the Clearest Insights First

While in a strategy we want to get all the dots well connected, there are usually some things that stand out right away. Call them out. For example, we are currently facing a scale problem in these areas. This needs to be addressed anyway, regardless of any deeper strategic plans, so we might as well start from there. 

When you know of something that needs to be done, unlock it. Don’t let everyone wait for you until you are done. Spend some time (1-2 hours) on organizing your thoughts so that such a plan makes sense. Grouping such items under common themes would help everyone feel better and understand where you are going with this. For example, you might say something like “we are still crafting our strategy for the next phase, but until we are ready there are two areas that need attention anyway: simplifying our onboarding process and strengthening our security for enterprise readiness. This is what we are going to be focusing on during the next quarter, and by then we will share a longer term roadmap based on the strategy that we continue to build”.

This allows you to honestly share your status, acknowledge that this is not yet the big thing that they were looking for, but still understand where you are going with this and why this makes sense in the short term. This type of decision is much better than not deciding at all since you don’t know your strategy yet.

Continue Sharing as You Build the Strategy

To build your leadership and trust, you need to communicate consistently and frequently. Share your current status, your learnings, and your next steps. It’s important to do so even if you don’t have a clear conclusion yet, but it demonstrates the progress and allows everyone to understand and participate in the thought process.

Don’t underestimate the importance of this part. Some people tend to only focus on the bottom line – your recommendations and whether or not people would agree with the direction you are taking. But the process to get there, and their agreement and contribution to it, is important at least as – if not more – than the outcome itself.