Designing Better Decisions: Business Acumen for Product Impact

Niyati Gupta at UXDX Community: Collaboration That Ships, Acumen That Sticks. Video: https://youtu.be/fYUDYas0qzc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Teams don't ship the wrong designs, they ship the wrong decisions

[00:00:08] Thank you. Hi everyone. I'm Niyati, and today I'm going to talk about something that we don't discuss enough in design conversations. It's not about craft, it's not about tooling and it's not about AI prompts, but it's about decision quality, because increasingly that's where the impact is won or lost.

[00:00:25] And here's the uncomfortable truth. Most teams don't ship the wrong designs, they ship the wrong decisions. I've seen beautifully crafted, deeply researched work fail, not because the UI was flawed, but because we were either solving for the wrong problem, optimizing for the wrong outcome, or just choosing the wrong bets. The execution was fine, but the decision wasn't.

[00:00:49] And AI is kind of making it worse. With AI, we can generate infinite polished variations in moments. Execution is faster, options multiply, but the judgment, that's where the game is kind of rigged. AI doesn't tell us what the right problem is to solve. The judgment and the decision quality, if they are weak, then bad decisions can scale faster, especially in the world of AI.

[00:01:14] And I've learned this the hard way. My career has moved from craft to strategy to leadership, and at one point I also became a PM. I worked as a PM at Google for a couple of years because I thought that's where the influence lived. But what I realized was it wasn't about the title, it was about the how of decisions.

[00:01:41] Working across multiple different kinds of teams, different products, high pressure, high growth, zero to one products, tall roadmaps and breakthrough launches, I've started to notice a pattern that is consistent. When decisions succeed or fail, it's rarely random. It's one of these three elements at play. Either success wasn't defined correctly, or we were not aligned on the success. Learning wasn't sequenced. Or tensions or trade-offs weren't explicit. These are the three levers now that I look for.

[00:02:23] Think of these three as steps. These are to me like structural conditions. If one of them is weak, the decision quality drops. So let's get into each of them separately, and I'll talk about where it all started. I'll start with defining success. I'll tell each of these as a moment in time, a real moment in my personal journey where I evolved these.

Defining success: Google Travel

[00:02:56] So the first one goes back to Google Travel. This was a long, long time ago, but I started noticing a pattern. Design was pitching bigger cross-journey ideas to leadership and none of them were making it to the roadmap. They were current ideas that were making the design and experience more coherent and good, but they were not making it to the roadmap. Only incremental small vertical optimizations were, those that ship fast, those that move numbers. And as a designer, that was frustrating, because the product felt fragmented to me and I couldn't quite articulate why.

[00:03:37] That's when I noticed that we were not misaligned on design. The intent was there, but we were misaligned on what success meant. Travel was a journey, but we were optimizing as a business for individual vertical clicks, not journey engagement. Design was pitching more of cross-journey movement, looking at travel as a whole, but individual verticals were optimizing for individual clicks.

[00:04:06] And the uncomfortable truth was I wasn't equipped enough to make that shift. I didn't have access to the metrics dashboard. I didn't know what metrics were actually moving and why they were moving. I couldn't argue with the language in the room, because design was talking about usability and the roadmap was talking about business impact, and I couldn't bridge the gap really.

[00:04:29] So I stopped trying to win the design debates. We stopped pitching the designs. We started, in fact, learning how the system works. I got access to all the dashboards, sat with data scientists to understand what's moving, what do we care about and what actually mattered. But the real shift didn't happen when I understood the business, it happened when I tried to influence it. It was about reframing success.

[00:04:55] So one concrete example: instead of optimizing for hotel click-through rates or flight click-through rates, we pushed for cross-journey engagement. Travel as a whole. Should we look at engagement as a journey? And that's what we started pitching. We stopped pitching for polish. We started pitching for systemic change, and for the goal or the success that we were optimizing for.

[00:05:22] And that's where the shift happens. Once the success was defined at the journey level, everything changed. We were able to pitch things like unified navigation, and it made it to the roadmap after years of advocating for it, because it made strategic sense. It made sense to the business now. It was driving a shared outcome. We weren't pitching polish, we were strengthening the system.

[00:05:50] And that's where design was invited early. We were embedded early, metrics were reframed to system level, design was shaping priorities, and we were basically in the room because we were talking the same language. We were moving towards a shared goal and success, and everything we were pitching suddenly made sense to leadership. It was not that we were debating each other, we were debating whether it made sense with the shared success or not.

[00:06:21] I do want to caveat though that metrics without judgment can create dark patterns. Metrics is a whole topic that I can give a different talk on, but here I do want to touch upon that I'm not saying we should be completely metrics driven, because without thinking about usability, trust and responsibility, if we just optimize for metrics, that creates dark patterns and that's not what we want. We want to create a meaningful metric system that drives success responsibly, and that is shared across different functions, and we have a shared understanding of it so we know where we're going as a group. That's where you will see a lot of conversations in the room also lead to less debate. But I wanted to emphasize that it's not just about the metrics, guardrails are important.

Accelerating learning: Netflix and the hypothesis

[00:07:21] I'll move on to the next one. Once you have defined success, the next thing is, when you come up with solutions, are you optimizing for design, or accelerating learning, optimizing for learning? This hit me hard at Netflix. When I came into Netflix, I was this designer who always felt like I come up with really thoughtful solutions. I look into problems and present really thoughtful solutions. And when I was presenting my thoughtful solutions, people would come to me and ask, what's the hypothesis? And it almost felt like critique. It's like, what do you mean, what's the hypothesis? And underlying that, they were trying to understand what are we trying to learn with this solution. This is Reed's quote that we always refer to at Netflix: we make informed bets and test them quickly.

[00:08:20] So what happened was, when I worked at Netflix a shift happened. I initially used to think my job was to come up with solutions, have the answers, defend my solution with good rationale. But then I shifted to framing my solutions as learning bets, inviting discovery. How can we learn together and find clarity? And I suddenly saw the room shift. We were not debating the design of the solution, is this the right design, is this the right solution, but we were debating is this the right thing to learn and how can we learn it, how can we get to clarity faster? And the egos in the room dropped.

[00:08:57] And when I say hypothesis, I want to make it a little more concrete so people know it. They look something like this: if we do this, we expect this change, because. So, if we reduce friction on step two, drop off should increase, because users won't stall at the decision points. And here the example is about metrics, but it could be about user behavior change, it could be about a lot of other things. But this makes it really concrete. What are you trying to learn and what your assumptions are, it exposes those. So you're not debating the exact solution or design, but you're trying to learn to get to that ideal success state.

[00:09:37] Again, a caveat here: you might have 100 unknowns that you want to get clarity on. That does not mean you need to test them all. Testing everything is noise. But you need to identify the riskiest assumption, and the one that you think is the most critical for us to make the decision and get to clarity faster. Creating that discipline to clarity, not an experimentation theater. You don't want to have 100 things you're testing, but being very strategic about getting to that clarity faster, not always just shipping faster.

Structuring tension: Google Meet during the pandemic

[00:10:16] Let's move on to the last and the place where I think there's the biggest tension in the room and most of the debates happen, which is structuring tension. This was back in Google Meet during the pandemic. So, fun: I decided to become a PM during the pandemic at Google Meet, which was probably the most demanding area. The product was exploding at the time. The demand for the product was exploding. Everybody was going online and running meetings at Google Meet.

[00:10:54] So our roadmap was overloaded. We had requests coming in from internal and external audiences. Design had this vision. There were things coming from a security standpoint, parity, collaboration, reliability, UX polish, and everything had merit. Everything had advocates. The problem wasn't ideas, it was about the competing forces. How do we prioritize which one to get to? Everything seems like the right thing to build, but we have limited resources.

[00:11:25] And there was this one meeting where we debated for 45 minutes whether we should be doing background blur versus grid view. It was a feature argument, but to be honest, it wasn't. Every role was trying to protect something. Engineering was trying to protect stability and reliability. Product was trying to protect growth. Design was trying to protect coherence and usability. Leadership was trying to protect differentiation. And no one was wrong, but the forces were invisible. We were debating features still, but we were not debating what are we optimizing for, what are the tensions.

[00:12:05] So after the meeting, we went back, and instead of asking what features are better, we started asking what spectrum are we actually debating. Is it about short-term lift or long-term advantage? Is it about velocity or technical depth, parity or differentiation? Once we named the tensions, the conversation changed. It wasn't about the features. It was about what were we optimizing for, what were the tensions that we can map out on, and the debate changed. We were not debating features, we were mapping the forces and choosing very consciously.

[00:12:38] So in the next meeting we didn't bring mocks, we brought a roadmap balancing proposal. The proposal was, let's do 60% short-term, 40% long-term. And it is not about compromising, it's about consciously deciding, conscious allocation, principled allocation. And then the tensions were explicit. The decision was made much more smoothly, because it was principled. It was based on, this is the tension that we have, but we are trying to optimize 60% this, 40% this. And that made sense to all of us. We were not debating just features anymore.

[00:13:17] So what happened before was the tension was implicit. It felt like it was a personal debate. We were going in circular arguments, and just egos in the room were debating each other. But after we named the tensions, it was principled. It was faster alignment, stronger commitment, and we could all get behind that. We trusted each other. We were like, okay, we're aligned on this is why we're prioritizing what we're prioritizing.

Recap: the three levers

[00:13:52] So I'll recap a little bit. This is where I feel, when the hard product decisions fail, usually it's one of these three things. This is the operating system that I personally have devised for myself, and I advocate in any team I work in to implement that.

[00:14:13] Defining success: to always start with what is the shared goal, how are we defining success, is it balanced, is it ethical, or is it just one-sided? Just questioning it. Not just learning how the business works, but questioning it and making sure we're moving towards the right goal.

[00:14:35] The second is accelerated learning. So not just coming up with solutions to launch and shipping faster, but coming up with ideas and solutions to learn faster together. What are the assumptions? What are the risks that we need to clarify? What are our learning goals, and creating a system for learning them faster? It's not just about running experiments, it's about getting to those questions and trying to find the answers for them, and the answers could be in usability prototype testing, data, user behavior, click behavior, or just A/B testing. There are a lot of ways you can get to that learning, but what do you need to learn, structuring that and getting to learning.

[00:15:20] And last but not the least is structuring the tensions and trade-offs. How are we prioritizing things in the roadmap? What are the spectrums we need to debate? What are the tensions? And just naming them, putting them out there so we can talk about them, rather than them being implicit and then it being about the egos in the room and debating the features, rather than, these are the tensions, we need to map them out.

[00:15:48] So in a world full of AI where creation is really fast, options are infinite, your leverage comes from decision-making. So if you were to go back to your team tomorrow and think about how decisions are made on your team, ask yourself: is the success clearly defined, or are we debating tactics still? Are we learning the right things, reducing the right uncertainties, or are we just shipping faster because we need to? Or are the tensions explicit, or are we just still being very conflicting and debating and going in circles? If one of the levers is weak, that's your leadership move. Try to see if you can do one of these three things to strengthen decision quality in your team. That's about it. Thank you so much for listening. I think we have about 10 minutes for questions.

Q&A

[00:16:45] Host: Excellent. Thank you very much. That was a great example with three very specific instances, and I guess for me, I personally know the products so it adds that little bit of extra. So if anybody has any questions, please write it in, as I said, on whichever platform you're on. We already have our first question so I'll jump in with that. This is from Kira, who said this is such a sharp breakdown of why hard product decisions fail. In my work with rehearsal mode I found that even with structured tension and defined success, teams still hit that approved then reopened wall, because the decision rights aren't locked into the rehearsal phase. It's the corporate version of a director giving a major blocking note five minutes before the curtain rises. It creates chaos. Solving for that truth, timing is how you actually make these design decisions. So I guess the question there is, yes, you can put in place all of that upfront, oh well, let's structure it this way, but people still have their pet projects that they're going to push through. So how did you deal with that?

[00:17:57] Niyati: That happens. I feel like when these things are in place, you have some leg to talk about and push back. It's not that you always need to push back. I do feel like first evaluate the idea that is coming in from a different leadership standpoint. Understand what lens it is coming from, and does that actually align with the three things? Does it align with the shared goal? Does it get us to learning faster? Does it map on one of the tensions? And if it does, it's worth talking about. It's not about immediately rejecting or pushing back, but evaluating them against the system and then making sure, oh, if it does, then let's talk about it.

[00:18:42] Niyati: But if it does not, you have some leg to stand on. It's like, we aligned on this goal to start with, and if we are moving away from it, let's talk about why, and then do we need to rethink our goal? And then, what are the things that we are pushing, does that goal, does that success still remain the same? That's worth debating, because now you have a concrete thing that everybody aligned on. If you're moving away from it, then you have a very concrete leg to push on.

[00:19:16] Niyati: And there will be instances where industry pressure rises with the AI, like you have to ship some things like yesterday for competitive pressure, and that's okay. Then your success is not just defined by engagement there, but it's also defined by industry success, and you should bring that lens into your success. And even in the spectrum, I think differentiation is important or parity is important, and let's map that, and then moving forward anything that comes in the roadmap is kind of, so adjust your scales accordingly. Don't push back just without evaluating, and if you have to push back, use those pillars or levers to push back, is how I have approached it personally.

[00:20:03] Host: Great. And in those instances, because I've been there, I've had those conversations and you get it agreed and then the next day somebody comes back and they've been thinking about it, I've got a better argument. Do you have a final say as the PM, or what's the way that you short circuit that never ending back with another angle tomorrow?

[00:20:24] Niyati: I've seen this work differently in different teams. At Netflix we actually have a product owner. We call them informed captains, who have the final say. They're usually engineers or PMs, but sometimes they're designers as well, depending on the project. So you have an informed captain that makes the final call, and at Netflix I've seen that, but in other teams I have seen it being a collaboration, being a PM call. But I feel like, the more you guys do it as a team and create those forums, like this is the forum where the core team will come together and make the decision, if you're still not able to, I think assigning that one person who's like an informed captain, who can take everything everybody's pitching, learn different perspectives and make the final call, makes sense. But I think creating that space for those debates, and assigning roles and those relationships: this is a core team, this is a team whose input is really, really important, these are the four people whose input is really, really important, but this is the one person who, if we go to a stalemate, this is who's going to make the decision.

[00:21:40] Host: Great. And we actually have a question that aligns with this now coming in from Fernando. So first off she says thanks for such an inspiring and clear talk. But her question is, what would you say was harder to put in place of those? As you just mentioned there, you had to put in place some kind of conditions that everyone agreed on. Could you share some learnings and strategies you used to get buy-in from your peers and teams?

[00:22:03] Niyati: Yeah. Let me see if I can talk about one of these three very concretely, and I'll give examples so it's contextualized a little bit. I'll talk about the travel example where we were trying to define success. That was a shift. We were so optimized for individual vertical revenue and CTR, so that's a shift, to think about the business as a cross travel journey, rethink our metrics.

[00:22:35] Niyati: I think what we did was ground it in concrete research that we had. It was not just design pitching it because it felt like an easier usability fix. We saw concrete data that people were doing those searches one after the other. They were going to Google search and doing a hotel search, and like the next day or in a couple of hours they were doing flights, and they were going back and forth. So it was a journey, it was not a linear path, and individually they were thinking just hotels. They were taking a trip and they were looking at all these different places, and we saw it in the engagement numbers, but we also saw it in user research. There was so much foundational research where people were talking about this. So we brought that forward. So it was not one person's opinion, it was grounded a little in the data and user behavior we were seeing in the past.

[00:23:32] Niyati: And we surfaced what was breaking down when we think about it in silos. We were missing this, and we framed it as a business opportunity. We were missing the cross journey. We could drive people from this product to this product very easily and actually increase the engagement there as well. So this was a missed business opportunity, not just a design opportunity, and that's where the unlock happened, to having a shared language to talk about. And this is my whole talk's crux, why business acumen is really important: you can have that shared language that you can talk about, and it's just easier to communicate that way.

[00:24:10] Niyati: So if I had to go back, it was that shared common language, grounding it in some data or research, it's not one person's opinion, it has a little bit of a rationale behind it, and then being very clear about what you're trying to push for. It's not just, you know, I don't agree with the PM so I want to push back, but it's like, I have a very concrete solution or metrics or success goal or tension that I'm trying to push for, and why.

[00:24:40] Host: I found it helps if people are aligned on a similar KPI. I've worked in a place where I've tried to explain this is better for the business, but their bonus and everything is based on their individual siloed KPI. So they're like, yeah, yeah, that's better for the business, it's better for the user, but this is better for me. So there can be a tension there that can be quite difficult to deal with.

[00:25:05] Niyati: It always is. And that's why I think that shared language, I understand that, I feel like you also have to meet the person where they are, but it could also influence that specific KPI that you care about when we change this.

[00:25:20] Host: Yes, so speak their language. I guess, just on a personal note, you mentioned you pivoted to PM but you pivoted back. What was your rationale for both moves?

[00:25:32] Niyati: Oh, that's a question I get so many times. So my rationale for going to PM was, as I mentioned, I felt that that's where the influence was. That's where I would be more strategic. That's where I would get to define the roadmap and define what success is. But I felt like that was true, but that was a very small part of the job. The job was much bigger. It was a lot of people skills as well. It was a lot of just managing debates. And it is an unforgiving role, because you're responsible and on the hook for everything that you don't do.

[00:26:17] Niyati: So personally for me, the portions I enjoyed as a PM were something I felt like I could do as a design leader as well. I could drive influence, decision-making, strategy as a design leader as well, and I don't have to be a PM for it. And the things I didn't enjoy were actually unique to being a PM. So I stepped back and I was like, I think something needs to change in how I work as a design leader, rather than me completely changing my role, to drive the things that I want to and enjoy. I started doing more of strategy. I started doing more of driving zero to one work, because that's what I love and enjoy. So I stepped back and came into the design leadership role.

[00:27:06] Host: Excellent. Thanks for sharing all of those case studies and your experience. I think that pretty much brings us to time, so I just want to thank you once again for sharing, and I hope everybody out there enjoyed it as much as I did.