Leader Spotlight: Zooming out and widening your aperture, with Vaarrun Bimbhat

---

Vaarrun Bimbhat is a seasoned product leader who most recently served as Head of Product at Shopify. He began his career in software engineering at Liberty Mutual Insurance, where he later transitioned into product management. From there, Vaarrun became a group product manager at Wayfair before transitioning to Shopify.

In our conversation, Vaarrun talks about the importance of zooming out to see the macro picture for product strategy and unlock new areas for growth. He also discusses how he builds a product portfolio that balances risk, long-term and short-term planning, and innovation.

---

Optimizing for a global optimum vs. a local maximum

To start, could you talk about what kind of indicators you look for to signal that it’s time to shift focus from achieving those short-term goals to investing in longer-term returns?

First and foremost, it’s not always necessary for a team or product to pivot from focusing on the short term to the long term — it depends a lot on your context. For example, if you’re working on a growth team that’s focused on executing multiple experiments to achieve short term results, that’s OK. I wouldn’t necessarily advise such a team to pivot their focus.

When it does make sense, however, is when you begin to see leading indicators of diminishing returns. Let’s say you’re executing a product strategy with several features in your roadmap. You expect a certain outcome, both in terms of the leading and lagging indicators. You begin to notice that while leading indicators look good, you’re not able to get to those lagging indicators. As a result, you’re not getting the necessary user satisfaction or revenue that you were anticipating. Those are signs that something is wrong with the product that you built out — you ended up prioritizing short-term hacks or features.

I often recommend people look out for these diminishing returns, not just in the work they’re doing, but also through different forums. For example, you might see a lot of customer support tickets. People might even start moving on to your competitors’ products instead. When you start examining those competitive products, you’ll realize that there is a philosophical difference in how you approach building your product versus them, indicative of risks in the long term.

Would you agree that sometimes, it’s not that you got the product wrong, but that customer needs have evolved?

Yes, and I believe that reinforces the need for problem discovery to be a continuous exercise. I’m a big fan of optimizing for the global optimum versus a local maximum. It’s a mathematical concept, but it comes with a specific limitation that people don’t often talk about enough. The reason people make choices to optimize for the local maximum is because they are constrained in their view to identify the global optimum. They’re constrained because either they haven’t done enough work to widen their aperture or because they haven’t gotten to a point where their aperture can be widened. Those are two different things.

For the first one, it has more to do with if you’ve done an extensive problem discovery to understand the entire landscape of problems. That enables you to prioritize the most impactful problem to solve. The second one, which is more challenging, is usually because you do not have the vantage point to learn about customer needs or the broader landscape.

To address this issue, I recommend designing and executing iterative tests so that you can get to the local maximum quickly. Then, you can widen your aperture to identify the global optimum as the sort of goal to prioritize. That’s why I think continuous problem discovery and moving fast on validating problems is such a key part of product development — it de-risks and improves your understanding of the problem space and the customer landscape overall.

How do you work with your teams to help them widen their aperture?

I think 50–60 percent of good product managers can do good problem discovery. They excel at examining multiple inputs and synthesizing them to identify the best problem to solve for. Where I’ve seen limitations, however, is in being able to execute on those inputs quickly so that they can widen their aperture and identify the global optimum.

The two things that I coach for are zooming out and testing. First, when you’re doing your problem discovery, try to zoom out to see the forest for the trees, and inculcate that perspective for the customer as well. I’ve often seen that customer conversations can lead to another problem called “the focusing illusion,” where, at that moment, you and the customer think the problem you’re talking about is the most important one. Instead, you should think through all the problems the customer is experiencing and which of them, if solved, would move the needle.

Second, now that you’ve done this exercise, how can you design tests or low-code experiments to quickly validate if the proposed solution can move the needle? When you do that rapidly enough, you will begin to widen your aperture and get to points where you can actually examine the problem space more holistically. Make sure that you have certain customers who are advocates, almost like beta testers, to work with and bounce ideas off of.

Building a balanced product portfolio

You often talk about building a balanced product portfolio — one that manages risk but also drives innovation. Could you say more about that?

I’ve been fortunate to have worked in a lot of companies where I’ve identified long-term goals or products that could maximize success overall. A lot of these products have been platforms that I’ve built out in different contexts. In several cases, I saw indicators that led me to realize that multiple teams within the company were investing in the same domain, even if that domain was not a core part of their product.

First, removing that duplication is purely an efficiency play. It reduces the amount of engineering or product management investment that needs to be put into building that product. Second, when you’re making the trade-off between the short term and the long term, are you positioned to be the most effective if you were to actually build out that long-term opportunity? The question I ask myself is, “How can we build out this product in a way that is going to serve the needs of this company as opposed to mimicking something that an external competitor does?”

For example, let’s assume your team realized that you’re doing a lot of development work for A/B testing across the company. One inference you could make there is you need an A/B testing platform, and you could just go out and buy something like Optimizely. But, you might realize that for some strategic reasons, buying is not the right thing to do. Instead, you need to build something in-house. Now that you’ve made that strategic decision, is your team best positioned to build out this solution for your company? Can you do that in a way that is differentiated for your company as opposed to, say, buying a generic product and integrating it with your company’s tools?

If the answer to both of these questions is yes, then I think you should prioritize building out that long-term opportunity. From there, you can determine how to best allocate your engineering resources to that long-term opportunity so that you can maximize certain KPIs. That’s the decision-making framework that I leverage. What I love about that approach is that it preserves focus.

How do you identify and prioritize problems that are overlooked sometimes, or those that maybe aren’t readily obvious, but could have the potential to drive some significant value?

As product managers, we are often in execution mode. We don’t get enough time to zoom out and think, “Could I be missing something?” What makes this especially hard is that you do not hear about these kinds of opportunities in obvious places, like in your customer support tickets or user research.

I’ve often seen this apparent externally — either with customers or competitors. As an example, Stripe and PayPal are both in the payment ecosystem, but they have a fundamentally different approach to how they’ve built products. Perhaps the first time you saw Stripe developing their APIs and building out beautiful documentation on their website, you couldn’t clearly see what they were trying to do, but now it’s obvious. Being able to zoom out and look at what your competitors are doing, as well as what kind of customers are gravitating to those competitors, gives you a very different philosophical understanding of the problem and reverse engineering that allows you to close gaps in your understanding.

Finding unobvious areas for growth

Do you have an example of a time when you uncovered something that wasn’t an obvious issue but had significant value?

I’ve worked a lot on payment methods, and one of the obvious things we always think about is how to make the day-to-day life of an existing customer easier. Say you’re operating in a certain geography where the credit card is not the most popular payment method. You’d likely think about what other payment methods would then make the life of an existing customer easier. However, the case you might not think about enough is how offering a different payment method unlocks a new customer segment or audience altogether.

For example, think about the audience in other parts of the world, such as India. There are payment methods like UPI, which is used by more than half the country. If you were to unlock those payment methods, it doesn’t just make the life of an existing customer easier, it helps you expand to new leads and convert them to customers. This is one of those less obvious areas that could turn into a growth strategy.

Do you find that taking the time to zoom out to the bigger picture, which then unlocks those unobvious areas, happens naturally? Or do you create intentional time for it?

Yes. I do that intentionally with a few methods. The first is by looking at competitor events and press releases. It’s also helpful to look at what partner events your competitors are being invited to and what they share at those events. Oftentimes, they’ll talk about trends, which can be a leading indicator for overlooked problems.

The second method is looking at some unobvious forums like Reddit to learn about customers, read company reviews, see what customers like about specific products, and discover new customer segments. Third, understand what the company and product strategy is trying to optimize for. For example, if your product is trying to optimize for global expansion, then you need to start diving into the intricacies of different geographies. If, on the other hand, your product strategy is to maximize coverage through a large number of features, then you have to start thinking about competitors that offer similar features and what those companies have learned to do or not to do.

Learning to pivot when it’s necessary

What is your process for figuring out that tipping point where the accumulated costs of an issue indicate that it’s worth addressing?

I think of the tipping point as an exercise where you constantly look forward and try to validate where you want to be 3–6 months from now. Then project where you will be in 12 months if you keep doing what you’re doing and evaluate if that’s a good position to be in. If you feel like that’s going to set you up for failure or be a large opportunity cost to recover from, I recommend pivoting as quickly as you can.

I’ve been in positions where I’ve waited long enough, only to realize that the engineering cost of investing in this long-term opportunity is so high that I cannot substantiate it. Do this evaluation as often as you can — perhaps quarterly as you are planning your roadmap. Think about where you stand and think about whether this would be a good position to be in six months from now. And if not, try and pivot sooner rather than later.

What approach do you take to predict or preemptively discover issues or address them?

I have worked a lot with financial and data teams to investigate what patterns we can uncover to achieve future forecasts. My goal has always been trying to do something 10x better and determining if the current path is going to help us get to that outcome. Those conversations and data analysis help you identify if you’re going to be in a good position or not. The other team that often has untapped macro insights is engineering. They are the core custodians of the architecture and infrastructure that you’re building out. They can see a lot of intricate details and loopholes in your system that you can identify early.

A good example of this is a scalability challenge. I’ve been in companies where we’ve optimized for short-term gains, only to get to a point where engineering solutions are no longer scalable. In those cases, we had to immediately pivot to something more long-term and sustainable. If you have those conversations early enough, you can flag those things and plan for changes.

Lastly, focusing on the task at hand could be an illusion and may not be the highest priority. How do you guide your teams to recognize that?

This is something that you have to be really intentional about. It helps to play the devil’s advocate for what you’re working on and perhaps think, “What if what I’m working on fails? Another great exercise that I learned from Shreyas Doshi is pre-mortems. If you’re working on a specific problem or solution, conduct pre-mortems to understand what could go wrong, identify risks that aren’t being emphasized enough, or uncover unknown risks. The “unknown unknowns” require more signal before you build out the entire solution.

When you do those things iteratively, you’re able to save yourself from the trap of thinking that the thing you’re working on is the most effective. Further, do problem discovery, which primarily revolves around asking probing questions. Ensure that you are placing your customers where they can be more objective and thoughtful about the entire problem space, and can clearly convey what problem is the most impactful for them.

I think the trap we often fall into is asking about specific problems and leading with questions about those problems. This only creates confirmation bias and validation from the customer. It’s more effective to lead with more open-ended questions and then zoom in from there. Customers also often have blind spots. A single conversation is not going to yield enough information, so make time to have customer conversations every week. Marry that with other forms of user research, like going on Reddit or user review platforms.

My biggest piece of advice is to widen your aperture and get as many inputs as you can so that your synthesis is stronger.