Early in my career, I had a mentor. I didn’t call him that at the time, but he taught me so much and helped me shape my leadership style and principles.

One of the practical tips he gave me, was that whenever I talk to someone, I should assume they know two levels less than what I would intuitively think, and start from there. It’s great advice that served me well over the years. People understand things in context, and working according to this advice allows them to get the context first before you dive right into the matter. It also forces you to rise above the details and explain things more strategically, and even if the other person already knows what you have to say, it helps them clear their head from whatever it is they did prior to talking to you.

This method can be used whenever you communicate with others – in your emails, in meetings, 1:1 conversations, and also when you write product requirements, which is what we will be talking about today.

We all strive to work with empowered product teams, who can achieve great things together. For the team to be successful, they always need to see the bigger picture. Even when you work with an engineering team that is used to getting very detailed product requirements from you, they can only gain from getting a broader context. In fact, this is the only way to convert “working teams” into “thinking teams”, and I have seen it in action many times.

Here are three things that you might be missing when you attempt to give the dev team the bigger picture. Without them, it will be very hard to succeed.

Explained Objectives

Start with why is almost a cliche these days. Everyone knows that if you want to get the team to achieve something, you need to tell them what it is you are trying to do. Sharing the goal with the team is basic, and if you aren’t doing it already you should start right away. 

Your goals have many layers in them. However, in my work with product leaders, I often find out that a lot remains only in their heads and not shared with anyone else.

First, you should share why this is the goal you set. Tell the whole story and explain how this goal is helping you achieve an even larger goal. 

Note that I am using the word goal here although it doesn’t have to be a quantitative one. In fact, you must include a qualitative objective to be able to explain the real thing that you are trying to achieve here. Try it out – even if you think the numeric goal is indeed what you are after, ask yourself why this is important and what you will be able to achieve with this number.

If the goal is numeric, explain why this specific number was chosen. If this is not a strict number but rather a nice to achieve one – say it. If you simply want to have a positive impact on a certain metric, and you can only set a ballpark of what you expect this impact to be – share it as it is. Don’t put fake numbers just because you need numbers. If you add numbers, explain their real meaning.

Next, you should share what is important to you about this goal. There are many hidden assumptions that you make when setting goals. A good way to find them is to assume a silly way to achieve the goal – one that is clearly not a good solution – and ask yourself what is missing, which hidden requirements did it break. For example, if you have a revenue goal, a silly way to achieve it would be to sell iPhones at half the market value. You will make tons of money, but the company won’t survive. 

This is a great way to find what else is important for you that you are not sharing. Another type of context is the trade-offs that you are willing to make. There is, for example, an inherent tradeoff between scope and time to market. In this trade-off, which is more important for you? For example, you might want to have a first release that simply works, even if poorly, and take it from there. Give the team this guidance, or else they will try to build much more than you currently want or need.

The Trade-Offs You Already Made

As a product manager, you make trade-offs all the time, not only in the goals you set (as mentioned in the example above). All of these trade-offs, along with your thought process, should be communicated to the team. The reason is that by understanding how you think and why you made certain decisions, the team is able to make more decisions themselves that would be aligned with this high-level guidance from you. Make no mistake: they are making these decisions anyway. You can’t (and shouldn’t) spoonfeed them enough to prevent the need to make decisions themselves whatsoever. So assuming they will need to make decisions, help them make the right ones by giving them guidance on how you would decide on such matters.

Some trade-offs are made at the principle level, like the one I mentioned above: do we prefer time to market over the scope of the feature, or vice versa? Identify these trade-offs in advance, and share them with the team. A good way of identifying these – since this is not how we usually think – is to predict which questions the team can ask you, and seek guiding principles in how you would answer them.

Many trade-offs in your product requirements, however, are made not so explicitly. When you are considering alternatives usually the decision process is more complex, and trade-offs are made on a case-by-case basis. These, too, should be shared with the team, alongside the reasoning of why you made them.

Whenever you considered a number of alternatives and chose one, share all of them and explain why this specific one was chosen. It helps the team not only in understanding how you think but also in knowledge sharing for future decisions. For example, you might think that alternative A is actually better than the chosen alternative B, however, you can’t afford it now because of certain limitations that you have. Once these limitations are removed you would consider going back to alternative A. 

This in itself can open a whole discussion on whether alternative B that is chosen now should be scalable enough to support any future need, or is it only an interim solution (an insight that would, in turn, impact how quickly it can be delivered). The team might also be able to help you find solutions that you didn’t think of and might be able to give you the value in alternative A despite the constraints that you have. The more they understand you, the better partners they are.

What You Don’t Know Yet

In product development, there are many unknowns. Sometimes, you don’t know how everything will work to the last detail, but you still want to start sharing with your team or even release something. People tend to believe that if they don’t know something there is nothing to share, but that’s not true. Because although you don’t know what all the details look like, you do know that there is a missing piece in the bigger picture. Share what the bigger picture is and call out the missing pieces. It doesn’t make sense otherwise.

For example, let’s say that you are creating a new onboarding experience for your product. You know that you want the users to accomplish something at the end of it, and you know what they need to do in order to get there. What you might not know yet is how to guide them to do it so that they don’t have to figure it out themselves. If you only share what you are hoping to achieve and how the users should do it, it might not make sense. The team wouldn’t necessarily call it out, but they will have missing links that they would need to connects themselves. If instead, you share with them that there is an additional piece that needs to be added – the guidance – and that you haven’t figured it out yet, it is much easier to understand how everything works together.

When you add a “TBD” to your requirements it’s not just a placeholder for you to come back to and add more details. It is a way to help the team understand the bigger picture even when not all the details are there. Without these TBDs, the team would have a harder time following your line of thinking, and an even harder time delivering on what you intended them to deliver.

The more you share with your team, the better. Let them into your head, and let them help you. Who knows, if you do it well enough you might even be able to go on vacation and they will manage without you 😉