Leader Spotlight: Balance vs. compromise in product management, with Suvrat Joshi

---

Suvrat Joshi is Senior Vice President of Product Management at Nintex, an AI-powered platform for business process automation and application development. He began his career in consulting, working for Microstrategy, Vastera, and JPMorganChase. Suvrat then transitioned to tech, where he joined program management at AOL before moving to product management at Yahoo. He then spent multiple years leading product at FAANG companies, including Amazon, Microsoft, and Facebook, before moving to Dropbox. Before his current role at Nintex, Suvrat served as CPO at both FarEye and Veriff.

In our conversation, Suvrat shares the importance of viewing trade-off decisions in product management more like a balance than a compromise. He discusses how he encourages healthy pushback on his teams, including by promoting a culture of open, honest conversations. Suvrat also talks about how he leads his teams to be data-driven without becoming data-blinded.

---

Adopting a mindset for balance

Today’s product teams are often pulled in multiple directions. As a product leader, how do you personally define ‘balance’ vs. ‘compromise’ in these scenarios?

For sure. PMs often get pulled in different directions, often with various dimensions involved. Sometimes, you may need to make a trade-off between immediate revenue, the long-term platform, and customer success. These are the sorts of things teams have to talk about all the time, and you have to make these calls. In most cases, these are thought of as compromises. It’s easy for a PM to get lost in this or fall into a trap.

In my opinion, a stronger approach to take would be to think of this more as a balance. If you think about this as a balance and less of a compromise, that changes the mindset and approach that could be taken. The keyword here really is “balance” — it can be across the many areas that PMs juggle daily.

Balance can be across several dimensions like customer, product, business, or short-term revenue and long-term success, conflicting metrics at times, etc. The key is to balance these and find the best path. Another aspect of balance is in the linearity of decision, which is a fancy way of saying to achieve balance over time. For example, the PM can pick revenue as the goal now, and for the next feature, maybe the PM amplifies the customer experience. So, in this case, there is a balance over time. I would really encourage PMs to think about this balance.

Can you share an example of what achieving this balance looks like in practice?

A while back, when I was working at a startup, the team had to make some choices around immediate customer revenue and a long-term trade-off. And a lot was at stake. Typically, in a startup, when there’s a board meeting coming up, there’s a critical customer win, potential fundraising, and other factors. Here, rather than do some kind of a mid-ground compromise, the balance was essential. We took the short-term revenue path and got to an immediate win. We had some other nice, intangible wins as well.

The team moved incredibly fast and benefited from that quick turnaround. We were able to improve customer experience, and then, a few months later, accomplished what we wanted to do. That nifty customer experience, combined with the immediate win, was a great example of achieving balance over time.

Encouraging healthy pushback

How do you help junior PMs distinguish between productive tension and misalignment when facing hard decisions?

I wish there were a scientific formula or rubric here, but there aren’t any. A couple of things come to mind, though, like identifying if something is a pattern or if it’s a one-off. It happens all the time. A pattern is probably an indicator of something different, like fundamental misalignments, rather than a healthy creative tension that occurs once in a while. It’s good to suss that out.

I also think it’s worth looking at the subtle dynamic. Sometimes, you just sense it, and that’s more of an art than a science. You can sense that the dynamic is off and that the interaction feels forced or ingenuine. That’s a case of a harder misalignment as well. But if there’s a pattern, you can bring metrics or other things into it to resolve the problem.

In terms of techniques, transparency and clarity in any conversation are really important. That’s fundamental for me. If the intent is clear and good, it’s a matter of realignment on goals and metrics. Those, in combination with transparency, clarity, understanding, goals, and metrics, are the starting point. Have that candid conversation. Figure out the gaps, work through them, and move forward.

What’s your approach to building a culture where PMs feel empowered to push back thoughtfully rather than default to compromising under pressure?

I’m a huge advocate of open, genuine, honest conversations. That applies here as well. If issues aren’t surfaced, it’s really hard to address them. If you don’t even identify these issues, how do you really figure them out, and how do you address them? It could be a product, process, or another issue in the general product domain, but the same philosophy applies. The best leaders that I’ve worked with all practice this to some degree in different ways.

The second thing to call out is that there are a lot of communication styles. You can pick your favorite communication framework, but there are a lot of engagement patterns. Understanding them creates a good awareness, if you will, because it helps everyone express themselves in the right way and resolve disagreements healthily.

For example, some folks might prefer an in-person conversation to voice out that disagreement. You’ve got to give that forum for that individual to do that. Others might prefer a written way of sharing feedback, like through Slack or a document. You’ve got to be flexible to meet people where they are in their preference of communication style, for both the feedback provider and the receiver.

The value of transparency

How do you go about figuring out what someone’s communication style is and how they like to get and provide feedback?

There are lots of things you can publicly post for others to learn about how you consume and share information, and vice versa. I’ve been in companies where individuals posted their Myers-Briggs personality types, which was helpful and telling. When I started here, for example, I posted a three-page “get-to-know-me” doc, which is open to everybody in the company. I republish it every six months so new folks can get to know me and learn how to work with me. I’ve gotten very positive feedback about it.

The other thing I would call out is to lead by example. Not everyone is a fan of public acknowledgement, but public recognition of something good that happened is a morale booster. You can say something like, “Hey, the pushback was great on this. We took that input and incorporated it, and here’s the outcome.” Recognizing that invariably creates a positive loop so individuals feel like they can share their thoughts and have them taken the right way.

Along the same lines of feedback, how do you navigate situations where customers ask for customizations that may jeopardize the product’s long-term platform strategy? What’s your approach to incorporating feedback without compromising on your product integrity?

It comes back to balance. PMs are at the center of so many functions, but also straddle between doing art and science. At times, you have to pick short-term wins and say no. There’s a lot of value in transparency — not just internally, but with the customer as well.

One thing that has worked well for me is to bring up that exact trade-off and choice that you called out. You can say, “Hey, this short-term need doesn’t really align with our long-term strategy.” Often, when you bring that to the customer, you’ll be surprised that they recognize the challenge. If you’re open with them, that providing that customization now means delaying another feature by six months, they’ll understand why you’re saying no.

Customers usually understand, and they can provide some really interesting insights and feedback to allow you to make that choice together. And that also makes the customer happy because they were part of the process. It’s great for the product team as well because you’re bringing the voice of the customer back into the decision.

Data-driven goal setting

What are your best practices for establishing a consistent, org-wide definition of success metrics — especially when product, design, GTM, and ops may all speak about data differently?

Any sort of data-driven goal-setting mechanism is great. OKRs are very popular, and we use them at Nintex. There are plenty of other similar frameworks that would work well, and I think that anything that establishes a goal, metric, and set of actions will help.

One thing that’s often missed is cross-functional goal sharing. There’s GTM, product, design, engineering, operations, sales, and more. If you have a shared goal, that’s amazing. I’ve found that the more the goal is siloed into one function, the more likely failure is.

For example, engineering may have some velocity metrics, while GTM may have demand generation metrics. If all of that feeds into an overarching company-level metric, it all ties together nicely, and then everyone can identify with it. Otherwise, it just becomes a siloed functional metric, which is hard to tie back to a company-level goal in OKR.

Have you found a good approach in terms of how often you should set goals?

It depends on the pace of the organization. Typically, an annual goal makes sense — it goes with the budget cycle and everything else. But often, 12 months is too far of a horizon for fast-moving, early companies. In that case, breaking it down into quarters is usually reasonable. In some cases, I’ve done even bi-weekly goal setting in situations with very fast growth.

Some sort of a breakdown with smaller granularity than annual works really well because it allows you to do course corrections. If you wait for a quarter, then your course correction mechanism typically is the same length. In a year, you only have three or four chances to course correct, but if you do it monthly, you get, let’s say, 12 chances to course correct. That’s another way to think about it, but it depends on the pace and growth of the company.

Treating data as a must-have

From your perspective, what changes once the mindset shifts from reporting to data-driven decision making takes place?

I’ve tried to encourage more data orientation, not just for reporting, but also for decision-making. That’s where the power of data shows up — by trying to embed it into routine decision-making or the routine cadence.

For example, if you have sprint routines or sync mechanisms, these are great places to bring the data in and identify gaps. Or, if you actually have data, then start tracking it so you can identify what you need to do with it. Making that part of the routine is a great unlock, and also encourages that data orientation. The key is to not just focus on the metric itself, but graduate to ask, “What do I do with this metric? What’s this metric moving? What decision do we make with it?” That’s pretty powerful.

How do you ensure your team remains ‘data-driven’ without becoming ‘data-blinded?’

It’s important to treat data, first of all, as a necessity. It’s a must-have. With that, the notion of balance comes in. You’ve got to look at data as a guardrail, because when it becomes an end-all be-all, that balance tips into being counterproductive. This is where you need to draw from both quantitative signals and qualitative insights, like user feedback.

For example, with hypothesis-driven thinking, you have a hypothesis, you go test it out, and that’s awesome. But if you are so fixated on that one data point without taking into account customer or user experience feedback, you can still argue that it’s still data, but you’re not accounting for other leading or lagging indicators.

Overall, a dashboard is important, but it can’t take you away from good judgment and context. Those factors still play into making the decision and the ultimate call. That’s the real differentiation between being data-informed versus data-blinded.