One of the first major fights I had with my husband was actually before he became my husband. In fact, it was during our trip to Italy, just a few days after he proposed to me in the most romantic spot in the Italian Riviere. Terrible, I know. Excited about the future of our relationship, we talked about where we wanted to live. The problem was that we wanted different things, both impacted by where we grew up. My husband grew up in the far north, at the end of a small town, with a forest starting literally in his backyard. I grew up in Tel-Aviv, the city that never sleeps. We both imagined building our family in an environment similar to the one we had as kids ourselves. Unfortunately, these two environments were very different from one another. 

This, however, wasn’t what started the fight. We both knew that we will figure it out. What did start the fight was a question that my new fiancee asked me as we were traveling in the middle of nowhere in Italy – seeing nothing but green mountains and an occasional house. He asked – naively, as he explained numerous times since – “wouldn’t you just love to live in such a place?”. My answer was a bold “no”. But he continued to ask why and explain all the benefits of such a beautiful environment. I felt pressured, and I hated it.

Now, don’t get me wrong. I know I am not the sole decision-maker here, and some compromises would need to be made. But I don’t want to be convinced – in good faith or not – that they are actually not compromises. I am a grown woman who can handle a good compromise in the name of true love. What I fought for was my right to express the ideal world I wanted to live in. If it was all up to me, we would raise our children right in the heart of Tel-Aviv. I get that it’s not all up to me, but don’t try to convince me that this is not what I really want.

I found myself telling this story multiple times this week. They were all cases where the product leaders I worked with couldn’t detach from all the constraints that they had to deal with, to even understand what they really wanted. They could only think about what’s feasible, but that is a mistake. Feasibility – technical, business, process, or even relationship-wise – is of course important for everything we do. To get any results at all we need to work with reality. But feasibility is important in reality, while we often let it limit our thoughts as well.

You might ask yourself what’s the big deal. If anyway when we come to implement things we would need to make them feasible, why is it important to ignore it at first? The answer is twofold: first, if you are making compromises you are much better off making them knowingly since there might be a risk there that you want to manage. For example, if you found a nearly perfect candidate, but with one area where you compromise on their abilities or even potential, you can mitigate that risk either by assigning this responsibility to someone else or by giving that person extensive coaching on the area where they are lacking. You cannot do that if you don’t even acknowledge that you are making a compromise. 

The second reason that it is important to forget at first any constraint you would need to deal with later is that it limits your thinking and the realm of possibilities you see. If you know that growing your business 10X this year is not possible, you most likely wouldn’t even see options to grow it 5X. But if you ask yourself what you really need or want, if everything was possible, your answers would be completely different.

One area that I have recommended using this technique in the past is with understanding the desired solution for customer problems before applying any specific technical or resource-related constraints. But here are a few more areas where you want to understand the ideal solution first, and only then add the constraints and the compromises you would surely need to make. 

Process Design

Building a great relationship with your R&D counterpart is extremely important for your ability to succeed. Some of it has to do with personal connection (I had a trick for enabling that connection between my PMs and their R&D counterparts: I would send them abroad together and tell them to sit next to each other during the flight. Things look very different after you’ve seen your colleague sleeping on an airplane seat and had to literally walk on top of them to get to the bathroom). Often though, as it is with any relationship, friendship is not enough. Every now and then, there are things that don’t work, and a very common example is the work processes between product and R&D.

Every time I worked alongside a new R&D leader, we took the time to define the processes that worked for both of us. It requires deliberate thinking and discussion, a great process doesn’t just happen. The starting point for such a discussion should be what is important for each side. What an ideal process would look like – for your needs, and separately for theirs. This allows you to understand what are the common parts that you immediately agree on and see eye to eye on, and how big is the gap you need to bridge elsewhere. 

It is important to define for yourself and express to the other side what are the parts that are really important to you, and why. For example, one of the R&D executives I worked with didn’t like Scrum. When I first heard it, I immediately knew that I have no problem with that, as long as we remain agile. We ended up using our own flavor of Kanban that worked well for everyone. But This could have become a serious problem had I not known to say that it’s the agility that is important for me, more than the specific flavor of it. 

Goal Definition

One of the assignments at the CPO Bootcamp is to define and break down the company goals so that the participants (and their companies) uncover what’s really important within the formal goals that are often too high level. Over the years, I have seen numerous goal definitions.

It is usually very easy to know whether the product leader thought about these goals top-down – what we really need based on where we want to be – or bottom-up – this is what we can do so let’s define the goal accordingly. 

The mere fact that it is easy to distinguish between the two, says something about why it is important to think about goals top-down first and only then add the constraints of what you can truly achieve: the goals you would end up with are much more likely to get you to where you want to be. Moreover, if you absolutely cannot achieve them, you still want to know that when you are still planning and not only after you have failed.

To do this effectively, you must force yourself to “forget” (that is, not consider) anything you know about what can be done, and think only from the perspective of what needs to be done. For example, when you set your ARR goals, take into consideration first what you must achieve in order to be able to raise the next funding round. Only then consider whether or not you believe it can be done and know how to get there. Willingness to acknowledge such gaps is where your leadership really shows.

Business and Product Metrics

This is one of the most common areas where I find myself talking about understanding the desired first and compromising on the feasible later. Whenever I talk to product leaders and founders about what they need to measure, they immediately think about how they are going to measure things. But that wasn’t the question! The question was about what you need to measure, and which metrics would best answer the business questions that you need to be answered. 

Not all of them can be measured as desired, of course. But you can’t think with a black box and white box mindsets simultaneously. When you apply white box thinking – taking into consideration everything you already know about what can and cannot be done, you are losing the ability to apply black box thinking and think about what you really need.

Whenever this comes up in a conversation, I suggest here too to assume that we can measure anything we would want to. It helps focus the discussion on the important question which is – what do we want to measure?

In metrics definition, the compromise is very straightforward: it’s heuristics, proxies, and assumptions about the world that explain why the metric that we end up measuring is a good representation of the ideal metric that we would have measured if we could. Here, too, it is super important to understand the limitation of the metric compared to what you really want, since you would be making so many decisions based on it.

Strategic Customers and Partnerships

One of the unicorns I work with had an issue with a strategic partner. They realized that the former agreement with them is bad for both the partner and the company, and wanted to change it. It is a complex situation to handle, very sensitive legally, financially, and commercially. In a preparation for the discussions with them, the product leader needed to put a proposal on the table. However given the complexity and the sensitivity of the situation, there were so many stakeholders pulling him in a variety of directions. Each stakeholder tried to enforce an end state that would satisfy their own point of view. Of course, these solutions couldn’t work together, and that’s even before they took into consideration what the partner would want or be willing to accept.

My advice for the product leader was to first get all stakeholders to think about what they really want, not about what’s the best they can achieve. It is only this kind of thinking that has the chance to enable a single solution that would satisfy all the stakeholders – and essentially the company’s – needs. And it is only then that they can understand what they really want, and understand which compromises they are willing to make in the resolution of this complex situation while considering the other side’s needs or willingness to cooperate as well.

Thinking is free. Don’t limit yourself too early. Remember – it’s not because you are a dreamer, but essentially the other way around: it is the only way to find true solutions to the problems and issues that matter most.