Adaptable Product Strategies

Fani Bahar, Roberta Virzi at UXDX Community: Europe West. Video: https://youtu.be/87iURM7Pap4

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.

Introductions: Booking.com and VMware Tanzu Labs

[00:00:00] Host: Now it's time to introduce Fani Bahar and Roberta Virzi. I'll just ask if you could each introduce yourself and a little bit of your background for our audience. I'll start with Roberta, please.

[00:00:12] Roberta: Hi everyone, I'm very happy to be here today. I'm Roberta. I'm a senior UX designer and team leader at Booking.com. I'm Italian, as you can guess from my accent, but I live in Amsterdam. I have this hybrid role where I'm both an individual contributor and a manager of multifunctional teams. Just a bit of introduction to the structure of Booking.com, so you can understand better what I'm referring to when I speak. At Booking.com we have several departments. Each department is then divided into tracks, and these tracks are divided into small teams. We work in small cross-functional teams, as Jovi was mentioning, with designers, product managers, engineering, copywriters and so on. Each department has its own objectives that are aligned with the company objectives, and then each team also has its own objectives and areas, which are aligned to the department's. So just a small introduction.

[00:01:21] Host: Great, and I'm sure we'll dig a bit deeper into that in a few seconds. Over to Fani: could you give a quick introduction to yourself and what work you're doing?

[00:01:32] Fani: Sure. Hi everyone, my name is Fani Bahar. I am a senior product manager at VMware Tanzu Labs. I've been working as a product manager for almost six years now. Before that I was an engineer; my background is in computer science. A little bit of background about VMware Tanzu Labs: I'm not working as a product manager for a VMware product, but I'm working on VMware clients' products. Basically I'm pretty much a product consultant. Let's say I'm working with an automotive industry company or a finance industry company, and we are working together to build the client's product. It can be a greenfield product, so a totally new product for them, or it can also be modernizing their current product. That's basically the responsibility that I have as a senior product manager at VMware Tanzu Labs.

[00:02:32] Host: Excellent, that's really interesting. We're going to have a bit of a difference in this conversation between the more frequent new products, or different products, versus building an existing product in Booking. Roberta, you touched on your organizational structure there. You said you've got departments and tracks and teams. Can you give an example of what's at those different levels, just so people can get into their heads what we're talking about here?

[00:03:00] Roberta: Just to give you an example of where I am: we have this accommodation department, which is the umbrella for all the different types of accommodation. Inside it I'm in the homes department, which is specifically for homes, properties like apartments, villas, bed and breakfasts and this kind of thing. And then there is another department for hotels, for instance, and then there are others inside.

[00:03:28] Host: Okay, great. And apart from accommodation, what would be the other departments, just so people can get an idea?

[00:03:38] Roberta: It depends on the product. For instance, there is flights, all these kinds of different products that we have. Another thing to specify: in these departments, the different teams can be working on the customer-facing products, so what you actually see on the website, while others work on the partner-facing products, what the hosts and the owners of the hotels can actually see.

[00:04:10] Host: Great. That's great, seeing that marketplace where you have to look at both sides of the marketplace. I'll come back to you in a minute, because I want to dive deeper into that.

Starting a product strategy with the double diamond

[00:04:25] I'm interested, Fani, in the work that you do, because you're looking at different clients all the time. Where do you start with creating your product strategy, before we get into adapting it?

[00:04:39] Fani: Sure. At VMware Tanzu Labs we have specific processes when we start the project or the engagement with the client. We have what we call the double diamond, so we have discovery processes and we also have framing processes. We start building the product strategy from the beginning, from early on, from the discovery processes. Let's say even from the first day working with the client, we really want to understand what the problem is that they are trying to solve, and from there we are also trying to understand what their product vision is. When I say engage with the client, it means not only with their executives, but with the real product development team. So in the product vision workshop we try to understand from each team member what the vision of the product is. And from having this vision, we also start defining what the strategy is, what a good strategy is, to execute or achieve our vision.

[00:05:50] From the discovery we have already discussed our product vision and our product strategy, but this is all still based on our assumptions, all assumptions from the team members. From there we try to interview or do some kind of research. It can be user research, it can be market research, it can also be competitor research. The goal of doing all this research is basically trying to validate our assumptions, validate our initial product strategy. And the moment that we get more knowledge of it, that's also the moment we shift to the framing processes.

[00:06:33] In the framing processes we also try to review whether our vision is still aligned, whether the problem that we are thinking of is actually the real problem, and whether the solution that we are thinking of is actually the solution that will solve the problem. Because of that, we also try to update our product strategy. So we definitely define it early on in building the product, and then along the way we always need to check whether the strategy is still relevant or still valid. Most likely I will always try to make sure that our product strategy is good enough, long enough, for the next couple of months. Because I think it would be a red flag if we are changing the strategy quite often. It means that we probably didn't do our homework really well, we didn't do our research really well.

[00:07:33] Host: That's a great example there at the end. I guess the challenge, because as you described in that double diamond process, it's a lot of discovery. At both phases you've got the broad thinking before you narrow in on a solution. How do you marry that broad thinking with trying to get a stable strategy? How do you marry those two seemingly different approaches?

[00:08:02] Fani: The broad processes here, we're just trying to use something like a Lean Canvas workshop. We use this framework a lot, because by using this framework it really maps out our assumptions about our problem, solution and the users very quickly, and with this we can also get alignment with the team very quickly. And from this Lean Canvas it would be really easy for us to also define what experiment we need to do as soon as possible, so we can validate our current product strategy. The reason why we want to do this experiment, as I mentioned before, is really to find out whether the strategy that we mentioned is really a good strategy, whether it will really solve the problem that we think is a problem.

The instrument company: when the assumption was wrong

[00:09:04] For example, I was working with a big instrument company. They are selling instruments, and they were trying to build an e-commerce application. At that time, one of the big problems that they could see is that a lot of people are looking for a specific instrument, but they couldn't find it on their website. They really believed that one of the biggest problems might be the supply chain. One of the other problems could be that the user is not able to add it to a wishlist or something like that for the instrument. So at that time they really focused on having a better supply chain, they really focused on how to reduce the cost. That's where their assumption started, and because of that, they really stuck with the strategy: "Okay, we need to reduce the cost of our supply chain." What does reducing the cost of the supply chain mean? They really believed that they probably ordered instruments for which there was not a lot of demand, while the instruments that have a lot of demand, they didn't order enough of. So a lot of people are looking for that specific instrument, and then it's sold out.

[00:10:27] We started with that assumption, and when we started with that assumption, we did a lot of market research, user validation, or even went into their internal supply chain processes, what actually can be improved. After that we worked again with the team to map out all our findings based on the earlier discussion, until finally we discussed, "Okay, we have all these facts, let's prioritize what the biggest problem here is." It turned out the biggest problem at the time was not about the supply chain. It turned out there were a lot of users asking for alternative instruments. They might want a specific instrument, but they want to have an alternative instrument. So in the framing stage, that's the moment of, "Okay, we might need to change the strategy." Because before, we thought our strategy really needed to focus on the supply chain area. Instead, probably the good thing that we can do is try to make sure that the user gets a lot of different instrument alternatives shown to them. So it's a process of having our assumptions validated, and then how we can prioritize the solution to try.

[00:12:03] Host: Great. I love the example, because it was more your assumptions being invalidated, which is as good as validating assumptions, because you're figuring it out. So thanks for that insight into how you work.

Strategy inside an existing product at Booking.com

[00:12:15] Roberta, you've got a different challenge, in that you have an already existing product. How do you go about creating that product strategy, and how much involvement do you have, or is it just handed to you, because you're part of the bigger Booking.com product?

[00:12:37] Roberta: It's a bit different, of course, because the product exists. As I mentioned before, we know we are in this homes department, let's say, so we know our scope eventually is to make it easier for users to find and book these kinds of properties. And we know each team has more or less an area or a topic that they touch upon. The way we work is we're quite free in deciding what we can work on and what we can ship, according to the business and the user needs, but of course we need to map them to the overall department strategy. Usually what we do is define: what are the user needs that we want to tackle this semester and this year, because we work this way. Then based on that we make these objectives, usually from three to five, let's say, which can be different. And based on that we develop the strategy. Usually the product manager drives the team, but it can be that the UXers have a lot to say about the strategy, so they contribute a lot. It's a team effort, let's say, in this sense.

[00:13:58] Host: Great. You said you start from the customer needs. Two questions on that. You said before that you have your departments, and their mission and their goals cascade down to your teams. So when their goals come down, are they customer needs or are they more business needs?

[00:14:20] Roberta: Usually both. We tend to find a compromise between the two, and UXers especially fight a lot for having the user at the center of what we do. It happens also that we might push back on something because we don't see the value for the user, so we actually make the team change what they should focus on.

[00:14:45] Host: Great. I've heard people talking about pushing back against the business objectives, but it's definitely hard, because a lot of companies say, "Okay, we need to grow X amount of market share, we need to earn X amount of profit." But it's great if you are able to fight for the voice of the customer.

[00:15:05] Roberta: The good thing is that everybody is very open to discussion, so we also have a lot to say in that direction. And what I explained in the talk is an example of something that came out, in this case, as a business opportunity, and then we, me especially, challenged a lot back on this product, and eventually we shaped it in a way that was more user-focused.

Getting buy-in: why, what, who and outcome

[00:15:32] Host: Great. Carrying on from that theme, then: getting buy-in. If you've done all of this research, how do you convince people that these are the three to five customer problems that we should focus on, that these are the most important ones? I guess there are probably multiple people you need to convince. There are the people in your team, there are your stakeholders, there are the customers themselves, to adopt new products. So where do you start when you're trying to get that buy-in, and how do you go about doing it?

[00:16:07] Roberta: Usually everything comes back to the data that can be prepared when you want to get the buy-in. Let's say I start by defining the problem statement, the business opportunity and the final outcome. To do so, I always ask myself: why, what, who, and the outcome. In this sense I can say, for instance, why do we want to do that? What data are we basing this upon? Then what: what do we think will be the solution for this, what are some high-level approaches that we can take to solve this problem? Then who, meaning defining the target: who are the actual users that we want to target? It can be a certain type of customer, or it can be the host, the owner of the properties. And then what will be the final outcome, meaning how do we define whether this strategy is successful? To do so, the first thing is really to gather data, which can be, as Fani mentioned, competitor analysis, market research, or internal research. We deep dive into previous user research, into previous A/B testing that we ran, so we find some proof that we actually need to work on this.

[00:17:33] Host: Great. So you've dug in, you found some data, there's a problem with one of your customers. How do you then convince others? Yes, the data would back it up, but I'm sure there's data for ten competing different things. So what are the steps that you take to convince people that this is the right product strategy to follow?

[00:17:56] Roberta: Usually it all comes down to the outcome: how this is aligned with the department objectives. If you try to find a way to speak the business language and demonstrate, "This is really something which can bring us success aligned with our objectives," which can be more bookings, for instance, or fewer customer service tickets, something like this, then it's easier to convince at least your team and your immediate stakeholders. Then there is another part, which is the external stakeholders.

Working with other teams and resolving conflicts

[00:18:36] Host: On the external ones, you touched on the fact that you have a team structure in Booking. Are you able to work purely autonomously, or do you need to work with other teams as well?

[00:18:49] Roberta: It depends on what we want to do. For instance, the product I mentioned in the talk, which is a quality rating system for homes, was mainly autonomous, because it was our product, we were doing all of that. But on the other hand there were all these touch points that other teams were owning, so we needed to coordinate with them, and explain to them what we were doing and why we wanted to do it, and try not to create any conflicts. Because as we run A/B tests, we need to be mindful of when we run what, so they don't interact with each other. So there is another layer, convincing external stakeholders, which is more or less the same: you need to be very prepared and explain the reasons why you want to do something.

[00:19:45] Host: Okay, I'm going to play devil's advocate here. In a perfect world, you have this very data-driven conversation and everything works out perfectly. In the real world it tends to be a bit more messy and complicated. So can you give any examples of how you've actually dealt with this? Maybe two teams had a bit of a conflict or something, and how you went about solving that.

[00:20:11] Roberta: For instance, in this case, if we need to revise the product strategy or the roadmap because it goes into conflict with other teams, then we try to find this compromise and say, "Okay, maybe in this certain period I'm running this A/B test, then you can run yours." If we know we're blocked on something, for instance, let's say we're blocked on the customer side of this product, then in the meanwhile we might decide, "Okay, we go on the partner side." So it's always a balance, let's say. It's always like this, because eventually there is no one telling us, "You need to do that, the final decision is this." We're actually free to figure it out ourselves. When it's very, very bad and we cannot really align, then we escalate, of course, and someone decides. But most of the time, between the teams, you can agree on your product strategies. Everybody knows that each team has its own things to deliver, so we try to find this compromise between us. It's not super perfect, because you lose a lot of time anyway.

[00:21:33] Host: It sounds really interesting, because that's one of the challenges that I hear a lot: as companies try to create autonomous teams, getting the boundaries right is never perfect. There are always going to be overlaps. I like the way they let the team solve the problems.

[00:21:52] Roberta: Ideally it should be aligned on a high level first, and then once we encounter this level, there should already be clarity on, "Okay, this team is working on this, so they might overlap." Sometimes it happens, sometimes not.

Getting buy-in as an outside consultant

[00:22:12] Host: Great. I'd like to jump over to Fani again, just talking about getting buy-in. You talked about your approach for getting the product strategy, and this is where I see it being a difficult challenge, because you're a consultant, external to the company. How do you go about trying to get buy-in with the companies that your research and your strategy is the right way to go?

[00:22:39] Fani: That's actually true. First of all, I'm definitely working as a consultant, but the other part of my responsibility is also enabling the product managers on the client side, so they can also be product managers. Because most of my clients are probably corporate companies, and they might not know what a product manager is. So that's one other part of my responsibility. From the beginning, before we start the project with the client, we have to align: we define our OKRs together. When I say we here, it's definitely the sponsor of the project on the client side, who actually signed the check to hire us, and also the team. The OKR is really the anchor for the whole project, and we definitely need to review the OKRs on a weekly basis, just to try to make sure that everything is on track, or if it's not, we can also define what the action items are.

[00:23:54] So we definitely define the OKRs early on, but sometimes in the middle of the project things can happen, things can change. There might be a specific strategy or a specific decision that we have to prefer, and this is the time that we definitely also need to manage stakeholder expectations. Usually what I would do is discuss our alternatives together with the team: "Okay, these are the facts, this is our current problem, and these are the different alternatives for how we can approach it, and what the pros and cons of every different solution are." Then as a team we can probably agree which solution we want to take, based on our current knowledge and on what we have already investigated.

[00:24:50] This is also the moment that we need to understand how to pitch to the specific stakeholder. The reason is that in this negotiation part, the moment that I want to present something to the stakeholder, it becomes my product, and the stakeholder here becomes my user. So I have to understand how I can pitch it so that it's easy for them to understand, because they might have their own specific agenda, and if I don't understand their specific agenda, it would be hard for me to convince the person. So first of all, I try to customize my pitch according to the person.

[00:25:39] The second thing is, usually I try to make some kind of decision tree: "This is the problem that we have, these are all the different alternatives that we can do, and these are the pros and the cons." I'm trying to really map and visualize it, to make the conversation with the stakeholder much easier. The third thing is, I think I had to come to the realization that I need to make sure that I'm not married to my idea. Because there is a certain point where the stakeholder, even though I'm showing all the data, all the supporting material, might say no, and I should not take this personally. So I should prepare myself to not take things personally; I need to expect this to happen.

[00:26:31] I think the fourth thing is, I always make sure that I understand what outcome I want to achieve from having this discussion with the stakeholder. Is it a small decision or is it a big decision? A small decision might be one where, if we made a mistake, it's easy for us to roll back, or it's easy for us to recover from it. Or is it a really big decision, where we need to really think about the potential risk if we go through with it, which might be changing the business model of a specific product? So we need to make the stakeholder realize whether this is a small decision or a big decision.

[00:27:20] The fifth thing is really to come to an agreement on whether we are looking for a commitment or for an agreement. Because I'm working with the client, I don't have full authority within their organization. So as a consultant I have to accept that, let's say, the stakeholder can say, "Yeah, I appreciate your work, but I think I know my company really well, and this is how we do it." And then I say, "Okay, I disagree with you, but I will commit to doing it." That's, I think, the difference as a product consultant, I would say.

[00:28:08] Host: The Jeff Bezos disagree and commit.

[00:28:13] Fani: Exactly.

Moving clients from fixed scope to an adaptable strategy

[00:28:14] Host: I really like the way you were saying your stakeholders are a customer as well, so you have to do the whole customer research and understanding, put yourself in their shoes. It's a really good approach. One thing I want to ask about: in my consulting days it was very difficult to have an adaptable product strategy, because from the very get-go the agreement would be, "You're coming in, you're going to build this, these are your deadlines, this is your time and your cost." You mentioned that a lot of your clients are very traditional, and they don't understand product management, or they don't have those roles. So how do you get past that fixed time and cost, build the scope as it was defined, to move them on the journey to adapting as you learn?

[00:29:03] Fani: I always challenge them in terms of, "I understand this is your current organization." In my talk I discussed the outcome-based roadmap. Before I try to sell this outcome-based roadmap, I always ask them what their roadmap looks like, how they define the roadmap, and what the pain points are with the current roadmap. They might say, "Actually, I see the roadmap as a timeline, and most likely we never actually hit the target. We never actually finished one roadmap in a quarter." Then I ask them, "Okay, is there anything that you have changed in the past, let's say, five years? Is there anything that you've changed in your framework? If you haven't changed it, are you willing to make a little bit of change?" Because that's craziness, right? You are doing the same thing and expecting different results. So what I ask of them is just their openness to try a different thing, and we are transparent during the project, working with us, so we can see whether this is working out or not.

[00:30:09] I think it's really true that a lot of organizations are really waterfall; they probably have a top-down approach. And as a consultant I have also realized that this is a problem that I cannot fix in a six-week project. But what I can do is try to make sure I enable the team that's working with me, pairing with me, to understand what lean and agile are, how to work in a different way, and then they might be an advocate [?] for their own organization. That's another way to look at it.

[00:30:52] Host: Brilliant. I'll just ask the same question to Roberta, particularly for our audience, where a lot of people might be coming from that position where the strategy is defined and they're just told to follow it. Do you have any advice that you would give to try to shift to a more experimental approach and a more adaptive product strategy?

[00:31:15] Roberta: In general I would say try to demonstrate the value of what you're proposing. If you explain to them, as Fani mentioned, how can you expect something different if you always try this approach? So try to say, "Okay, we can try out this new approach. We can see fast how we can fail faster." We say we fail fast, we iterate fast. In this way you don't waste a lot of time working on something that might be unsuccessful, but you can shift the product strategy very quickly, or shift the feature you are building very quickly. So my advice would be to try to build a presentation that explains to them what the benefit of this new approach would be compared to what they are used to doing.

[00:32:13] Host: Great. And this one, with one minute left, is probably a bit of a difficult one. I've found when I've tried that, people take offense, because they go, "What do you mean it's not working? I'm very good at my job. I've done the research, I've done the due diligence. Who are you to say what I'm doing is wrong?"

[00:32:33] Roberta: It's a matter of words. I wouldn't say, "This is not working," but I would make it sound like it can be improved, because everything can be improved. Make it sound more that way. But of course you might encounter resistance like that; it's something that happens.

[00:32:53] Host: Great. I think we're actually just out of time now, so I'd like to thank Roberta and Fani for sharing your insights. I really enjoyed the conversation, I hope everybody at home did as well, and I'll pass it back to Jovi. Thank you.