Evolving A Mature Product

Parul Goel at UXDX Europe. Video: https://youtu.be/S6AS9y-UFs8

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.

Resolution Center, and three years on one initiative

[00:00:04] Hello everyone, it's a pleasure to be here with you guys. I am going to start by telling you about one of my products and initiatives that's close to my heart. So let me start by asking, any PayPal users here? All right. Any Resolution Center users here on PayPal, has anybody used Resolution Center? All right, so a few of you. Well, most of you are fortunate, you haven't had to use Resolution Center, because you use Resolution Center only if you have an issue with your transaction.

[00:00:38] So I do want to spend two minutes talking about the product and the initiative, because I will use it as an example all through my talk. Resolution Center was a product I worked on. It is our dispute and chargeback management portal. What that means is, let's say you are a buyer, you bought something online and you did not receive your item. You can go to PayPal, you can go to your Resolution Center and file a complaint. You can say, oh, I bought this and I still haven't received it. So PayPal will then intermediate between you and the seller to make sure you get what you want. So we will let the seller know that somebody has filed a complaint, so the seller will go to their Resolution Center and say, oh, you know, I did miss the item, here's the tracking information, so it will be delivered tomorrow. So you get the point. It's a way for buyers and sellers to manage anything that has gone wrong with the transaction.

[00:01:37] So Resolution Center has been a part of the PayPal experience from day one, but for the first ten years nobody really paid any attention to it. It just stayed the way it was built and no investment was made. So no one was surprised when for two or three years in a row it was voted as one of the top five most painful experiences at PayPal. And so finally we decided to do something about it, make an investment, and there was this huge initiative kicked off to rewrite Resolution Center to address whatever our customers were complaining about. And that's where I came in, I got the role of the product lead on this initiative. I was the product manager for Resolution Center.

[00:02:28] Now, I spent three years on this initiative, I spent three years as the product manager of Resolution Center, and the outcome of this initiative is something I'm very proud of. We improved NPS, we lowered losses, we really did do what we had set out to do. So something to be very proud of for me. But when I think about the journey, what it took to get those results, that is the challenging part. Those three years were not easy three years for me, in fact they were quite challenging, and I was very frustrated at times. I felt like I was running really hard but I wasn't getting anywhere. It wasn't really a very blissful time in my career.

[00:03:13] And when I look back in retrospect, there was one foundational error I made, which was to assume that, oh yeah, evolving a mature product like Resolution Center is like building a new product. Same skills, same mindset, the tools that have carried me over so far will work here also. And that's where I was wrong. There are some very significant differences between when you are building something from scratch versus when you are evolving something that already exists. So I'm going to share with you three challenges that are unique to evolving a mature product, and I'm also going to share with you what I wish I had done at the time to either avoid these issues or to address them.

Challenge one: resistance to change

[00:04:06] My first issue that I ran into pretty quickly was resistance, resistance to change. Now I was new to Resolution Center, I had no history with it, but most of my stakeholders did. They had been working on Resolution Center for a while, some of them were even part of the team that had built Resolution Center ten years ago, and so they expected it to work a certain way. In fact, their metrics were based on Resolution Center working a certain way. They were all part of the initiative, we had this huge kickoff, everyone agreed that yes, something had to change, there was a lot of room for improvement. But there was this assumption that this change will be outside of me, it's not going to change my role, it's not really going to touch me.

[00:04:57] And we discovered these assumptions pretty quickly when we got into execution. So from the product side, we looked at the list of complaints, we looked at data, and one of the low-hanging fruits we identified was the dispute filing experience. As a buyer, how do you let PayPal know you have a complaint? So we optimized that flow, the user experience. We made it a single page flow from multiple pages, we cut down all the irrelevant information we were asking for, we upgraded it, it used to look like something from the mid 90s. And we user tested it five times, like five iterations where we would present it to users, get their feedback and then incorporate it.

[00:05:43] So a month and a half later we were super proud of what we had come up with. We being product, engineering and UX, the team who had built that. So I had to get buy-in from our customer service team, our ops team, before we could launch it. When I presented our new and improved experience to them, I was just shocked by their reaction. They were like, no, you can't go live with that, this is not what we are looking for. And I was like, why, what's wrong? That it's too simple. And to me as the product manager it didn't make sense, like, but that's our goal, we are trying to simplify the dispute filing experience. And they said, no, if you simplify it then we will get a lot more buyers filing disputes. Those are the disputes that the customer service team then addresses, and we are just not resourced for that. This is going to impact our net [?]. You cannot go live with this.

[00:06:47] And eventually, after a lot of pain, we did address these issues, but what it really hurt was the team dynamic. In the very beginning there was a lack of trust. I mean, I can imagine from the ops team they were like, who are these people, they just joined the team and they're acting like they know what they're doing when they don't. And from our perspective, I can tell you we were like, who are these people holding our progress back, we could do so much without them. And this was just one of the instances, we had several of them where we realized, oh wait, we are not on the same page, product, policy, ops. We just had very different ideas of how we would improve Resolution Center.

[00:07:32] So that brings me to my first lesson. If I had to go back, this is what I would do differently. Number one, I would go in knowing that I am going to be an agent for change, which means there's going to be resistance, which means this is not about product, it's not about policy, this project is going to be about people. That's going to be my main focus.

[00:07:58] The second thing I would do is I would educate myself a lot more. I was very focused on product, I knew how Resolution Center worked inside out, but I did not know why did ops care about it, how is it connected to PayPal losses. Those were the areas I hadn't invested in enough. And if I had to do it again, I would spend a lot more time understanding the areas which were even outside of product, because if I had done it, if our customer service organization felt like I understood them, I wouldn't have gotten that pushback, or less.

[00:08:34] And finally, I feel like, looking back, we skipped a huge step. Our overall KPI was to improve NPS. There are hundreds of ways you can improve NPS. We didn't really decide on which ones are we going to do, which ones are we going to address first. So instead of going into solutioning, I would have spent a lot more time with stakeholders prioritizing what problems are we solving for, how will we define success. And what this would have done is brought up some of these conflicts earlier in the process. It would have really saved heartbreak all around.

[00:09:13] So this was my one big lesson, that when you are evolving a mature product you are really a change agent. Working with people, bringing them along, is your number one focus, what you would spend most of your time on.

Challenge two: baggage

[00:09:31] Number two: baggage. Mature products come with a lot of baggage. Now let me give you my example. When I came to this country 20 years ago, I came with two pieces of luggage, that's it, that's what I brought to this country. Today when I have to move it takes four movers, a large truck and an entire day, and I don't even know where all this stuff came from.

[00:10:00] Same thing happens to our products. When we start, we are solving for a small set of use cases, we are solving for a segment. But over time these use cases, these segments that we are solving for, expand. And that's a good thing, we are adding more value. But when you are evolving a mature product, as a product manager you have to figure out what to do with them, what to do with all of these boxes. Now they are yours.

[00:10:29] So the same thing happened with Resolution Center. We realized that it's the default product for any resolution flow at PayPal. Whenever we launch a new product at PayPal, Resolution Center gets a new flow. And when we looked at the data, 50% of our flows accounted for 80% of the traffic, which meant the other 50% only had 20% of the traffic we received. So as a product manager I had to decide, what do I do with the bottom 50%?

[00:11:07] So as I saw it, I had three options. Number one is shut them down. We don't need them, there isn't a business justification to keep it around, why have I to carry dead weight? But I wasn't sure if I could shut it down. Is it a compliance violation? Would customers notice it's gone?

[00:11:26] Okay, second thing was, okay, you know what, let's take it along, let's also include it in our rewrite. But then I was literally doubling my scope, and knowing that there isn't much of a value from the bottom 50%, I was signing up for asking for a lot more resources, and really prolonging my delivery time.

[00:11:52] The third option was, okay, you know what, I won't shut you down, I won't take you with me, I will just leave you where you are. So bottom 50%, you can stay on the old stack, old experience, old policies, I won't rewrite you. But then as a product manager now I had doubled my product. I had the old experience to worry about and the new experience. My engineers had the old stack and the new stack. Now policy stakeholders also had old and new policies. And there was no end date to it, so which also wasn't very efficient.

[00:12:29] And really what I ran into was I had no framework for how to deal with these issues. So if I had to do it again, when I work on a mature product I would know that I have to be ready to make some difficult decisions, some unpopular decisions, which might include breaking up with customers, saying goodbye to some customers.

[00:12:54] But to make these decisions easier, there are two things that I need. Number one, I need extreme clarity into my business goals. What am I trying to do, what is this initiative, what is this product supposed to do? Because that's going to be my guiding star in making these decisions: whom do I keep, whom do I discard?

[00:13:15] The third thing is I would spend time either developing or borrowing a robust phasing out strategy. What do I do with the flows, in this case, that I don't want to keep? Are there other PayPal products that I could merge them with? Can I merge them with the top 50%, do these variances really matter? And let's say the decision was our last resort, now we can't carry them, we can't keep them, they are not business viable, we have to let them go. Then what is my sunset strategy? How much notice do I give our customers, what do I tell our customers, who's sending out these emails? These are all part of a phasing out strategy.

[00:14:07] So when you are working on evolving a mature product, make sure you have a framework to deal with this. You will have a lot of baggage. How do you make your decisions about what goes in the keep pile, what goes in the discard pile, and then what do you do with this discarded stuff, how do you deal with it? That's something that will be your problem, something you have to be ready to deal with.

Challenge three: tunnel vision

[00:14:32] And finally, my third challenge that I ran into was tunnel vision. Now, before any product is built, it starts with a problem statement. There is a problem you're trying to solve for, you look at some of the solution approaches for that problem and then you pick the one that's best in your context. That's how your product is built. But once you build it, that becomes your default solution to that problem. So where do customers go to file a complaint? They go to Resolution Center.

[00:15:13] So the same thing had happened with Resolution Center, but it had happened 10 years before I arrived on the scene. But when I got there, our goal became to rewrite Resolution Center. That's what we became focused on. We never really took the time to say, is the problem statement still valid, has it changed in the last 10 years? What are some other solutions we can explore other than Resolution Center? I mean, our goal really wasn't to rewrite Resolution Center, it was how do we help customers who have issues with their transactions.

[00:15:52] There is so much more that we could have explored. Maybe we could have optimized the transaction flow, maybe eliminated disputes altogether or reduced them to such a small number we don't need a Resolution Center. We could have launched an insurance policy where customers don't have to complain at all. So there are all of these things we could have considered doing, but we didn't, because we just fell down to how do we optimize the solution ahead of us.

[00:16:21] And looking back, this really is my biggest regret about Resolution Center. And because we defined our goals so narrowly, it was a squandered opportunity. Ten years later Resolution Center had a chance [?], and we did good but we could have done great, had we really taken a step back.

[00:16:46] So this is what I would do differently if I were doing it today. I would define my role a lot broader than I did then. And you know, for us who are in technology, we do have that privilege, we do have that luxury, where we can define a role. Nobody told me go reimagine Resolution Center, but nobody asked me not to either. To some extent I made that decision that this is what I'm going to focus on. So I would define my role a lot broader.

[00:17:15] Secondly, I would zoom out. Forget Resolution Center, that's not what we are trying to do, it's a customer problem we are trying to solve. And there are several ways you can use to zoom out. You can ask yourself why five times. Like, why do customers file disputes? Because they don't know what's going on. Why don't they know what's going on? Because the seller did not send them the tracking information. Why didn't the seller send them the tracking information? So you get the point. You can ask yourself why a number of times and get to the core of the issue.

[00:17:51] The second thing you can do, and this has worked really well, is come up with ten ridiculous ideas before you get to a serious solution. So for example, for Resolution Center, if a buyer files a complaint, you know what, we will just give them a refund, that's it. And PayPal might not make any money, but that's a possibility. The second potential solution is we can detect issues before our customers detect issues, so we will make our systems so intelligent that we can discover and address issues even before they happen. So if you really start thinking broadly and are not really confined by feasibility, then you will really start seeing possibilities in a lot of other areas.

[00:18:36] And finally, avoid the incremental innovation trap. And that's where we landed up, we just ended up doing a lot of innovative things but in a very, very narrow scope. So if I had to do it again, I would actually just really look at the big picture. Take a step back, a huge step back, and look at the big picture.

In conclusion: adopting a teenager

[00:19:03] So those were the three problems I wanted to highlight to you. In conclusion, this is what I want to say. I have heard people say that building a product from scratch is like giving birth, giving birth to a baby. So if that's the case, then evolving a mature product is like adopting a teenager. They come with their personality, they already have a history and you have to honor it, you can't ignore it. So it does take skill, it takes patience, partnership, some therapy, but it's a cause worth championing.

[00:19:38] There are so many products and experiences out there that are way past their heyday, and they do need evolution, they do need attention. So if you get the opportunity to manage a mature product, take it on. Go in knowing that there will be baggage, there will be resistance, but also know that it doesn't have to be a rewrite or a revamp or a replatforming. It truly could be a reimagining. You really have this open field ahead of you and you can decide what you really want.