Reinventing the PayPal.com Experience

Transcript

Jared Spool: ...Bill is VP of Next Gen...

Bill Scott: Commerce.

Jared: ...Commerce, at PayPal. I've known him since the early days, back when he was at Sabre.

Bill: We go back about 40 years, or so, ain't it something like that?

Jared: Yeah. Something like that.

Bill: 50, 60, something.

Jared: Something incredible.

Bill: He was a crib mate [laughs] .

Jared: Yeah. You've been at PayPal now...

Bill: Almost four years.

Jared: Four years. Since you've been there, you've had some absolutely amazing accomplishments. Which one are you particularly proud of?

Bill: I think when we reinvented Checkout. Checkout product had pretty much stayed the same, for probably five years. When David Marcus became president of PayPal, he had been part of an acquisition there.

Jared: Checkout is the process where a third party on an e-commerce site...

Bill: Yeah. You're on an e-commerce site.

Jared: ...has an option that says, "Pay with PayPal."

Bill: Pay with PayPal, and you go through the flow. The trick with Checkout is that if you just have a slight variance in conversion, of the amount of people who were successful going through a payment checkout flow, it's a lot of dollars. To change that is not a trivial thing.

When David Marcus, who had been part of the acquisition, took over as president, he had a startup DNA. He got myself, and few other folks together in a room and said, "Let's rethink Checkout from scratch." The way we did it was we got maybe two designers, three designers, two or three product folks, three engineers, and we got a war room, a conference room.

We holed up in there, and basically started sketching. Within a few days we had a working prototype, that took David's Balsamiq Mockup. I love when a president of Accounting does Balsamiq Mockups. Took it and we made it live, to actually process some payments.

By the next week we had users coming in, and doing usability testing. That was a really different way of working, and I think that's one of them.

Jared: Help us understand how different that was, for PayPal.

Bill: Basically Jeff Gothelf, you guys may know Jeff Gothelf, who does the LEAN UX book and workshops. We had him coming in, and do a forensics on the design organization. One of my favorite conversations with Jeff was interviewing a designer, who said they had spent three weeks creating these beautiful Photoshop mockups.

They went to show it to the engineer, and the engineering team laughed at it. The designer went away crying. I call it pissing on your Picasso. The whole mode of operation was to create something, throw it over the wall. Karen was my partner in crime there, before she went to MasterCard a year and a half ago, at PayPal.

She's nodding her head, and she knows the experience.

Jared: Karen Pascoe.

Bill: Karen Pascoe. Yeah. That was the difference. I remember Cody, who was our designer on that Checkout product in that room, made an interesting observation the first day. We'd been sketching on the whiteboard, and one of my guys was coding it in real time.

At the end he goes, "OK. Should I use an OmniGraffle, should I use Photoshop, should I use Ajera? Where should I put this in?" Jeff, who had written the code, turns the laptop around and says, "Well here it is." Cody goes, "Well what's my job?" He had been seduced into thinking his job was just documentation.

Really what our job is, is delivering experiences together. That was the big "Aha" moment, in that room.

Karen McGrane: I'm so impressed, by everything you've been able to accomplish at PayPal and beyond. What advice would you have for other organizations, that are looking to take on this transformation? What principles, do you keep in mind?

Bill: I think to change an organization that big, you have to have support. There's no doubt about that. You also have to get a groundswell in the grassroots. To do that, you got to yourself have some very strong principles you believe in. What's going to happen is it takes an enormous amount of persistence, beyond measure, to continue to go against all the things that will fight you in an organization.

Basically organizations are set up to stay the same, or go the wrong way. If there's anybody who said, build up an organization and resist any change. You have to have this persistence, that is held in some strongly held beliefs. Now these principles, these beliefs, don't change from company to company.

Everywhere you go, these same principles hold. Some of mine for teams are getting to a shared understanding, between all the disciplines. Engineering, design, product, marketing, legal. Everybody has a shared understanding of how we get product out the door, and deep collaboration.

We know how to work together. We believe that it's a team sport, that we work together, and then that continuous customer feedback. Believing that if we can get back to the problem, we'll stop defending the solution, and we'll start coming up with great ideas.

Those are three key principles for me, the understanding, the collaboration, and the customer feedback, that I used over and over in my talking to teams. When you have that persistence, that gives you something that just roots you and holds you solid, but then you have to have improv. You can't just be rigid.

I've seen people come into organizations, who try to change an organization, and they have a playbook they did at the last company. You've probably all seen that, right? They come in and they've got some processes, or they got some programs. Whatever it is, they bring it, and they try to apply it.

It's met with such resistance, it's so ugly, it's so stale. When I came in, basically my pitch to be hired was, "I don't know what the hell I'm going to do, but this is what I believe. I'll make sure that these beliefs, get in the organization." They were dumb enough to buy into that pitch.

[laughter]

Bill: I basically was able to go in and have humility to start with because I felt like within a company like that, even if on the outside you go, "Man, this is so screwed up," because PayPal in 2011, the user experience looks like it was from 1999. It was so horrible, you go, "Is there anybody here any good?"

Of course there are lots of good people in that organization, but the problem is everybody gets stuck, so you have to believe there's wisdom in the crowds. You have to believe that there are a lot of people who want to do the right thing, so you can find partners, allies, and you can start teaming with them.

That combination of that dogged persistence with a humility and improv to listen and to reflect, and then to put those together into a playbook, a solution that's in context for the organization. Listen, that changes too. That's one of the shocking things. You sort of get something going, and and you go, "Wow, that's going great."

Then you have the leader of organization leave the company, or a big reorg happens, new people come in, other people leave. All of the sudden, the playbook doesn't quite work the same. You've got to readjust and do it again. That's where the persistence really gets really hard, because you've already done this once. Now it's twice. Now it's three times. It's just that constant persistence and improv.

Jared: Are there principles that drive that playbook? Do you use some sort of overarching principles of what you guys were about and what you're trying to do that lay out the pieces of the playbook, so that when that shift happens, the playbook ends up changing?

Bill: To me, that third principle I talked about, that customer feedback, is the most important, because every time I see teams that get stuck or start fighting, or you got design team versus the product team versus engineering team, they've always forgotten the problem. That's my experience, anyway. Maybe I'm too simplistic and reduce it too much, but it does seem to be the case.

The first thing I try to do is start asking what problem we're trying to solve, and then make sure you get customers in front of our people. Have them go to usability, have them do deep design research, actually do field visits, follow the customer. Any of those things we can do to get them to see a real user using the product.

It's amazing how it jars everybody out of their comfort zone. The designer starts thinking, "How could I solve this problem?" The engineer starts thinking, "I think I could do this with the code that..."

If you get legal, you have the "yes" lawyers, that's what we experience too. If we got legal in the room with us with a whiteboard, and say, "Here's the problem we're trying to solve. You have problems you're trying to solve too. Walk us through that. We'll walk you through ours." Then it was amazing how the legal team became a design team.

Jared: What happens when you put a lawyer in front of a whiteboard? Do they just dissolve?

[laughter]

Bill: These didn't anyway. I think that could be the case. That's a really good point.

Jared: "It's a document that gets erased! We can't have this!"

[laughter]

Bill: They used the Sharpie.

[laughter]

Jared: That'll do it. They know how to leave their mark on an organization.

Bill: It's pretty simplistic but I keep putting in my head that if I can put a smart team together and I can soak them with enough context of the user's problems, good things will happen.

Karen: I like how you described that, like soaking them in customer feedback.

Bill: In fact, the team I have now went from having a really large organization, 400 or 500 people to just 10 people. They're design, product engineering, analytics, strategy in one team.

My job at this point is, how can I get as much context about the payments industry, about the financial industries, FinTech, everything in to their heads, expose them to as many problems as possible, because this team is really good and they will come up with great ideas that I never conceived of.

Jared: You've been at PayPal now for four years. When I first met you, you had just come to Yahoo, and then you went to Netflix, and then you went someplace else, and then you went back to Netflix.

Bill: Couldn't get enough.

Jared: You could not get enough of Netflix.

Bill: Yeah, I've finally got enough the second time.

[laughter]

Jared: You've finally got enough. You were at Sabre before Yahoo. These are structurally very different organizations.

Are there things that that perspective gives you of these different organizations, where you realize there are just certain things about how do you start working with a new culture, how do you get in there, do you have to tweak that playbook that you have, that you're using based on the culture? Are there just things that basically just work and you just bring that with you?

Bill: You don't do that. The first thing to recognize is that what's common with all these organizations is there are people there. We're all kind of messed up.

Jared: It's like Soylent Green, right? They're made of people.

[laughter]

Bill: Exactly. I don't know if you've noticed, but we're all pretty messed up in different ways. When you put us all together, it's a pretty interesting soup that happens. Each of us have an agenda. We all try to have pure motives and pure agenda, but we all have agenda. We all have some self-interest, and everything else.

Recognizing that out of the gate, and then as you start working with people, trying to understand where they're coming from, and how can I help make them successful, without sacrificing your principles, without sacrificing the product.

Sometimes it's as simple as, you find a person who's a decision-maker, and you just take more of a back seat, a supporting role, making that person really successful and you just don't care about your credit, right?

I have a Zen view of it, that if you end up doing the right thing over time, the organization recognizes it. If they don't, you shouldn't be there. It's pretty simple. It gives you some freedom to not worry about who's getting the credit, and just go do the right thing. Then, you do have to, in these big organizations, in every case - PayPal probably the more extreme case. I had to note certain people in the organization that I could not move.

They just weren't going to change, so I had to route around them. I tried not to do too much of the routing around, but some people you just had to route around. You just prayed for the day they left. I'm just being real honest with you here, I remember driving into work one day and we had to call this one person that had left the organization, they were telling us.

I was in the car. The 101, I'm sure people are looking at me crazy, I'm going "Yes! Yes! Yes! That [indecipherable 12:33] is gone."

[laughter]

Bill: They caused me so much grief, it is very frustrating when you're working with people who are very stubborn. I had a guy sit down with me and told me he was upset with me. I said why. He said, "You're affecting my goals. I'm not able to achieve my stated goals." I said, "I didn't come here, actually, to help you achieve your goals." Just, newsflash.

That was the kind of people sometimes I had to work with, and Karen's nodding her head. She knows. She and I could name the same the people.

Karen: Let me follow up real quick, and ask, similarly, how did you get executive air cover in all of these different roles. You worked with Larry Tesler at Yahoo, and Reed Hastings at Netflix. How do you get executives to support you?

Bill: I think, speaking the language of the customer is actually speaking the language of business, if you think about it. When I came into PayPal, for example, I didn't come in and say, "Hey," because one of the big things I did was change the whole front-end technology stack, so we could get to continuous delivery and fast releases.

I didn't come in and say, "You know what, we need to stop doing Java, we need to start doing No JS," which is what we did. I didn't know if that's really what I wanted to do or not. I came and said, "You know what we need to do, we need to get to rapid experimentation." The UI layer is the experimentation layer.

What I would do, every time I've gotten a chance to be with one of our executives I'd already thought of Tweetable Moments. Tweets that would summarize something. I would actually give that sound bite to them. When you think about it, the user interface layer, is the experimentation layer. Then, I would hear other people saying that, which was cool.

I put these little memes out there. "The hardest thing that we face is moving from a culture of delivery to a culture of learning." They'd go, "Yeah. That's right." Then, we'd talk about that, right? It would start a conversation. To me, these Tweetable moments were key to that, because you only get a few moments of an exec's time. You want to make it count, and it should be something that has a business impact.

I tried to be, you know I was coming from an engineering perspective in the engineering teams. I try not to wear one hat. I try to wear the design hat, the product hat, the legal hat, the business hat, so that when I talk to anybody, I can come from their angle and connect with them. I think that connecting at the base need level, what's the real need we're trying to solve, resonates.

If you come to leadership you're saying, "You know, we need to go to No JS," Who cares. That's great, but three years from now, it'll be something different. Those aren't really the solutions. How are we going to get to a place where we can beat our competition. We can deliver better products to our customers. We can do it really fast. We can learn, learn, learn, learn, learn.

The learning meme or mantra really resonates with leadership.

Jared: The structure of PayPal. Checkout is just one part of the PayPal empire. When you joined it, PayPal was part of a bigger eBay empire, which it's now severed itself from in some way. At the other organizations that you worked at, did you see that there was organizational structure influencing the way decisions were being made, and how did you just break down those?

Bill: It's really huge. I think one of the things I learned at PayPal being in executive leadership, was just how important in a reorganization, who you end up being in staff with each week affects the whole organization. I don't think you realize it until you're actually in senior leadership and you start having that weekly staff meeting.

Now, professional services is on the same staff with you. Guess what. Professional services issues will come more to your fore, and you'll start solving those problems that are affecting. Your merchants out in the field with trying to use the product, or developers using the product.

Whereas from there, in a different organization, you never are exposed to them except maybe once a quarter, you just as a human don't think as much about it. Here, you're in a staff meeting, it makes a huge difference.

The real work that happens in an organization always happens across organizational boundaries. You have to recognize where those connections are coming from. You also then have to then go, "OK, well where are the connections not happening," Then you really reach across the aisle and start making this happen. When I first got there, I did 100 interviews in about 45 days, something like that, right?

Jared: Who were you interviewing?

Bill: Everybody I could in the company. Anybody in leadership, individual distributors, leaders, executives.

Jared: Across different groups.

Bill: I tried to make it as far as I could. I created a full organizational map of the company. What everybody did. I'd create charts of all that so I understood what everybody's role was, what the subtlety of the different roles were. In a big organization, there's all these weird overlaps. They're not quite overlaps, but they're not fully overlapped.

Understanding it functionally, how somebody is working, that political context, that organizational context was really key. Once you've had that conversation, you've connected with somebody, even though it was 30 minutes, you have the right to go back and ask more questions.

There's somebody you've connected with that they'll listen to you the next time, if you made a good impression in your conversation.

Then you learn a hell of a lot. You get this organizational context and you get an empathy for the organization. I call what I did there at PayPal really was supplying design research methods to changing an organization. The actual organization is my user, in one sense.

You're doing those hill studies. You're talking to people. You're observing how people work. You're starting to diagnose and do forensics, and then come up with maybe what a playbook would do.

Jared: If you guys are starting to form questions, and I hope you are, the session questions channel in SWAK is where to put them, and then we'll go to them in just a few minutes. In terms of all these interviews that you did, I'm very curious when you got there, what was the viewpoint of design and user experience and how did that set your agenda in terms of what you wanted to accomplish?

Bill: Both design and the front-end engineering which I later called user interface engineering...

[crosstalk]

Bill: ...were very disrespected. They were pretty low in the totem pole, especially the front-end engineers.

Jared: Why was it? Do you have a sense?

Bill: I know in the engineering side, I can comment on that. I can comment a little on the design side, too. On the engineering side, what had happened was you had developers they called devs and then you had Web dev. It was actually said like that Web dev. It went down. It was like [does inflection] Web dev. The dev was lower and the Web dev and then dev.

It was basically, they had this templating language you had to use. You didn't write any real code, you wrote templates. There was not much respect from the actual engineers for the Web devs. I said we're now user interface engineers. Those guys are dev but we're engineers. I just upped the game and brought in some really awesome people and we started solving really hard problems. Before long, we became the most respected engineering organization in the company. We changed that game.

On the design side, there had been so many different leaders that had come into PayPal earlier on that had their own issues. It was seen more as just the last the resort. There was this big planning process that would happen, and then at the very end, design would get a chance to put their stake in it.

What really changed it was when Hendrik Kleinsmiede came in to PayPal lead design, Karen knows real well. In fact, Hendrik is over at VISA now. Hendrik, really, was good friends with Jeff Gothelf and believed in UX and Lean Startup. He immediately, before he got on, I reached out to him and said, "I hope you are thinking like this. He said, "I am. Let's do it together."

Us together, having that combined mindset brought design to the fore because we were partnered with our president. Basically, it was me and Hendrik leading the charge for the new checkout product. That put the head of design and the head of our engineering together to lead that and we were successful. It didn't hurt to be successful. It definitely helps.

Karen: Can you talk a little bit about leading the charge for more Lean UX or more Agile methods. You got a couple of slides if you want us to bring those up.

Bill: Yeah, just flip real quick, one forward. That was the room we got into to create a project we called Hermes at that time to recreate checkout. There was just a few engineers, few designers, product folks, a lot of white boarding sketching, a lot of real-time coding.

That was the start-up. What happened was more and more teams saw this effect of this and definitely wanted to do this. If engineers are exposed to this and designers are exposed to this and product people are exposed to this, there are very few who don't want to do this.

Jared: Walk us through this a little.

Bill: Here, what we did was we were doing a lot of white boarding. You could see on the left at the bottom, some mockups, printups. Basically, Eric and Jeff were doing a lot of the coding real-time. We go to usability on the right-hand side. We do that every week. Our rhythm at that time was Tuesday and Wednesday were about building for the next usability session. Thursday was usability sessions.

We did it in a write format, rapid duration testing environment where you change the code through the day as you need to. The engineers, designers, product people were in the room together observing users on Thursday. This required our usability team to change the way they work because they had to bring a report the next day. Friday, they had a report for us. David, our president, would also drop in to listen.

We avoided a lot of the highest paid person in room phenomenon because we had that report. David would have ideas. He was also pretty careful about saying, "Don't just listen to me, let's do what the users want to do," which was still hard to do because you pretend to listen to the leader. We would just test it.

Then, we'd decide what we were going to do and then Monday, Tuesday, Wednesday, we'd do that. We did that probably for 12 to 16 weeks that rhythm then we slowed it down to every two weeks. From there, just...

Jared: Before this project, what was the rhythm like?

Bill: Probably like towards mid or end of a project that we'd go to usability to see what they built.

Jared: Which is how many weeks then?

Bill: Probably, it could be three months or something like that.

Jared: You went from these three to five months cycles down to one week.

Bill: Yeah. The interesting thing is, it took us a long time to actually roll this new checkout out because you're replacing an existing product. It required the whole bottom of technology, all of the payments core platform to be refactored and redone. It changed the whole organization which was hard.

It took a couple of years because you have to get your conversion rate, the amount of people that are successful going through checked out to be as good or better than the previous one. It didn't matter if it's ugly or not. It's working. We surpassed that.

Now, we're in almost full ramp mode. It took a while to get there. That 12 weeks or so that we did that, the design really hasn't changed much since that 12 weeks.

There are a lot of tweaks we've done. The basic framework we came up with, the way we handle the wallet, bang different funding instruments, handling things as diverse as credit or whatever else while you're checking out. All that came about during these usability studies. That was a pretty fruitful time.

Jared: Where's Eric Boston? He's here somewhere over there. Elaine can come over to you with a mic. Eric's got a question over here.

Bill: This is the stump the chump?

Jared: This is. This is. Who's our contestant playing for?

[laughter]

[crosstalk]

Jared: Over there?

[crosstalk]

Eric Boston: I didn't know I was going to actually ask the question. My question is more around our team. We have multiple UX teams throughout the organization because when you have focuses on mobile specifically, web specifically and then we have a bunch of internal teams that are doing stuff just for employee facing apps.

We've been changing through the pace of UX within the organization. We still have teams that have UX in the titles, they do stuff that seems UX-like but yet they're implementation seems like it's always more like, "Well, we believe this therefore that's true," versus going out to the customer, doing interviews, doing prototypes. It's around like, we have some buy-in, but then it's like there's a lot of different practices as far as how that buy-in is implemented. How do you get alignment on within those teams? That's what I guess I'm asking about.

Bill: The question really is about alignment among various UX teams. They don't report into the same organization. They're in separate ones. We tried a lot of different things like Yahoo. I did the Yahoo design pattern library to help coalesce some of that. Then I've seen other groups, I saw PayPal doing this too, where they were trying to create a pattern library and really it was a pattern police which never works.

I've been in central UED design organizations. I have some experience around this. What I've found, again, I'm going to go back to the same principle that I talked about earlier, is that if that central core UED team that is developing really the core styles, the guidelines, the patterns or whatever approach they're taking, in some sense, it almost doesn't matter what approach they're taking in. It depends on the organization.

If they're not solving the problems for those other groups helping them make them better, they're not going to be successful. What the classic mistake is, a centralized team gets really frustrated because this team's going off this way and that team is going off this way and this team is going off that way. If they actually think of them as customers, those organizations, then they start going, "Well, wait how do they work? What is their actual workflow? Can I make that better?"

If you make one improvement to the way those teams work, guess what, they'll listen to you. They'll beat a door down to you. You can't keep them away. Basically, if you make other people in the organization more successful, you never lack for work. You never lack for people wanting to be on your calendar, wanting to consult with you, wanting to talk with you.

If you are policemen, they will run from you. When you come down the hall, they'll dodge into another room and go away from you. You can't have the police state, the Stasi, the East German police kind of approach to UED. You've got to have that more than help solving problems. You're in that ride and then you get into conversations and you actually have skin in the game.

When you don't have skin in the game, you pitch ideas that don't really make sense. I've seen that over and over again. There was a team that got so excited about the pattern library. They were hiring outside the firm to build the pattern library. They got really excited about doing this pattern library.

They said, "We know we could have a chat in here so designers can chat with each other. We can have..." and they had so many features unlike us. First off, let's do an MVP. If we do a pattern library, how about the pattern detail page and maybe a rough taxonomy. That's it, if we do that, let's just ship that.

Applying the same LEAN start up principles...A cobbler doesn't have shoes for the kids, a design team doesn't apply the same design principles to themselves, is also often what happens. You have to take a real LEAN approach to those centralized teams and meet needs and get your work.

Jared: Where's Julie Martin? Elaine, we're going to go over to Julie next. Before we do that, one of the questions that I had following up with Eric is the politics. PayPal can be a political place, yes?

Bill: No!

Jared: Yes? No? No?

Bill: Shocking.

[laughter]

Jared: Is this a news flash? [laughs] Does it get political around design at PayPal? I bet it does. If so, how do you play into that? Has that changed as you progress through the different...

Bill: It has changed. We've had different actors - that's generally where it comes from. Actually, I have talk on like 18 or 19 anti-patterns that stifle LEAN teams. In those 18 or 19 anti-patterns, if we look up, Google that talk, you'll see me pointing out my real life experience of watching this happen. One of those is the genius designer because you get the person who generally they came from Apple or wanted to go to Apple with something.

[laughter]

Bill: They tried to apply, but work at Apple somewhere else which usually doesn't work. They're going to control the process. It always gets back to this if you could ever get a dose of reality of the customer into them. Problem is, this one person I remember that was in that role -- you know who I'm talking about, Karen -- would never listen to usability feedback. If they go to use usability and it's like, "This sucks." The users totally hated it.

He was convinced he had the right approach and just wouldn't listen. Fortunately, he left the company. If you can't get a dose of reality from the customer end, you're not going to be succeeding. When you get away from that, you fail. I don't know. I'm being simple minded here but it's...

Jared: It's something that you can do through hiring in terms of checking to see if that's going to work. I've been in the same situation, I'm currently working with a team where I'm going to start putting a jar on the table and if another member of the team says, "Well, when we were at Google, we used to do..." I'm going to make him put 20 shares of Google stock in the jar.

[laughter]

Bill: In your jar.

Jared: I'm just tired of that statement. I'm just wondering if the way to deal with that is to just whim them out in the hiring process.

Bill: I think so. When I look at patterns around design organizations, especially if you're in any kind of role of creating products, a big failure happens when you have design leadership who've never worked closely with engineering product. They maybe come from the studio background.

The studio background is fine. There are a lot of great things you bring from it. If you only have the studio background and you don't have the real world of talking to engineers, understanding engineers, what happens is I've seen those design leadership retreat back into their studio. They love to setup their own little studio and go hide in it. They don't connect and I've seen that happen over and over in almost every company I've been at.

You need to hire leadership that knows how to roll up their sleeves, and know how to compromise. Because design is not just art. It's the actual compromise with the real world, and very iterative, and failing fast, learning fast.

Jared: That makes sense. Where is...?

Bill: Julie.

Jared: Remember Julie is second, but where is Allan Ball? Which one? OK, over there. That's where we'll go after Julie, so Julie, your turn.

Bill: Hello Julie.

Julie: Hello. I think my company's process is very similar to how you described your organization when you got there at the design, with very long planning process where design doesn't start until afterwards.

Can you talk a little bit more about how you convinced the business to switch methodologies? Obviously, you can't just flip a switch, and have the business be on board with adopting a new methodology, and changing their process. to adapt more.

Bill: I was a little fortunate, although I've done it in other places, but I was a little fortunate at PayPal to have seen a leadership give me more carte blanche to change things. In other places, I didn't have that, and I also have friends who have been successful, or they didn't have that senior leadership.

What they've almost always done is carve out some sort of sandbox. Some place that they can make a significant impact, but it is not betting the whole company. I know like the folks at Hotwire had done this where they basically wanted to experiment with, "I can't show you where this hotel's at. Otherwise, it violates the whole idea of what we're doing. If I can put it on a map, in a general area, would that drive conversion?"

The sandbox didn't. When they first started, it was horrible. They were losing money, but they had got enough buy-in. They got a certain amount of dollars to invest in the lack of conversion, and then finally, they crossed it, and went way over.

Then it was like, "Oh, OK, great." Then, "How did you guys do that?" That methodology started picking up, and being used in other parts. You always have to have some sort of sandbox.

What you really want to do there too is I've always looked for a business development person, or a product person, somebody in the organization who's got an interesting problem, and hasn't been able to crack the nut, and you go partner with them, and figure out a way that you could try something.

They're generally always excited about doing that, because you're coming and giving them free resources for one. Helping them in any way. Then if you can provide some value, that gives you the right to provide more value, then more value, and then more value.

At Sabre, that's what I did, because even though I had the VP, and development who came in and said, "My charter was make us love usability," that was my charter.

[laughter]

Bill: I took and ran with it, but there, it was like grassroots getting to cross-pollinate teams. Trying to get this team that did crew planning, did the switch over, and evaluate the flat planning product. Teach them the discount, usability, methodologies, and then be more like a renegade sort of thing, which worked.

There, I found a few key product managers who had discovered where the levers in that direction had controlled. Teresa Neil, my co-author of my book, she and I just made them successful. Then before you knew it, we were involved in every conversation.

There was no single product being talked about that we weren't a part of. We were so busy we didn't know what to do with our self. That wasn't my charter. When I came to Yahoo, I used to say, "I heard you are the AJAX of AngelList?"

Well, they meant that to be internal, but then I flipped it to external too. I never stop with whatever the charter is. You get in, then you find out what the problem is to solve. There at Yahoo, we need to have an external evangelism too, bring great talent in, and then also speak to the whole design community like patterns, and stuff like that to help everybody get better. You just start solving a problem, and you find your way around kind of stuff.

Jared: Let's talk for a minute about this external evangelism thing, because I think this is something that in the field, we do scatter shot. How important is that to getting really great talent?

I think a lot of people think that the way you get great talent, and of course when Lou's here tomorrow, we'll talk about this in way more depth, is you write up that job ad, and it's funny, and cute, and you post it up on the wall, and that will get you the best talent.

Bill: Well, I knew when I came into PayPal in 2011, there was nobody in the front engineering community who wanted to go work at PayPal. Most had left. There are still some good people there, but a lot had left.

I knew my job really was to change the story. Humans love stories, and so as we started making those changes, as soon as we started having that Hermes project, I went out and started talking about it. People liked the message, and so before I knew it, I gave like 20 talks that year about the change we are underneath.

Jared: Silicon Valley in particular is so protective about their property, and their processes.

Bill: It helped that David was going out, the president, was making a lot of noise about that PayPal was under a big transformation. I got in trouble with our PR team a few times, but I'd already had...They grabbed me one day, "Hey, you need to tone that down a little bit." That was so trash talk, the previous PayPal.

[laughter]

Bill: It was all perfect.

Jared: You guys were trying to go IPO.

Bill: No, this is way, way before IPO. We were good friends, and I already make good relations with the team, so I could get a little buy. I said, "Look, I have to be honest. I have to go out, and tell how bad we sucked, because any engineer out there in the crowd knows it. It's no secret."

For them to hear an executive of PayPal saying, "We totally effin sucked, and now we're getting better. Here's how we're getting better, here's what we're doing," people love that comeback story. I tell the comeback story, and then before long, you had more people joining me who made the comeback story even more real, and more people joined.

It was a little self-fulfilling process, so I'd never shy away from taking advantage of telling a story and marketing, and those things like that, because people want to be part of something successful.

Jared: Allan. Where's Allan? Here we go.

Allan Ball: Hey, I just wanted to ask about how do you decide when to make broad sweeping changes as opposed to more incremental changes? Once you've made those broad sweeping changes, when do you do it again, or do you?

Bill: Well, it's interesting. I tend to almost always make incremental, and then at some point, you realize, there's a broad change to make. Then you make that change, because you learned enough to make a big change.

I probably would lead with the incremental, and then go to the big. Big is from your learnings. You got to reorganize the whole group. You've learned from talking to people, you've tried some ideas out.

The team that had been building the technology before I got there, the mistake they made was they had hired a lot of people, probably between 50 to 100 people, and they'd been working for about four years on this technology.

I came in, and ended up with seven people in six months replacing everything they had done. They were telling me the whole way through, "You can't do that. There's no way it's possible," and I said, "It's possible, because..."

They said, "You're going to fail." I said, "That's what you don't understand. I know I'm going to fail, but I'm going to fail in small increments. What you've done is you've failed in a large big gamble, and I won't do that."

I fully expect to fail every day, but I'm going to learn from it, and that's why we could do in six months with seven people what they couldn't do in three or four years with almost 100 people.

It's a powerful lesson, because I was listening. I knew what my developers needed, and what we've put out there, everybody wanted. I couldn't stop them from adopting it if I wanted to.

They had adoption team, and a second adoption team to help the first adoption team adopt the technology. It's just classic mistakes of big organizations. I can't make this shit, this stuff up. Sorry.

[laughter]

Bill: I don't want to put an explicit on your podcast.

Jared: Oh no.

[laughter]

Jared: We can have all that shit here. I'm cool with it.

Bill: OK.

[laughter]

Bill: Cool.

[laughter]

Jared: You don't have to go all Dave McClure on me, but we can...

[laughter]

Bill: I could do a [indecipherable 40:38] .

Karen: Looks like...

[crosstalk]

Jared: Where's Nick Cochrane?

Karen: Looks like we're out of time.

Jared: Oh. No, we have a little extra time.

Karen: All right.

Jared: Where's Nick? Nick has a great question after that. Where's Mickey Cancleve? Behind me. Perfect.

Nick Cochrane: Hi Bill.

Bill: Yeah. Hey, how are you doing?

Nick: My question is about the war room.

Karen: That's fine.

Nick: I work at ExxonMobil in IT, and we are trying to experiment with this high performing team concept as well. My question is about this war room. I know it was very successful, but I have a couple of questions about it.

One, did you face any resistance to what you were doing in that war room from other parts of the organization? Two, what happens after the war room? Do you roll into another war room, or is this more of kind of a unique one off project?

Bill: The war room was set aside by our president, so [laughs] it's like, "Good luck arguing with that one." In fact, when we would need a bigger war room, he basically told the facilities that if they didn't give us that most coveted conference room, the nicest one we had, he was going to give the board room up to us.

That's how much support we had, which was pretty cool, and he didn't have to do that, so he got what he needed. We then had a lot of copies. People were taking conference rooms offline, so much facilities was having a massive headache to create all these war rooms.

At some point, it has to get out of war rooms, and just become part of the normal process, and that's a harder thing to do. We actually were pretty successful at that. I would give us probably about a C at this point.

We had gone as high as A, and probably dropped down to C, and we're probably trending back up now, because as companies organize, reorganize as people leave, you've got to remake all those connections. You got to keep it going. I would say on the ground floor, the engineers and designers. product key people work really well together.

There are a few teams that it's probably a little rougher, but most teams do pretty well now. They imbibed this concept. We try to have a little bit more of a LEAN methodology we've put in place.

We had that for a little while, but when I reorganized my front end engineering teams, it became harder, because I know I decentralized that organization, and it became a little harder because they became a general engineering population. That became a little bit more challenging.

We've rebooted it a couple of times, and you'll have to do that in the organization. Just expect that whatever you put in place, it starts working now, it'll stop working in about six months, or a year, and you'll have to reiterate on it which was a big lesson for me.

Nick: The follow up on the war rooms. When you were in the war room, all these folks were in one room, and they've got the work on the wall. If they're leaving the war room, are they now in disparate places in the building, or are they all still stuck together, is the work still up on the wall?

Bill: What we try to do is we try to keep to putting teams in the same area. Where we don't do that, we're less successful. Frankly, it's just human nature. Once you get beyond what Christopher Alexander's called the nuisance distance, the communication drops off rapidly. Where people have to walk to a nuisance distance to talk to each other.

It could be on the next floor down. It could be on the other side of the building, which is why he advocated creating architecture to create communities. That's always a challenge though, because facilities is not as agile, and lean as the rest of the organization although David tried to make it that way. Tried to really do that.

We did break down all the cube walls, and make it open space and stuff, which helped.

Jared: Mickey was next, right?

Mickey: I'm wondering if you can talk a little bit about as you're pushing design thinking, or design methodology out, and especially up into your organization, how you continue to let your pool of talent feel really valued? There's this democratization of design happening in my organization right now, and I find that it makes the folks practicing it as sometimes uncomfortable as the folks learning it.

Nothing makes people more uncomfortable than the second an agency comes in from external, and was brought in by one of the executives you're trying to infuse with that design thinking. Talk a little bit how you keep both sides of the spectrum comfortable.

Bill: That's a tough one, because I've seen a couple of situation where we brought the outside firm in. Then the rhythm that the design engineering teams that were working together all of a sudden changed to where the design team was working with the outside organization and not working with engineering anymore. Then engineering was cut out of the loop.

I've seen that happen. What I've tried to do myself in those situations is intervene, and sit down and have the teams reset on what the problems we're trying to solve, how these different teams can pull together, and solve that problem.

If your leadership doesn't understand that fracturing is going to happen, then it's going to be a problem. On the ground, you've got to have to make a connection with that outside firm yourself, and try to solve the same problems together, which is tough, because they've been usually hired to just do some work, and throw it over the wall.

The other day, stuff has to get built. There are very few situations where you have an outside firm that's building your product. They are usually designing something, so at some point, your design team, engineering product team is going to have to take that and make something real from it.

That's where the real magic is going to happen, and so that's the best place to make sure the collaboration's happening in the most extreme case of it.

Jared: One of the questions that's come to mind is PayPal is one of the oldest companies on the web. Is there a mentality that's underwriting things of where people are just scared that PayPal could go away? That some new business model could come in, and just take over?

Kids on the west coast, they love that disruption word, though I don't think they know what it means, but they use it all the time. Is there this fear that PayPal will be a victim of disruption...?

Bill: Well, I...

Jared: ...and how did that drive, the design process?

Bill: Well, I think that they didn't have enough of that when I got there. In fact, if you look at Stride, it's been pretty successful from a processing perspective, they came about because the founders were trying to do a hack day, and they were trying to use PayPal, and the API sucked.

They said, "Well, we could do a better job than this." That's when they went off and created Stride.

Jared: Well, people moved from PayPal to Stripe...

[crosstalk]

Bill: I know.

Karen: I moved to Stripe.

Jared: Please. I know you got to rub it in.

[laughter]

Bill: You should have look at Braintree by the way. It's what I'm working on.

Jared: We can talk.

Bill: Yes. They didn't have enough of that healthy fear. I think that's definitely in the organization now. A lot of what we did to turn things around was because of the recognition of the Stripes and the Squares, and anybody else who was popping up. The Apple Pays, and whoever else.

The approach we've taken is that we're a fabric to the payment ecosystem so we can support pretty much everybody. As long as we have that mindset, we're actually more successful. Half of the Apple Pay implementations are actually running on our PayPal Braintree platform, so we actually enable that for a lot of merchants.

We've definitely got that healthy fear now, and the fear is really important, but you can't obsess over it. You've got to create real value for your customers. At the end of the day, that's what's going to win. It's not just focusing on them.

In our industry, payments is hard. It's actually really hard in industry, so that does help. You got compliance, and legally, you're in 200 countries. You know this, Karen, in MasterCard too. It's hard. It's a hard problem, so that's what lulled them to sleep I think, to think that they couldn't be disrupted, but anybody can.

Jared: What's the most exciting thing coming up that you can talk about?

Bill: I'm working on Nextgen commerce, which our next generation commerce products. I think what gets me excited is where commerce, and payments is going in the world, and how it can really enable people who don't have good livelihood now to in the future have easy access to money, to get loans, to get ability.

That what's happening in FinTech, we call it with the financial services...

Jared: Financial technology.

Bill: Yeah. With the unbanked, underbanked, and around the world I think is the most exciting thing that's happening, or going to happen. It's going to take a lot of work to get there, but just a little bit of money in the hands of people in countries that don't have it can make a huge difference.

Creating that equal access is, to me, probably the most exciting thing I see coming.

Jared: Well, that's great. I think that I'm excited about what you guys are doing, and where you are going, and the role that design is now playing in this, and so thank you very much.

Bill: Thank you. Appreciate it.

[applause]