Umesh Unnikrishnan is VP of Product at Branch, the leader in mobile deep linking and attribution. Umesh leads a team working on consumer-facing experiences, monetization, and partner integrations. Before joining Branch, Umesh worked for some of the most prominent companies in tech, such as Microsoft, Google, and Pinterest.
In our conversation, Umesh describes his experience taking products from zero to one at early-stage startups and how that process differs at a large enterprise. He also talks about the importance of setting KPIs and OKRs that people can actually control so that teams can measure success without external distractions.
When you’re building an MVP, it’s very easy for product managers, engineers, and designers to think “We know what we’re building.” And almost always, we end up building something that we think is perfect but no one actually wants. Therefore, my number one rule is to not go too long without talking to customers.
When I say talking to customers, I mean actually talking to the people who will use your products. At a big company, there’ll be people in between you and the customer — salespeople, marketers, user research people, all of whom are proxying the customer to you. But unless you talk to a real customer, you don’t really know the problem they’re facing.
One of my favorite examples is from almost 10 years ago when I was at Google. We were building some advertising tools and one of the requests that came in was to build an iPhone app version of our tool. It was a fairly reasonable request, and mobile was booming.
My engineering lead counterpart and I, coincidentally, happened to have a customer visit at the same time. We went and visited this particular customer who had asked for this, and I talked to the team that actually made the request.
I asked them how they would use this iPhone app they requested and they said, “We work with a large airline that’s our advertising client, and they launch all of their campaigns at midnight on Sundays. That’s when the sales go live.” So, what they really wanted was the ability to launch campaigns from home on a Saturday night, i.e., they needed a scheduling feature, not an iPhone app. And that was a much easier thing to build than a whole new app. A win-win for us and the customer.
Whenever I think about success and scale, there are different stages that every product goes through. The first is the invention stage. Here at Branch, we’ve gone through many iterations of building various products over the course of a few years. That’s our zero-to-one product-market fit invention stage of a project.
After that comes the scaling stage. We’ve gone from zero to one, so now we need to scale it to a hundred or a thousand. That’s a lot of what we’ve been doing over the last couple of years.
A lot of the initial part of building any product is trying to find that first set of customers for whom it works really well so that they become advocates going forward. My philosophy is that it’s always better to find 10 customers who love your product and are willing to vouch for it than to find a thousand customers who are lukewarm about your product.
At its core, the processes are somewhat the same. In both cases, you’re trying to figure out the product — building an MVP or prototype and figuring out which market would fit the best. That’s loosely how most teams tend to approach PMF.
I think the two things that are really different are timelines and resources, and what success and failure look like in each case (as in what’s a good and bad outcome).
Paul Graham said, “You’re either default dead or you’re default alive.” With startups, you’re always in a default dead state. At a large company that’s generating revenue and has existing products, you’re default alive. If you don’t exist and you don’t do anything, the company still lives. At startups, it’s the other way around.
At a large company, success would often mean figuring out a product and then figuring out how that product fits into the larger strategy. A best-case outcome for a zero-to-one effort in a large company is that it gets absorbed into some larger business, and then you get the resources of that larger business to scale and extend it. At a startup, if you build something, you’ve got to figure out how to take that scale and make it a sustainable business. There’s no savior out there for you; you kind of need to figure it out yourselves.
At Google, I was working on monetizing image search. That was a zero-to-one effort because it had been tried in the past and didn’t quite work.
I had some experience doing that at Pinterest, so when I went to Google, I said “Let’s figure out how to monetize image search using some of the existing ad demand that we have.” We took about a year and a half or so to figure that out and show that there was a potential for a huge revenue opportunity there. The eventual goal was that we got absorbed into the larger ads organization and that was a successful outcome.
First of all, I’m a huge fan of the OKR process. There are variations of this, but a lot of it boils down to having to write a goal and communicate what the goal is. The more specific and the more measurable that goal is, the higher the chance of success.
Organizations spend a lot of time figuring out what that goal should be. At Google and other large companies, we spent a lot of time debating whether a particular goal should be 20 percent or 25 percent.
The advantage of this process is that you have clarity for the entire organization on what your goals are and you’re able to share that broadly. Anytime you’re in a meeting, you can point at the goal and say, “Our goal is to hit a 20 percent growth rate this quarter and this project is very important to achieving that.”
That’s why this is important — it brings that clarity of purpose across the organization.
It’s vital to be sure that when you’re aligning a team around an OKR or North Star metric, it’s a metric people can actually affect.
Revenue, for example, is a very poor KPI, although a lot of organizations do use it. Unless you’re a sales team and you’re actually the ones collecting the dollars, you don’t have control over that revenue. You might do all the right things and still not hit it because of market conditions or because the company that you were trying to sell the product to had an organizational change and your supporter is not there anymore.
Metrics like revenue are often lagging metrics. You could do things this quarter and then have that revenue only hit next quarter. Those are all reasons why it’s a bad idea to have those kinds of, what I think of as output metrics, as your KPIs. Instead, you want to have input metrics as your KPIs.
For a product team, that could be something like launching product X or v2 of product Y and getting it adopted by 10 customers. For an early-stage project, it might be something like figuring out how to do X or getting the first meeting with a client. Those kinds of early-stage things might be more appropriate for an early-stage product.
Another thing to remember is that an OKR doesn’t necessarily have to be a KPI or an actual metric; it could be a milestone as well.
I use an XY chart. On one axis, and this is specifically in the context of advertising, you can either have no ads (where you have a lot of users but no revenue) or lots of ads (where you have a lot of revenue potential, but no revenue because you have no users). There’s a happy medium you need to hit between these two. A lot of effort is usually spent figuring out that magical moment or that boundary condition where your ad can maximize revenue.
It’s very important early on to establish that there’s usually a trade-off between customer happiness and revenue, especially if you’re talking about a consumer advertising-funded product where there’s a lot of healthy tension between UX and ads. As a person on the revenue side, you need to be deeply respectful of the user experience so that you don’t lose credibility.
Early on, you have to build a model that shows the cost of ads compared to user experience. What’s the relationship between users and how much revenue you’re generating? The naive approach is always to show more ads to users. That’s how you end up with crappy news websites and things like that with popups and autoplay videos. You should then discuss how you can grow users in pockets of markets that are highly monetizable and how to make each user who’s viewing an ad more valuable.
Last year, we found that we didn’t hit our goals on the product that I lead right now. It happens a lot in many projects, but as we got to some of the core of why we didn’t hit these goals, there was a lot of finger-pointing. We built the product, so some people said sales didn’t sell well. And sales said, “No, the products were delivered late.” This is usually a good indication to leadership that all is not well — these teams have actually not been working together.
As a leadership team, we decided that we needed to be spending a lot more time together. If we can’t be aligned as a leadership team, our teams are not going to be as aligned either.
We started by blocking two hours every Monday for the full leadership team to talk. It was a little awkward in the beginning, but it was key for us to be aligned. As it went on, we realized that, as a leadership team, we were often misaligned on goals, priorities, and so on. Soon, these two hours became not just status updates, but working sessions on product strategy, our sales strategy, etc.
We realized some fundamental flaws in our operating model and our strategic goals. By the middle of this year, we were able to use that as a way to reset some of our goals and realign for 2024. We then started spilling off on those two hours and realized we actually needed even more time together. As long as we were all aligned, everything below us at the operating team level would go a lot smoother.
Cross-functional communication is really hard. I think there are different strategies for individual product managers versus a product leader but, in general, I break it down into three steps.
Step one is figuring out who the key cross-functional partners are. This varies a lot from team to team, company to company. You really need to understand who your core team is — the one that’s actually making decisions. As long as you are aligned that this is the core team, that’s the team that’s actually owning the product. And within this core group, you should have very high bandwidth, very high-in-frequency conversations.
The second step to that is thinking about everybody else who needs to be informed and consulted. For example, when I worked on FinTech products in the past, Risk and Finance were always key parts of those cross-team stakeholders because they needed to create models and tell us how much money we’d lose. In this layer, you can have less frequent but more polished communications.
And finally, you have to think about keeping everyone else at the company or organization informed. Maybe you’ll do a monthly email or quarterly town hall that you present at that gives everyone else an update as to what’s going on.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Discover how ECRS helps product managers eliminate waste, simplify workflows, and drive efficiency across fast-growing teams.
Turn your SaaS product into a platform by spotting key signals, avoiding common traps, and building for scale, reuse, and integration.
Learn why the shift from three-in-a-box to full-stack product leads is redefining product roles, collaboration, and career growth.
Learn how product-led cost management improves margins, maintains velocity, and creates user value through a repeatable playbook.
Learn more →
