When I decided to move into product management I interviewed, among other companies, for a product management role at Google. On the on-site interview day, one of the interviewers asked me the following question: if you had all of Google’s resources and no other constraints, which product would you develop?

I was really afraid of this question. I never thought of myself as the entrepreneurial type, that simply comes up with brilliant ideas out of nowhere. But I knew it was coming, so I spent some time thinking about it prior to the interview. My answer was: I would develop a voice interface for the computer (it was before the smartphone era). The interviewer seemed surprised. “A voice interface?”, he asked with raised eyebrows. “Yes”, I said. His next question was “why?”, and unfortunately this wasn’t a question I prepared an answer for. I thought for a moment and then answered “because it’s time, it would be the next big thing” or something of that sort. 

As you can probably guess, I didn’t get the job. There are, however, a number of takeaways for you out of this story, both for when you are interviewing and for your day-to-day as a product leader.

It’s Not About Big Ideas

If you read again my answers at the interview, you can see that the idea that I raised wasn’t actually bad. In fact, it was probably a pretty good one, given that Siri, Alexa, and the Google assistant were invented since then. What was missing in my answers was solid product thinking.

I sometimes see these two mixed up with people who seek my career advice. They want to consult with me on whether or not product management is the right profession for them since they feel that they don’t know how to come up with these big ideas, and feel that it is needed in order to be able to lead. But the truth is that even if you do need these big ideas in order to demonstrate leadership (and even that is not necessarily true), the ideas themselves never show up in a void, out of nowhere. They are always part of a solution to a larger problem.

For example, one of the most innovative ideas I had throughout my career was Twiggle’s product. Twiggle’s technology was able to improve the accuracy and relevance of e-commerce search results. The technology was always demonstrated as part of a search engine, and that was what Twiggle’s founders originally thought of delivering as their product. But a search engine wasn’t a suitable product for Twiggle’s target market. The potential customers we talked to all had their own custom-made search engine, and replacing it with Twiggle’s simply didn’t make sense (for a number of reasons that I won’t get into here). Prior to me joining the company, there was an idea to run Twiggle’s search engine side-by-side with the customers’ search engine and somehow combine the results, but it was cumbersome and they couldn’t find a good way to do it. 

It was out of these constraints that I came up with the idea to deliver Twiggle’s technology as an API that would plug into any search engine to help it deliver better results, without taking over completely. As you can see, it wasn’t an idea that landed on me out of the blue. It was a relatively simple outcome for a set of well-defined constraints. Unlike what you might think, there is a lot of room for creativity within well-defined boundaries. For some people, like me, it actually works better this way than having something completely open-ended to innovate in.

Your role as a product leader isn’t necessarily to come up with big ideas (the team can help you here), and for sure they don’t need to show up in your head without context. The best ideas are solutions to the most complex problems out there.

It’s Not About Correct Answers

One of the misconceptions about product leadership is that there are correct and incorrect answers that you simply need to reveal. In fact, almost any answer is great, as long as you can explain why it is so. Product leadership deals with so many unknowns, that the absolute truth is not reachable in most cases. Moreover, it deals with the future, and there are many factors that would impact it that you simply can’t foresee. 

In product leadership, we cannot expect to operate only within the realm of known facts. Instead, it is all about risk management. 

And so, to make your point, you need to explain why you believe something is right, and specifically why it is better than the alternatives because progress itself is more important than everything else.

Note that I said that you need to explain why you believe something is right, not why it is right. We can’t know the absolute truth, remember? That means that you need to explain how you see things and help the audience get into your head. This is true whether you are interviewing for a new position or working with your colleagues on a new idea. 

If You Have a Hunch, Find the Logic Behind It

Explaining why you believe something is right isn’t always easy, especially if you don’t know the answer yourself. For example, in my answer to the question at the Google interview, I probably had a hunch that this would be big. But leaving it as a hunch doesn’t help, because no one will follow my leadership just because of my hunch (and honestly, I wouldn’t want them to).

It is your job as a product leader to translate your gut feeling into logical thinking. Ask yourself why you think your hunch is true. Try to convince (yourself first) that your idea is indeed a good idea, based on what you know and additional reasonable assumptions. Make sure to tell a coherent story where one point leads to another, and there are no missing links. It should be like a proof of a mathematical theorem that ends in Q.E.D. 

Your audience (again, interviewers and/or colleagues depending on the situation) should be able to understand why it makes sense. If you are making assumptions in the process, list them out explicitly. Say “I am assuming that X, and therefore Y is true”. If your listeners don’t agree with X, this is a great opportunity for them to speak up. You’ll be surprised how many misalignments are straightened this way. The discussion on the assumptions (in real life and not so much in interviews) is one of the most important ones you can have. It is often more important than the decision itself, as it helps everyone see the world similarly and agree on certain strategic choices. For example, you can say that you assume that monetizing our product is more important for this quarter than growing the user base. If management disagrees, that’s a great discussion to have, the outcome of which will likely be much more significant than a decision on a specific feature.

Another revelation out of listing your assumptions is a spotlight on what you actually don’t know. For example, with my original Google idea, if I forced myself to explain why it makes sense, it might have looked something like this: I assume that in the future computers will take a much more active role in our lives. They will be more prevalent, and we will rely on them more heavily. To make them more useful for smaller tasks, we need to operate them as easily as possible otherwise it wouldn’t be worth it. If they could magically understand what we want without us having to do anything, that would be ideal. But the next easiest thing is to simply tell them what we want.

Out of this explanation, some things make more sense than others, and some assumptions I have more confidence in than others. By stating them clearly, I can now understand which ones require further research and validation, so that I can do proper risk management for my decisions. Without translating my hunch into this level of detail, I would be making decisions in complete darkness.

Whether you come up with big ideas easily or not, always come back to the reasoning behind them. Because the idea is important, but the reason why is much more so.