HotelTonight's Madhu Prabaker has built a career in designing experiences for a peculiar kind of beast: marketplaces. These types of companies require a delicate balance of competing interests from different sides. The dynamics of two-sided marketplaces create compelling challenges and unique use cases for designers. While one ecosystem partner might prefer speed, another might prefer accuracy. It's not always simple to design well for multiple audiences.
After a long stint at Yelp, Prabaker recently joined HotelTonight as Director of Product. The recent app refresh was the first step along a journey to build an extensible design language and component bank that can be drawn on as the team works through its roadmap. Prabaker believes these two things, a common design and a menu of components, will help the company move faster, experiment more often, and ultimately help it respond faster to consumer behavior.
Bolstered by a fresh infusion of $37 million, speed-to-market is critical. The team must respond rapidly to users and quickly capitalize on emerging opportunities to keep pushing forward into an opportunity that CEO Sam Shank sees as still emerging. After all, it was only earlier this year that Shank called last-minute "the new paradigm of hotel booking."
Prabaker took some time to share his take on this new paradigm one-on-one. If you're not familiar with the re-design, the video below is a helpful visualization of the concepts Prabaker explains in the interview that follows.
We're doing more deep dives into the more educational side of things, in the sense of talking to the people who were doing cool things. To kick it off, give me an overview of who you are, your career path, and what you've been doing at HotelTonight recently.
My name is Madhu Prabaker, and I've been at HotelTonight for the past few months. The first project I took on was the redesign, which had kicked off just prior to me joining.
Before this, I was at a marketplace company called PeerSpace. We were focused on making all the wonderful spaces of the city available for anyone to rent. Prior to that, I was running the mobile team at Yelp for four years, from 2011 to 2015. So that's really where my love of the mobile app and the consumer experience came from. That was also a huge reason why, when the opportunity opened up for me to join the team here, it was something that I just couldn't say no.
You've got an interesting background there, with the restaurant hospitality side of things and the physical space hospitality. Seems like that translates really well to HotelTonight.
Absolutely, and Yelp and HotelTonight were early premiers in the mobile space. I think we had apps available on both app stores. Our products evolved at the same time that the App Store and consumer preferences changed.There's only a handful of companies that have ridden that wave and really learned how to be the best product for the platform. Where we weren't a desktop site before. We were focused purely on the mobile spaces.
So when you arrive at a new place, a new position, what are the first few things that you do as you're settling into this project for a full app redesign?
The very fortunate thing about joining a team and a company like HotelTonight is that there's not a lot to fix. There was so much that they had done well in terms of getting profitable and making sure our app was extremely high performance. And it was award-winning on that platform. So you could say that my job coming in here from a product perspective was made much easier by that.
And instead of focusing on improving how the team executed, because I think that this is one of the best executing teams around, the biggest thing that I wanted to provide early on was some strategic vision. And being able to tie Sam Shank's vision for the company all the way down to the activities that we were doing on the team to create more visibility and help us increase our speed of execution, speed of concept validation, and our speed of experimentation.
Looking at the redesign, the designers and the engineers had already done some really great work in identifying what were the core things we wanted to attack with it. When we approached the redesign project, it wasn't like some other companies might approach a redesign, which is either driven by two things.
One is, there's a lot of things that aren't working. We need to completely rethink it. Or it's we don't really have confidence in our point of view or personality, or the things that are part of the product, so we need to completely rethink it. It needs to actually match our brand. Fortunately for us, both those things were not true.
So even though we ought to redesign, it was really more of a refinement. The goals of the redesign were really twofold: create a consistent and coherent design to makes it as simple as possible for customers to find and book the best hotels for them, and at the same time do those things while emphasizing all the aspects that make HotelTonight different. And then the second thing which you don't see today, but it will be very apparent in the future, is that we wanted to create and employ a new design language that sets us up for all the exciting things that we have in our roadmap for the next year or two.
Now we have a platform and a design that is robust and flexible -- and ultimately really scalable. So all the things that we're going to build in the future we know exactly how they can evolve and work within this design.
Let's jump into the extensible side of things. People forget that the constant iteration, that cycle of app updates, is a grind that's inescapable. I would love to hear more about how you approached a design for the future where you can create a platform that will help you be able to grow into. When you say designing something for the future and creating that architecture, what does that look like and how does that help you be prepared to move faster?
Part of it is that there are certain design principles, in terms of flexibility. It comes from starting with what's the best-in-class experience we can imagine to serve both our users. Both our customers who book with us and our hotel partners who merchandise their hotels. How do we serve their interests in the best way? What are the platform-level things that we're going to want to build for the future in order to do that? That's extending our customizability. How can somebody tell us or provide input to what they're interested in -- whether it's creating a travel wish list with favorites or just based on their prior activity and using personalization to improve that. So for each of these threads we try to look at a two-year horizon and what we need to support.
And then, here's the art of it. You have to now take all of those things and then build components that will serve you well today but still be able to scale to serve you in the future.
We try to make these things as reusable as possible, and then some of the overall metaphors we're using in the design language need to be able to scale up.
You're almost doing an exercise where you're your stress-testing the design and the components by making sure it works for today and imagining what it would look like if it had supported all those other elements we want to build in the future. Knowing that we're not building those yet, and then using that as an input to us to let us know if these components are really scalable.
And if the answer is no, that means redesigning the components, keeping both those things in mind. How do we best serve the customers and the product we have today, but also how do we make sure that there's a path between what we have now and what we want to build the future. If you look at some of the design iterations and see how they evolved, it points to that journey.
For those who may not know, and also even for myself, when you say components, what specifically does that mean? How do you see a component within the app or the design?
What the customer is using in their hand operates in two states: one state is, this is the design that the design team came up with. And again this is trying to serve both sets of our customers. But underlying that, there is actually the component that the engineers are building.
If we're able to design something that serves our customers today, and in the future, and if our engineers are able to build those components as reusable robust components, then in the future we have this really beautiful and extensible card-based design. So if we want to add a new module that emphasizes a certain aspect of hotels that our customers found valuable that the hotels really want to emphasize, instead of getting into the nuts and bolts of the pixels and the code, we would just copy this one element that we had created.
The component, the underlying implementation, and the design would be something that we'd have available to us. Now we have something that becomes extremely easy for us to reuse. That's good for us because it saves us a ton of time. It's also really good for our customers because they've gotten familiar in understanding how to use the product today.
If we introduce something new with the exact same design language and interaction, we know it's going to be really understandable and usable for them out of the gate.
I would also be curious to hear how that applies to maybe future platforms. For example, maybe the mobile app is not the way that people are booking hotels. How does that 'future proof?' Looking ahead and thinking about different channels, what role does that play?
We've made smart choices about not over indexing on the ways that people have done hotel search before in the past. Which is a set of filters and I'm going to show you hundreds of results. And we don't have a point of view and you as a customer scrolling through all of those things.
In some areas, we've explicitly chosen not to do that sets us up for a mobile future that we can better serve.
There's another really interesting part of it, which is our chat. We use chat now to communicate with customer service and for our Pros feature. That in itself is something that our customers absolutely love. We were just look an example this morning where someone was able to chat in a request for a David Bowie poster. And some addition to the room that was just an extraordinary cool experience -- completely frictionless for the user.
And every part of that ecosystem ourselves, the user, and the hotel felt great about it. So chat as a platform is something that we already have a competency in, and we've built it to great effect both for the Pros product and for our customer support.
When we start thinking about how consumer behavior changes in the future, and we position ourselves to best act on that. If it's something that we find really interesting, it's about finding ways to build those core interactions and really hone them down to their simplest most value driving form.
With a product like the chat feature, which I recently used and was interesting to get to know the random person on the other side, do you feel that interaction isessential to create a brand that people identify with? And if so, do bots (and the fact that maybe this person is actually not a real person), create skepticism that affects the impact that chat can have on brand perception?
You totally nailed it. For chat, there was a movement a few years back where everyone was like, oh we need a chat strategy. It was really focused on the implementation and wasn't really focused as much on trying to solve the core user problem.
In a lot of ways, where chats and bot apps have gone wrong in the past, is they haven't focused on the customer. And they haven't focused on delivering value for their particular ecosystem. Instead, they just build something which took an existing modality -- whether it was tapping on the UI or talking to someone on the phone or talking someone in person -- and then just shoved it all into chat because that was the new hot thing.
When we think about chat and how can best be served whether it's automated chat, a bot, or whether it's chatting with the real person. There are at least four different modalities for interactions that happen both offline and online.
There's talking to someone face-to-face, there's talking to someone on the phone, there's tapping on a UI, and then there's chatting via text. We think about what's which modality is best served to solve the problem at hand.
And the interesting thing that I've noticed is that, depending on the type of problem you're solving, a different modality might be most effective. For example, when things are working really well and expected, oftentimes just a tap-based UI might be the most effective way for someone to do it.
When you're in a space where there's a lot of variance in terms of direction that the customer might want to go to, chat is a really nice way to do that. However, sometimes there are even examples of where if things aren't going well, sometimes just talking to someone on the phone and hearing a voice or being able to see someone in person might be the best use for that.
That's why we've been very selective with how we use chat. In particular trying to avoid some of the issues that we've seen for other competitors, either in our space or other products that have rapidly employed chat and bots as a new thing without really focusing on the problem they were trying to solve.
To identify the problem, I think maybe that is a struggle for a lot of companies and teams. Do you normally, and especially speaking towards this redesign, go in and talk to customers first? Or do you do the Steve Jobs, which is I think that is what it should be, this is our brand and we're going to do that? Walk me through the process of on-boarding customer information and then delivering for them.
A bit of the art is to figure out how do to use all the channels of data that we have available to us to be able to derive insights that help us identify how all the products we're working on today are functioning. And then also orient us towards the unmet needs and the opportunities that we might best be able to serve in the future.
I can just mention a few that we hold in high regard. The first one is just our quantitative data. We've developed a really deep competency in being able to track all the meaningful measures that capture that the performance of our marketplace.
My past company was a market company as well, and marketplaces are complex because you have a whole supply side which is really focused on our hotels. How much inventory they have, the different pricing, the quality, all of those aspects -- and then marrying that to the demand side, which is our customers are trying to find that.
So having a really robust system is good because it helps us understand performance and if there are any issues, for every product that we ship, immediately.
The second benefit is being able to have a really strong and robust AB testing framework. That means that, as we ship new products, for example all the really great personalization improvements that we have done recently, we're able to tell definitively to what degree is improved performance. Especially in terms of customers being able to find and talk the best hotels, as well as in terms of hotels really feeling they're able to sell the rooms and be able to meet their goals. It helps us quickly identify to what degree is the feature we're launching being able to be successful for that. So I think that's an area where we have these really robust systems that help us out.
The challenge is being able to marry that with the qualitative data. A lot of this comes in from individual customer success or customer support data. So we get these tickets for users having particular issues or misunderstandings and we can run usability tests with a set of users who have used us in the past and users who have never used us. And being able to understand their mental model. Where are the confusions and misunderstandings? And also the things that they get really excited about.
Then we marry the quantitative and the qualitative data and produce insights based on those. That's where the magic comes in. Fortunately for us, we have a very strong leadership team. Sam Shank has an ability to understand what both sides of the customers really need. That's hugely beneficial because, without that, the amount of data that is generated both on the qualitative and quantitative side is overwhelming. So you can really get into positions where you don't have a strong vision of where your product is and what it isn't, and where you want to go in the future, you can you just kind of get stuck in there.
That's how we try to think about taking both sides of our data sources and pulling insights from that while being driven by a common shared vision.
There are the three phases of data, from seeing, compiling, and then acting. Sometimes that last step is forgotten. The right data was captured and analyzed, and then it just disappears from the vision. We didn't do anything with it. How do you make sure to follow through?
The other thing too is that we want to be a learning company. So you want the feedback after you made a decision based on those insights and we deliver the product. We want to be able to take the performance of that feature or what we learn and feed that back into our process.
We run tons of experiments. The expectation is not that everyone's going to be right. The expectation is that we're going to learn something from each one of these things. Sometimes that learning just means cool this thing works. Let's ship it out to 100 percent of our customers. Sometimes that learning means that OK now we have a better idea of what a more successful product will be in the future.
I have an emotional data on data and insights gathering. When people are maybe wrong -- they had a thought that was proven wrong. How do you deal with the emotional side of it? Where you had invested a lot in a design, and you were certain this was the thing, and it turns out no one cared?
As much as possible from a product and design side, we want to really be egoless. You want to divorce your ego from the things you're working on. And really it's just trying to develop as much empathy as we can for our customers. The people who are booking through us and our hotel partners. And if we can really develop that empathy, through awareness. Giving our teams access to those users. It's really the qualitative stories that help people understand the benefits and the pains and some of the unmet needs.
If you're able to divorce yourself from "this thing is a representation of me and it has to be right because it's a reflection of me," and rather think of this as, "this is an idea that I have that I think will best serve our customer." That's the first step. It makes it a lot easier for you to be able to accept a bad outcome as an opportunity to learn and get better.
The other part of it is from a company perspective. You really need to give those things that didn't work really high visibility and emphasize what we learned from everything.
Someone who's new to our organization will start seeing these examples of, in a company-wide email, say we tried this experiment, here are the insights that led us to try it, here's what we thought success would look like, and here's what actually happened. And it turns out it didn't work for these other reasons, but we learned all these new cool things, and that's put out as a really positive thing.
I think that also helps set the tone right in the company so that people are excited about learning versus trying to always be right. And then it's much easier for people to recognize when they're wrong on some of those things.
It's a range between curiosity and stubbornness.
Yeah. The other thing, going back to the Steve Jobs perspective. I think that point of view really set us back a little bi on the technology and product side. The idea of the single visionary. You also hear another quote that's often missed attributed, which is a Henry Ford quote which was, "if I asked people what they wanted, they would have said a faster horse.
The thing that people get wrong with it when you talk about talking to your customers, and understanding and developing an empathy with them, is you're not just doing what they ask you to do. That would be a very simplistic way of doing it. And you would get maybe a request for a faster horse but if you really try to understand their goals, understand to what degree your product serve those, or still isn't serving those. Everyone can articulate the pain points in their life and the way in which they want things to work. And then it's our job to be able to understand those needs and then translate them into a product and maybe that person wasn't able to articulate.
But when they're using it, they can't deny that it actually really solves that core problem. Hopefully, in a really delightful way, that's surprising for its ease of use and in the fun. That's something that's super important to us at all HotelTonight.
When you guys get that chat or these new features integrated into the app, how do you then take this new information and put it into existing systems? For example, if I request a certain type of pillow through chat. How do you account for these new data sources that are created with new design features?
Every data source you provide has a different way of measuring the signal. There's probably two passes that happen. The first one is not doing it at scale, which is really important early on. That's combing through and making yourself fully immersed in all the details of it. So if it's a chat product, it's reading hundreds of chat logs. Trying to even get a sense of what's going on. So that's kind of step one, a full immersion.
The second step is being able to identify the key patterns that you're seeing. So in the chat, it might b 10 or 20 canonical flavors of what a chat is on the platform today, and it's been able to understand and categorize those.
And then the third phase of that would be building automated systems where we can immediately identify those patterns. And then we can do it at scale. So now, when there are thousands and thousands of these, we have dashboards and systems that help us understand what our customers are looking for and how well we are serving each of those needs. These are things that we can track, and then as we're trying to improve them, we now we have a baseline by which we can look at the performance for the thing that we change or the new feature -- and compare it against those historic baselines to see if we improved conversion.
How do you decide when to use automation? Do you make sure that the data source is relevant first, or do you take it all in and then use automation to parse it all out and then say actually this is not signal? What comes first?
The automation is built once we have an understanding. In order to build it accurately so it's detecting the right signal, and we're attributing the right meaning to that signal, we first need to understand it at the micro level. And then as the product scales out, being able to slowly start building automation. But only once we're convinced that we really understand the patterns that are happening. and that does not make sense.
People have trouble figuring out what is noise and signal, but then when to get rid of something. Not all data as great data. Sometimes you have to say no.
The data will never tell you its accuracy. All data looks the same right. It's better to not have the data, and use the qualitative information and your intuition to make decisions, versus using data that are inaccurate and actually getting you the wrong way.
Having some discipline up front can really help be faster. That's certainly something that we really really focus on here. That's why we have a separate data team that's focused completely on attributing meaning and helping us as a company make decisions.
It's easy for companies now to just generate tons and tons of data but being able to have the expertise on the team to be able to interpret that data, and use data to drive decision making, is a whole different thing.
As we wrap up, let's look out 6 to 12 months from here. So you have a good baseline, you come into the role, and now you're moving to the next phase. Where do you see the design going? What are some trends, changes, and shifts in consumer behavior that you're looking at and considering how that might impact HotelTonight?
At the very simplistic high level, we're trying to find ways to better serve the customers that we have today. And that's really around understanding conversion performance, looking at our funnels, understanding the issues that come up from customer support. Talking to folks who are our highest level Perks users and how they use the product and how is that different from others.
The next thread is always looking towards growth. We think we built something really special that is valuable for both sides of the marketplace for the customers and for the hotels.
So how do we make this product able to be used by even more of them? It's really worrying about how to solve problems for the next set of millions of customers and thousands of hotels.
One of the things that's really interesting is that you always kind of having your finger on the pulse of consumer trends. We've really focused on knowing the new consumer, the millennial, the Instagrammer. When they think about hotels they don't think about a commoditized box, that's in a location, that costs a certain price. They really think deeply about the experience of being in that hotel. And how does that match with what they're looking for and how do they share that with the people that are important to them. That's fit really nicely for us.
As much as I love our app and I think it's amazing, sometimes we just want the app to get out of the way because we have these amazing hotels. We're trying to merchandise them, with their photos and their descriptions in the best way possible, just because of super important to that booking decision for that type of consumer.
Tying this back to the redesign, we really shrank a lot of the chrome and hid things out of the way as the user scrolls. Really trying to get the content and not the context be the king and then being able to be at the forefront of the decision-making process.
Do you find that user generated content, in a future of augmented and virtual reality, will always be around?
I personally think it's still really important. When you're working with products that are high-quality, people want to share their experience with the world. And that's a really big part of having any experience is the ability to share it. So I think user generated content for the person who's booking the hotel is always going to be something that's important for us.
We want to provide an expressive outlet for them to be able to talk about what they love, share the best aspects in terms of photos with future customers. User generated content, especially with the high volume of users that we have, is a really nice way to create even more trust, both with HotelTonight and with the hotel.
Oftentimes, that trust is really just that you've already fallen in love with the location, the hotel, and the price. You really want to make sure this is going to be an extraordinary experience. Certainly, the extraordinary experience that you hope it's going to be. I think that's where the reasons why people liked it and the photos also play into that.
And for us also, we've taken a point of view which is that we don't think it's a great mobile experience for someone to have to comb through hundreds of reviews. So we try to summarize that information and provide the most helpful summary of information up top just so that it's really focused on that mobile experience. That really ties back to us just being a mobile first company and the principle that nobody wants to spend their time looking at hundreds of reviews or browsing hundreds of photos.
They want that information packaged in a way that's super easy to make a decision based on. And there will always be a place for that, at least at HotelTonight.