In this episode of The Optimal Path, Ravi Mehta talks to Maze about connecting user research to product strategy and integrating effective product decision-making frameworks.
In this episode of The Optimal Path, Ravi Mehta talks to Maze about connecting user research to product strategy and integrating effective product decision-making frameworks.
Ravi outlines the importance of visualizing product strategy—from the company's mission to defining specific product goals—and how to balance intuition, analytics, and user feedback to make confident product decisions.
Discover how these methodologies can refine your strategy and product development approach, setting a clear path for product success.
About Ravi:
Ravi Mehta is a visionary product strategist known for crafting innovative strategies that transform industries. He has held several prominent roles, including Chief Executive Officer of Outpace, and is an active angel investor and advisor in consumer tech companies. His past positions include Executive in Residence at Reforge, Chief Product Officer at Tinder, and product leadership roles at Meta, TripAdvisor, and Xbox. Ravi champions a human-centered approach to building products that has notably influenced the tech sector. He continues to help shape the industry by sharing his experience and frameworks aimed at improving product strategy and execution.
Connect with Ravi
You can connect with Ravi on Linkedin, follow him on X, or visit his website.
Resources:
Follow Maze on Social Media:
To get notified when new episodes come out, subscribe at maze.co/podcast.
See you next time!
Ash Oliver:
Product decision-making is an art and a science. While the outcomes of decisions are usually apparent, the formula for consistently getting them right often remains a mystery. So how do you hone product thinking in a way that ensures stronger decisions and better product outcomes?
Ravi Mehta:
Statistical significance is not enough. More important than that is informed conviction. What is a set of evidence that you need to feel like you have conviction around a particular decision? I'm excited because it feels like more and more companies are taking that sort of approach to building products. And as a result, I think we're seeing products that are more human-centered, more design-centric, more research-driven, and ultimately do a better job for the customer.
Ash Oliver:
Today on The Optimal Path we're uncovering how to think about product decision-making, balance the inputs of evidence, and construct clearer strategies. I'm Ash Oliver and this is The Optimal Path, a podcast about user research and product decision-making brought to you by Maze. Our guest is Ravi Mehta. Ravi is the CEO of Outpace, and an active angel investor and advisor in consumer tech companies. He's previously held positions such as executive and residence at Reforge, CPO at Tinder, and product leader at companies like Meta, Tripadvisor, and Xbox. I'm really excited to have you here to discuss our topic. Thanks for coming on.
Ravi Mehta:
Thanks for having me. I'm excited for the conversation.
Ash Oliver:
You're well-known in the product management world. You write extensively on the topic of product strategy and product leadership. You've been an Executive In Residence at Reforge teaching this material. You have a breadth of experience gained through your years at tech giants like Meta, Tinder, Tripadvisor. As you know, the podcast focuses on product decision-making through the lens of research and user understanding. Although I think the PMs listening will find this topic very close to the work that they're doing, I think anyone within the greater RPD team will find this valuable in how to develop product thinking, how to connect research to product strategy and company vision, and ultimately how to make stronger product decisions. To dive in, I thought we could start by having you describe what you've referred to as the three pillars of product decision-making.
Ravi Mehta:
I have a post where I go into this in more detail. The question I was really trying to understand is how can product managers and product leaders make better decisions. In fact, how can anyone on the product development team make better decisions? And if we zoom out to the essentials, there's really only three different inputs into decision-making about our products. There's our own intuition, so what is our sense about what customers want and what the right product is for them? There's analytics, so what is the data telling us? And then there's customer feedback which is, what are we learning from our conversations with customers? And the fact that we have these three things: intuition, analytics, and feedback is really important for us to be able to make balanced product decisions that actually draw from all three of those inputs and help us get to something that has the best chance of having the best answer.
But the problem is that every single product person I've worked with, every single team, and every single company I've worked with has bias towards one mode of decision-making or another, depending on that person's experience and depending on the culture of the company. What's really important is for us to understand those biases and correct for them. And make sure that we're making decisions in a really balanced way. So some product folks and some teams are very intuitive, they'll have a good sense about what customers want. But the problem with intuitive decision-making is that if it's not underpinned with data and with talking to customers, sometimes that intuition can be wrong and that can lead to a lot of swings and misses.
One of the things that's been really common over the last 10 years in product is analytical-based decision-making. In fact, some companies have taken their own intuition out of the equation and said, "Hey, we're going to build our product as a result of experimentation. So we're going to run an A/B test, and if an A/B test works we're going to ship it, and if it doesn't work we're not going to ship it. There's a lot of products in the market today that are the result of experimentation. And in many cases, those products operate at a way that's really optimal with respect to particular metrics. But the problem is that oftentimes those products don't intuitively feel good. They feel like the accumulation of lots of different experimentation. They feel like sort of a Frankenstein that's been put together from different component parts. And so analytical decision-making is great because it's evidence-based. But in the absence of intuition, and the absence of customer feedback, and customer empathy, those experiences can feel overwhelming and clinical relative to things that are designed in a more balanced way.
And then lastly we have feedback. It's incredibly important to talk to customers in order to understand what they're thinking, in order to really empathize with them, and understand how our products fit within their lives. But taken too far it means just doing what the customer tells you to do. And that can get you so far but it can't get you all the way to the end result.
So the example I like to use in this case is ... At the time that Apple was building the iPhone, BlackBerry was the most popular phone in the world. And one of the things that people loved about the BlackBerry was the little chiclet keyboard that enabled people to text and email quickly. And nobody at the time was saying, "I don't want this keyboard, that this keyboard is getting in my way, I want a completely screen-based device." Customers don't have that product intuition and that product foresight and so they can't always express the solution but they might be able to express the problem or parts of the problem. And so customer feedback is really important. But if you over-index on customer feedback you can only ever build what the customer understands and is able to tell you and you can't go beyond that.
And so ultimately, all three of these different decision-making models: intuition, analytics, feedback are incredibly important to be able to make balanced decisions and actually feed off of each other. Analytics and customer feedback actually helps hone intuition. On the other hand, if you're looking at data you need some intuition to interpret what it's really saying and to understand when the data's pointing in the right way or the wrong way. And then customer feedback can really help you color in that data. And then lastly with customer feedback, it's important to have intuition or product sense to really understand how to pull that feedback forward and understand what to do with it. And then it's important to use data with customer feedback as well so that we can understand what's happening at scale amongst all our users rather than something that might be just a problem of a single user or a few.
Ash Oliver:
There's so much there. I love the visualization of this triangulation between intuition, analytics, and feedback. Are there are any principles or techniques that you could do to try to shift the company towards a more balanced approach if you do recognize that you're in one of these three categories?
Ravi Mehta:
Yeah. I think one of the things is to be clear when you're making a decision. So oftentimes teams aren't clear that they're in a moment of decision. A good example is when you get the results back from an A/B test, people just sort of defacto assume that if one test is better performing than the other test variant we should just launch the test variant that's performing best. But that's actually a decision. It's a moment where the team has learned something really important and should ask the question of, "Is this the right feature for our user? Do we want to launch this as is or do we want to take what we learned and synthesize it into the product?" So I think the first thing is to be clear when you're making a decision.
I think the second thing is ... Once you're clear that you're making a decision is to hold yourself and your team accountable for making that decision based on multiple forms of evidence. It could be the analytics, it could be conversations with customers, it can be what's happening with competitors from a common sense or a product sense standpoint. Deal is the best thing for the customer.
And then the third thing that I think is really important is to have the culture around disagree and commit. The best decisions are actually not the result of consensus they're the result of conviction. And really good sharp decisions are things that are often controversial where someone on the team who has a particular perspective feels really strongly about the direction moving forward. And there might be other things that seem as good alternatives, or there might be reasons why that might not be the best feature. But the problem with having that sharp high conviction decision go through a consensus process is it dulls things. And then at the end of the day you end up shipping something to the user that is less clear in terms of what it's solving for.
So a disagree and commit culture does a really nice job of saying, "Here's the decision that we're making. It's okay if we disagree but we're going to make the decision. We're going to commit to making that decision as successful as possible. If it turns out that that sharp clear decision was not the right one that's okay, we're going to learn from that, we're going to revisit, and we're going to factor that back into our decision-making process." And so those things I think can really help when a company feels like it's not making decisions in a balanced way or in as clear a way as possible.
Ash Oliver:
That's tremendous. Not consensus but conviction I think is such a great mantra. It also leads me to think about the factors at play within the culture: the psychological safety, the ability to try things out. There's so much that we could get into in each one of these areas. I want to focus a bit on the intuition and feedback because I think that's a good intersection, especially for PMs, designers, and researchers. So to look at intuition first. We oftentimes, especially in design, think about product intuition developing over time and experience. This is craft, and taste, and sensibility that you learn from success and failures. But outside of time in the seat learning, how else might you recommend cultivating intuition inside product decision-making regardless of if you're a designer, or researcher, or PM?
Ravi Mehta:
I think it's a really good way to frame the question. The word cultivate is exactly right. Intuition isn't learned, it isn't taught but it can be cultivated over time. And it's a product of a set of inputs, seeing how those inputs play out over time. Ultimately the source material, the raw material from which intuition is made is making a decision and seeing the outcome. And seeing whether or not you were right or wrong in that decision. And you can accumulate that through your own experiences, and that's really important, and so people's intuition tends to improve over time.
But you don't need to just limit yourself to your own experiences. You can look out in the world around you and see what decisions led to what outcomes, and use that as a way to integrate into your own thinking. One of the examples I like of this is Ray Dalio, the hedge fund manager that wrote a book called Principles. Had to develop an intuition about what happens in economic cycles. And economic cycles are 10 years, 50 years, sometimes 100 years long. And so in a single lifetime, it's impossible to experience enough at-bats to really build up an intuition for their cycles, especially the longer-term cycles. And so he's really a student of history and he talks a lot about this. He looks at the data over time and asks the question of, in this particular situation with this particular pattern, what ended up happening? And what about that was specific to that situation? Or what about that was traits of a cycle? He's able to learn, not just from his experiences in his lifetime but the experiences over many lifetimes by looking at history.
As product builders, we don't need to look at such a long timeframe, but I think we can look at what's out there both now in the current generation of technology as well as in past generations and past cycles and learn from that. If you look at what happened with mobile and who sort of won and lost in the mobile paradigm shift, there's some really interesting lessons for how to win or lose in AI. People that took their desktop experience and just sort of shrunk it down into mobile, and thought about mobile in a way that was not really native to the device, tended to lose out. Instead, companies that rebuilt their experience for mobile, and thought in a mobile native way, were the ones that really won. And I think we're going to start to see that with AI. There's a lot of companies that have dropped AI on top of their products. Sometimes people are using it, sometimes they're not.
If a company is able to rethink in an AI-native way, what that means for their product, that can be very powerful. And so one example I'd like to use here is Descript which is a product we're using right now. They've done a great job of rethinking the video editing experience from an AI-native perspective. And instead of using the timeline that has been essential to Adobe Premiere and Final Cut Pro, that worked prior to AI, they're using more of a transcript-based approach using natural language processing to turn video into Word and enabling people to edit scripts in a way that's much more AI-native that then has the knock-on effective editing the video. And that's a rethink of a workflow that could only really exist with AI. And I think we're going to start to see more of those types of companies through the real winners in AI who couldn't exist before AI just like the real winners of mobile were the companies that couldn't exist or who had products that couldn't exist before mobile.
Ash Oliver:
Yeah, that's super interesting. It makes me think about the pattern recognition that can be established across industries, as you mentioned with the example with the economists. Also thinking about examples of ... Within art or music, the unconventional paradigm shifts that maybe have occurred. And especially within industry now with AI, just the new expansive thinking that can take place. And so this is all really interesting. I'm also thinking about the micro level of the documentation of decisions that have been made establishing this paper trail or history across the company. Obviously, that can become a huge cognitive load, oftentimes a lot within people's heads as they just spend more time at the company. But are there any tactical day-to-day ways of being able to maybe encourage more of this? Or to, like I said, maybe track what decision led to some outcomes so that you can start to get this linear understanding even within your own company? Are there any techniques that you've seen applied there?
Ravi Mehta:
Yeah, it's a really good question. I think this ultimately comes down to prediction. If we make a decision, we've basically predicted how something is going to play out in the future and what we need to do today in order to get to that positive outcome. And so a decision is ultimately a prediction. And the only way a prediction is valuable is if when you make it, you actually commit to looking back in the future and seeing whether or not that prediction was accurate.
The way that I think companies typically do this, but they don't necessarily think about it in this way, is through goal setting. OKRs are essentially a prediction. They're saying, "We think on the first day of the quarter we're going to achieve by the end of the quarter these things." The hope is that you're going to achieve those things. And if you didn't achieve those things that you'll understand why and you can feed that back into the process. And so I think goal setting is one of the fundamental things that teams can do in order to better document their decisions and understand how those decisions played out.
One of the things that I have in some of the Reforge courses that I've done on product leadership is a framework called NCTs which stands for Narrative, Commitments, and Tasks. It's offered as an alternative to OKRs. Solving for some of the things that I think people have challenges with OKRs including having more narrative context around the goals so that people understand not only what the team is trying to achieve but why it's trying to achieve those things. But one of the things that's really important is the idea of commitments actually takes the place of key results. The wording there is really important. Ultimately, the idea behind or the concept behind a commitment is it's something that the team is taking really seriously and committing itself to do.
And it turns out that people don't like to make commitments unless they feel like they can really live up to those commitments. So just using that word and shifting the perspective from this is a goal, something that's future-oriented, to this is a commitment, something that's oriented in now, makes it more clear that the team is committing to a decision about what they're going to do, and that is predicting that decision is going to be really positive in the future.
And helps the team actually go through the process of not just putting the goals aside and maybe looking at them at the end of the quarter and seeing what worked and didn't work, but instead sort of living and breathing those commitments every day to make sure that the team is making progress on the things that it thought it was going to make progress on, or is revisiting if new information is coming to light. And so I think the number one thing that teams can really do in order to get better at decision-making is by treating them like predictions. Predictions are only really important if you look back and figure out whether or not you were right or wrong and then learn from those predictions.
Ash Oliver:
This just explodes when you think about the possibilities with AI and LLMs in terms of the verdict, it's going to be so exciting. I know we're not going to have this episode entirely focused on that so I don't want to get us down a rabbit hole. It also makes me think of this key concept that Maze has coined in terms of leveraging feedback and research to accelerate the time to right and decrease the cost of wrong, which I think is really prevalent here in what you're describing. And also connecting these narratives, and commitments, and tasks to the bigger strategy. And I know we're going to talk about strategy as well.
When we're thinking about feedback and how that might be a lever to pull here in that acceleration and the prediction or the confidence around the prediction, I think there's so many different streams now of insights and customer feedback. I think we're seeing a similar parallel to the first beginnings of data-driven decisions and all of the analytics that have become available. How do you think about effectively integrating user feedback into the product development process and ensure that it aligns with the strategy while also addressing user needs, and expectations, and some of this narrative, and task stuff that you're talking about?
Ravi Mehta:
I think feedback is really important. As we moved into the big data era of technology products and the amount of data that we could collect, and consume, and analyze exploded, I think there was this feeling that data is ground-true and there's nothing else need to really understand the customer because the answer is in there. And the analogy I like to use is that looking at data is like looking at a silent black-and-white movie. You can watch the movie, you can get the plot, and you can see what's happening, but if you add sound and color it's just a much better experience, and you could tell a much deeper and a much richer story.
And adding color, from a product development standpoint, is talking to customers and being able to actually put real needs, a real understanding of users, an empathetic perspective on top of the data so that you don't just look at the numbers as the what but you can really understand the why. And so I think that's really important and essential to have a product culture that's focused on making sure that you're both using data but also interpreting that data with knowledge of customers.
Because the thing that we don't, I think, put enough emphasis on is, all data is subject to interpretation. In many cases you can look at the same set of data and get to a completely different understanding of what the right path forward is. If data is inherently interpreted then we need to make sure that our interpretation is really good, and we can't do that without a deeper understanding. That's a shift in perspective. Moving away from this idea that data is fundamental truth and more that data is an input that needs to be synthesized amongst other inputs.
Ash Oliver:
It makes me think about the ... Expanding the triangle, right? The balance between the intuition, the analytics, and the feedback. And then within the feedback there's this balance within what sources, as you were describing before.
Ravi Mehta:
I think that's a really important point around the idea that there's all of these different sources, and those ultimately need to be synthesized into a direction. And one of the things that I think was a change in thinking for me is ... For many years I was really focused on decision-making through statistical significance, especially being at consumer companies which have a large amount of data. The goal always was to get to 95% competence interval, see what experimentation ... Experiments worked. Launch the ones that worked and then rinse and repeat that process. And what I've come to understand is that informed conviction is more important than statistical significance. If you're making data decisions just with statistical significance, that means you're not actually incorporating these other modes of information. And even with a 95% competence interval, your product decisions are wrong one out of every 20 times. And so statistical significance is not enough.
More important than that is informed conviction. What is a set of evidence that you need to feel like you have conviction around a particular decision that's been informed by a diverse and effective set of evidence? And then you can make that decision and make that so for the customer. I'm excited because it feels like more and more companies are taking that sort of approach to building products. And as a result, I think we're seeing products that are more human-centered, more design-centric, more research-driven, and ultimately do a better job for the customer. And they may not be locally optimal in that moment in time, but I think they're globally optimal in the sense that they're solving a fundamental need that has long-term value for customers.
Ash Oliver:
Absolutely. I think building on the concept of user empathy and understanding, I'd love to have you contextualize this as an example. Can you elaborate maybe on a specific instance where user needs led to a product decision that maybe initially seemed counterintuitive but resulted in some sort of improved outcome, user satisfaction, adoption, retention? Is there anything that stands out to you?
Ravi Mehta:
The example I'd like to use is a little bit more of a macro example, it's the example of Airbnb versus all the other travel companies. Like if you use other travel products, in many cases, they're very noisy, there's a lot of urgency messaging. They've got a lot of things happening on the screen so they've come to a locally optimal conversion flow but they're not thoughtfully designed. And actually, the Airbnb experience for the traveler is a very refreshing experience, a very human-centered experience. And it turns out that that is the thing that actually disrupted the travel industry. And all of the conversionary optimization in the world wasn't able to get the travel industry to really understand and take advantage of the opportunity that Airbnb saw.
Ash Oliver:
It makes me think about zooming out a bit on what design did for business, I think, is what maybe research will do for business in this next era. Certainly AI is involved in that. We're leveling the playing field in terms of what is possible to build. It makes me wonder, where does the differentiation come from? I think that differentiation into what you just described is really centered around the design and the experience. I can't uncouple how the understanding of the need for that and that audience maybe informed the result of the design.
Ravi Mehta:
The thing that I think Airbnb figured out that the other travel companies didn't is ... There was a vacation rental business in accommodations before Airbnb, but what Airbnb did was they reframed the relationship between a property owner and a booker as a human relationship between a host and a guest. That was this unlock that helped them reinvent how people think about vacation rentals and actually created an entirely new class of product. Not by changing the product itself in a fundamental way but by rethinking how people use the product and the value that they're getting out of it. The value of going to a hotel is it's sort of an organized and institutionalized thing. And also some convenience and some elements. I think prior to Airbnb, vacation rentals where ... You get some more space but it's disorganized and you don't have a high level of standard. I think Airbnb by saying, "This is actually a relationship between a host and a guest" allows you to have a more local experience, allows you to have an experience that's attended to.
Ash Oliver:
Yeah, for sure. That's a great example. It makes me think about the vision and the strategy. I would love to segue into your product strategy stack as an overview. Can you provide a high-level take on what the stack includes and its key components?
Ravi Mehta:
Yeah, absolutely. So the product strategy stack is something that I've started to use as a result of trying to think through how to create really good product strategy and understanding what exactly does that mean. And so one of the things that's common when people talk about strategy is there's a whole set of terms that just get conflated together into a jumbled mass. And it can be strategy, vision, goals, roadmap. Those things get used somewhat interchangeably. What often happens in companies is that the strategy is actually a goal. If the company says, "Our strategy is to increase revenue by 10%," that's actually not a strategy that's a goal. It becomes very hard to achieve that goal if there isn't actually a strategy to understand, is that the right goal, and how do we go about achieving it? And so the product strategy stack is a way of defining the different elements that go into product strategy and thinking about how they relate to each other so that we can make really good product strategy decisions, and have a better chance of achieving what we want to both for the product and for the company overall.
And so the strategy stack consists of five pieces, each of which relates to each other. And the top of the stack is company mission. Everything flows from the fact that the company is designed to create a change in the world, to basically achieve a mission. Missions can be highly aspirational. So Facebook's mission is to bring the worlds closer together. Microsoft's mission, in the early days, was to put a computer on every desk and in every home. Airbnb's mission is to enable people to travel like a local. These are not the actual mission statements these are just what I as a customer have interpreted. Everything strategically starts with what value are you trying to create for the customer and what are you trying to achieve in the world. It starts with the company mission.
Flowing from the company mission, so just under the company mission and the stack, is the company strategy which is, the company has or should have a rigorously logical plan for how it brings that mission into reality. You can't achieve your mission unless you have a strategy. And so the company mission and the company strategy work in concert to figure out, at a very detailed level, what do you as a company want to achieve and how are you going to achieve it. And the third layer of the stack is product strategy. And so product strategy actually sits between the top of the stack and the bottom of the stack. And it's the connected tissue between what is the company trying to achieve and what is the work of the product team. The middle layers product strategy and then the remaining two layers are product roadmap and product goals.
And so the stack consists of five elements: company mission, company strategy, product strategy, product roadmap, and product goals. Each of those five different things, and I'll go into them in a little bit more detail, works in concert. And so we can think about the stack in two ways. We can work from the top down to define our strategy, to define what we're going to do. So we start with the mission at the company level, then we define the company strategy, then we define our product strategy which is basically our plan for how the product is going to play its part in the company's strategy. And then we define a product roadmap which is the set of initiatives, the sequence of initiatives that we need to deliver as a product organization in order to achieve our strategy.
And then lastly, and most controversially ... I think the bottom of the stack is product goals. So the goals are the things that we measure to understand whether all of what we've just said is actually making progress. And so goals I think of as actually being the output of the strategy, not the input to the strategy. And that's a controversial thing. A lot of people say, "You should start with what is the goal that you're trying to achieve and create a strategy around that." I think instead we should start with what is the company trying to achieve from a mission standpoint. How is it going to achieve that? And what goals actually act as evidence? An example that I like to use is ... If I'm traveling from LA to Las Vegas on vacation I could set a goal to travel 200 miles, but the goal to travel 200 miles won't necessarily get me to Vegas. I could travel north and start heading towards San Francisco, I could travel south and start heading to San Diego. And so the goal absent a particular destination actually has no meaning.
So the goal of increasing revenue by 10%, without a strategy underpinning it, doesn't have any meaning. Whether or not you achieve that by going after consumers or businesses or with one product or another product in the portfolio, these are incredibly important strategic questions. And so I think before we set a goal of traveling 200 miles we need to set our roadmap. What is the destination? Where are we going and why are we going there? Product leaders and companies can use the stack top down to define the strategy to start with the mission and then end with a set of goals. And then they can use the stack bottoms up to understand how effective the strategy is. To analyze, are we doing the right thing?
So if a company is achieving its goals because it's implementing its roadmap, and that implementation of the roadmap is driving the product strategy which is adding to the company's strategy which is helping the company achieve its mission, that's great that means we're doing the right things. But if on the other hand we're missing our goals, that might mean that we've chosen the wrong things for the roadmap or it might mean that we just executed those things in the wrong way. If we chose the wrong things for our roadmap it might mean that our strategy is not right strategy, or it might mean that we just need to do different things to execute on it. And so we can work bottoms up to essentially diagnose our work and we can work top down to define our work. The product strategy stack is meant to be sort of a simple framework that makes it clearer. What are the different elements of a strategic initiative? How do we define that? And how do we diagnose that as we're working as a product team?
Ash Oliver:
It's so well said, I think it's incredibly valuable. I think so many companies, fortunately, get this wrong at the topmost layer, the mission. I've seen, actually, many that have oftentimes been a goal to unseat a competitor or to increase revenue. I just think that the framework here is incredibly important to set this up for success. There's another thing that you talk about in terms of visualizing the company vision or mission, and that really stood out to me. I'm wondering if you could elaborate on why you believe it's essential for a company vision to be made visual. What advantages you see in maybe translating this abstract vision statements or mission statements into tangible visual representations?
Ravi Mehta:
Yeah, definitely. So this was a big unlock for me. I'd spent years as a product manager and a product leader primarily communicating strategy and roadmaps in words and saying, "Here's what we're going to do." And then always being struck by the fact that months later everyone had different expectations of what was going to get built, why it was getting built, and whether or not we were on the right path. I was at Tripadvisor at the time and we needed to define a strategy for how does Tripadvisor implement a trip planning feature such that it creates a longer-term, more engaged, more retentive relationship with the traveler so that they're coming back to Tripadvisor directly rather than having all of their usage of Tripadvisor intermediated through Google search. This was a strategically important problem but it was also a really hard problem to get right. It meant that we were going to have to move some important things around on the site, potentially having some conversion rate impacts.
Trip planning is also one of these notoriously hard things to get right. There have been a lot of trip planning startups that had done this. And so we decided to take a different approach. And so rather than just write up the strategy in a doc, we said instead we're going to create a strategy document which is inherently visual. And as part of the strategy we're going to define 20 or 30 different wireframes that show, at a very high level but a visual level, what it would mean to implement this strategy. And the reason that that was really important is that ... Strategy is actually at its best very specific and concrete. It is absolutely big, and broad, and ambitious, but that doesn't mean that it shouldn't be ambiguous, and that doesn't mean that it should be loose or blurry. Strategy has to achieve this tension between being ambitious but also being concrete.
And wireframes are a really good way to do that. Because ultimately our strategy is implemented through an interface that a user uses, which is inherently visual, and you need to make trade-off decisions. As one example, the decision of what should be on the tab bar in a mobile app is absolutely a design decision but it's also a strategy decision. What are the four or five top features or functions that we as a company think are essential to us being able to deliver on our mission to a customer? That is a strategy decision that doesn't really get baked in a document, that is just words alone but is a fundamental and important question when you're building wireframes.
Another analogy that I like to use for this is, you would never work with a contractor to build a house who just gave you a completely pro spec for that house. If a person said, "Here's the bullet points, here's the 20 things that this house is going to do. It's going to have four bedrooms, it's going to have three bathrooms, it's going to be two floors, it's going to have a great kitchen, it's open concept." There's no way that you would sign up for the contractor to build that house without a blueprint. You need to have the blueprint in order to understand how do all of those requirements translate into the very concrete trade-offs when you're creating something in 3D space. And so it's the same thing with a product. A product is ultimately an interface that a user needs to use, that needs to exist in 2D space, and the only way to communicate that concretely and with enough fidelity is by taking a more visual approach.
Ash Oliver:
I think that's such a huge unlock. Like I said, really stood out to me. It's more often than not I see vision and strategy communicated in a Word doc. Do you think that there's some hesitation just in terms of either the time commitment? Or do you think it's ... It puts too much emphasis maybe on a commitment that isn't made at this point? Why do you think more companies aren't visualizing this?
Ravi Mehta:
I think there is a feeling that visualizing is a design activity, and design needs to take a lot of time because all sorts of pieces that need to get right. And it needs to reflect the brand, it needs to fit into the existing product. One of the reason I advocate for wireframes instead of designs is really you're just trying to sketch things out. You're just trying to say that there's multiple different ways for us to be able to express ourselves. Part of it is visual and then part of it is in a description of the functionality. And so wireframes need to take a lot of time, in the sense that someone can write in real time. This is true for design teams separate from strategy as well. I think too often teams jump straight to painting the masterpiece and don't spend enough time in the sketching phase. And so the wireframes, for a strategy document, are really just meant to be a sketch to help everyone get on the same page and not any sort of final designs that the team is committing to.
Ash Oliver:
I think this is so powerful. It was certainly inspirational as well when I saw the former startup that I was working for. I mean, they used Keynote. It was simply screenshots of the products, right? It wasn't even click-through prototypes. It had so much power and ability to align us in what direction we were headed in as well. I want to transition to our Hetrick questions that we ask every guest at the end just to find out a little bit more about you. And my first question for you is, what's one thing you've done in your career that's helped you succeed that you think few others do?
Ravi Mehta:
Understand the priorities of the people that you work for. It might be your direct manager, it might be the board, it might be investors. As someone who's young and looking to get ahead, it's easy to look at people that are in leadership positions that are really well paid, that have large teams, that have a great scope of influence and not think to empathize with their problems. It might seem like they don't have any problems. But when you take a moment to think about what are their problems? What are their priorities? What are they solving? That gives you an opportunity to figure out how you can engage with them in a way that's most constructive for you and really constructive for them. Empathizing with leadership I think is one thing that very few people do and can actually be a great unlock. And can translate you from just being someone on a team to being an ally that's really helping leadership achieve the goals that are important for the company.
Ash Oliver:
That's such great advice. My next question for you is, what is the industry-related book that you've given or recommended the most and why?
Ravi Mehta:
It's a really good question. This will change from time to time. Given how much we've talked about visuals today, I think a book that's really worth looking at is Slide:ology, it's By Nancy Duarte. She is probably one of the world's best visual thinkers. She helped with Al Gore's presentation for Inconvenient Truth which was a documentary that really, I think, helped to change people's perspective on climate change. And her book Slide:ology, first of all, it's a masterpiece in visual communication, is just a beautiful book. So just a great reference. But it also goes through the process of creating a really good presentation. And even if you're not creating a presentation, just being able to understand how she thinks visually is really important. She has some follow-along books too. One on storytelling that's really good. Anyone who's thinking about how do I think more visually, that's the first book I recommend.
Ash Oliver:
That's so great. I think that would, most especially, resonate with researchers and PMs that are listening. The storytelling and visually thinking about how you're communicating this information is probably a huge boom. My last question for you is, what is an unusual habit or an absurd thing that you love?
Ravi Mehta:
I think everyone imagines what parent they'll be until they are a parent. And for me, I always thought I'd be a straight and narrow parent, be very strict. But an absurd thing that both my wife and I have done, we've got two girls they're now 14 and 12, is we just keep putting ourselves in a position of having parent fails. So we always think the kids are more capable than they are. And we put ourselves in situations with the family, which in hindsight are really absurd and funny but at the moment can feel really tricky.
My daughter has recently gotten into 70s and 80s hard rock and so I took her to a Led Zeppelin cover band concert at The Greek. And then as soon as we sat down, basically the whole audience lit up. I think my daughter had her first contact high at 12. The absurd habit is basically overthinking what the girls are ready for and just doing that. It feels very tense at the time. But I think in retrospect we've enabled them to have experiences that we wish we would've had. We all take it in stride and we have a lot of fun as a family, and nobody's gotten any sort of permanent injuries yet.
Ash Oliver:
That's success. Definitely a characteristic of a fun dad so that's cool.
Ravi Mehta:
Maybe too fun. So yeah, absurdly fun.
Ash Oliver:
Ravi, thank you so much for this, this has been incredible. Thank you so much for being here.
Ravi Mehta:
Yeah, so much fun. I really enjoyed the conversation, thanks for having me.
Ash Oliver:
Thanks for listening to the Optimal Path brought to you by Maze, the user research platform that makes insights available at the speed of product development. If you like what you heard today you can find resources and companion links in the show notes. If you'd like to stay connected you can subscribe to the podcast newsletter by visiting maze.co/podcast. And send us a note with any thoughts or feedback to podcast@maze.design. And until next time.