Peter Merholz with Jared Spool Podcast Transcript Brian Peter Merholz, interviewed by Jared Spool, recorded June 5th, 2008. Christiansen: [musical interlude] Brian: Welcome. I'm Brian Christiansen, producer of UIE Podcasts. In this week's episode, Jared speaks with Peter Merholz, president of Adaptive Path, the noted experience strategy and design consultancy based in San Francisco. Peter is the co-author of the recently released book, "Subject to Change," which discusses embracing uncertainty and the idea of experience as a strategy. On that same note, Peter Merholz and Andrew Crow will be presenting "Subject to Change: Product Strategy and Planning Tools for Great User Experiences" at our User Interface 13 Conference, which will take place this October 13th through 16th, 2008, in historic Cambridge, Massachusetts. You won't want to miss it. And now, here's Jared. [musical interlude] Jared Spool: Welcome, everyone. I have Peter Merholz on the line. He is the CEO of Adaptive Path. He's going to be speaking at the User Interface 13 Conference with Andrew Crow in October. And we're going to talk to him today about product evolution and how you map that out. Peter, how are you? Peter Merholz: I'm well. One point of clarification: I'm not technically CEO. I am merely a president at Adaptive Path. Going well. Things are going very well. Thank you. Jared: OK. I'm glad I got that wrong, and you could clarify... Peter: [laughs] Jared: There's a technique that you and I were talking about a few minutes ago that I think, could be extremely valuable to teams, in terms of just being able to figure out where they're going with the design of their product. Can you talk about that? Peter: Yeah. This is one of the techniques we'll be teaching at the workshop in October, and it's called the Product Evolution Map. And it's a tool that we came up with to address a need. And the need was one of two needs. We were either having particularly startup companies, new companies, coming to us who, in their first release, wanted everything in it, or we were working with bigger, more-established firms who were having trouble getting a sense of how they should evolve their online presence. In both cases, the need was the same, and that was to articulate a path for this organization, getting from where they are currently to where they need to be or where they want to be. The Product Evolution Map, in some ways, resembles a product road map, a standard tool in product development practice. Where it differs is in texture and mindset. Product road maps tend to be very feature and functionality oriented. You kind of have this long list of features, and you write next to each feature, when you think you could, launch it, based on some measure of feasibility, whether it's an engineering capability, whether it's how long it takes for the design to happen, whether it's a relationship-maybe there's business development and partnerships that are required. And that's a typical way for managing the release of features is: "When we have it ready, we will launch it." And that actually runs contrary to how we believe experience design should be planned. Simply having capability isn't a good enough reason to launch something. Instead, the Product Evolution Map breaks up the product delivery path into three stages. We always use three, for the reason that you always three: three is a good number that, at least in Western cultures, we have grown accustomed to and understand. And essentially, those three stages tend to be a "What can we do in the near-term?" "What can we do in the mid-term?" and "What can we do in the long-term?" And the key difference is that each of those stages is not about features and functionality, but it's about what is the nature of the experience that you want to deliver as an organization. And when you use that as the defining factor, what that means is that you might actually delay the launch of features and functionality- that is that you are capable of launching-because you realize it doesn't make sense with the feature set that you're planning. So, an example of how we've used this is we had a startup client, kind of a Web 2.0 client. I can't say much about the specifics, but it was an organization that had an existing product in the market, and they recognized there was an opportunity to bring it into a much more kind of pure, customer-facing realm. They were looking at companies like Flickr or whatever, in terms of the kind of market opportunity and the kind of customer orientation that they wanted to have. The challenge that they had, though, is, because they'd never released a product to the customer market, their first release they wanted to do everything. They wanted it to be a fully fleshed-out, Web 2.0 app that had all the features that you could imagine, in terms of profiles and social networking and syndication and tagging, like all that stuff. And so, what we worked with them on is to stage their release so that it was achievable. And we broke it up into three stages, each of which has a title. So, the first stage was "Attract," the second stage was "Fulfill," and the third stage was "Extend." And even just those words kind of help you figure out what we were communicating to them in terms of how they should evolve the service. The first thing they needed to do was simply attract customers. This was going to be a new offering, kind of a new space. There's nothing quite like it out there, and so the challenge is simply going to be to get people into the system, comfortable with the system, familiar with the basics of what it was that this company was trying to do, and the focus being to develop their initial user base and familiarize them with the basic services and capabilities. The second stage, fulfilling, is when the service can start touching more areas of the customer's life. So, instead of just simply getting them to use the service, start introducing them to new features and functionality that required a more embedded experience. And then the third, this extend, is probably the most interesting, which is kind of those Web 2.0 capabilities: "How do we get the stuff that we have out into the world, out into the web, people subscribing to it or embedded in other people's sites or Facebook apps, or whatever it is?" But, we needed to make it clear to them that even though they wanted to do that kind of extension right away-everybody wants to be fully embedded from day one-they needed to kind of stick to their knitting and first release a usable product that simply attracted people. Jared: OK. So, the "Attract" was the near-term, the "Fulfill" was the mid- term, and the "Extend" was the long-term? Peter: Exactly. That's exactly right. Jared: And different products would have different of these near, mid, and long-term things. The "Attract, Fulfill, Extend," that was just because of the nature of this particular project. Peter: Exactly. On a different project, one that we did for financial services firm-so this is an established firm, and they had an idea of where they wanted to go, but they were having trouble articulating the best way to get there. And so, what we worked with them was a three-stage road map. In some ways, it was a bit of a cheat. It was kind of a two-stage road map, though the first stage was where they currently were. [laughs] So, there were still three stages. And those three stages were kind of your current state, which was this kind of band-aid website that had grown organically over time, and it was frustrating to everybody. The second state was what we called the "cohesive experience," right? Which was the first thing you need to do is become simply kind of competitive in the marketplace. Offer the basic features and functionality that people would expect from a financial services firm and do so really well. Then the third stage was this idea of a relationship platform. This is a financial services firm where the relationships are largely mediated through an adviser, through a human. And there was some talk about bringing that relationship with the adviser into this second stage and using the website to better grease the wheels of the relationship. What we realized is that that would be trying to do too much at once, that they needed to simply have, in that second stage, a website that was credible and basically competitive, and to wait until the third stage, where they'd create a relationship platform where a customer and an adviser can really use the web. You can imagine it almost in ways like a wiki or a base camp, right, where there's the ability to send documents back and forth and comment about, maybe, opportunities for investment or new products, maybe life insurance products, or whatever it is. You can imagine a web space that can foster that communication, or enhance communications that are also happening on the phone or in-person- maybe document delivery and those types of things. So, it's just this three-stage model is one that we've found helps organizations think clearly about the opportunities that they have ahead of them and how to pursue them in such a way that, again, they're not putting up the client-adviser wiki tomorrow just because they could because wikis are easy, but they're waiting to consider, "In the release of the experience, for the whole experience that we're trying to deliver, when is it appropriate to bring that kind of functionality?" So, that's how we found it to be useful for our audience. Jared: So, in terms of coming up with these three stages, what sort of inputs did you use to get to that point? Peter: So, the inputs that we used to get to these three stages; largely they're driven by stakeholder interviews, right? It's largely driven by understanding the business and understanding the needs that business has in terms of deliver value. So, that's one key thing. So, it's a lot of conversations, a lot of discussions, maybe even some white boarding. The other component, though, these Product Evolution Maps-and when we teach the workshop, we go into a fair amount of detail-what's crucial is that you marry value to the business at each stage with value to the customer at each stage. So, if we take these financial services example, the value to the business of the cohesive experience was the just very basic kind of increase in deepening your relationship with the financial services firm, a little bit of up-sell. But, mostly it was for the business to prove to the customers that they are serious about the web as a platform for delivering good service. And for the customers, on the other side, what they're getting is essentially ease of use, right? "Compared to the existing site, this new site just works. It has much of the same functionality, but I now understand how to use it." As you move forward, into that kind of relationship platform, the value to the business was really kind of deepening the relationships that clients had with this organization by providing those tools that enabled and enhanced the relationship that they were having for the adviser. For the customers, the value was really demonstrating the value of the relationship that the customer has with this organization, and, through the use of the tools, frankly, being able to do better investing, smarter investing, better planning, and longer-term planning. And so, at each stage, it's important that you identify the stakeholders and what value they'll be deriving from it. And so you need to talk to people in the business and understand the value that they have, or what it is that they value, and then talking to the audience and identify what it is that they're interested in or desiring. So, if we think about that other kind of Web 2.0 startup, the one with the "Attract, Fulfill, and Extend," the reason we started with "Attract," a very basic, just you have to simply announce yourself and start building the user bases: we presented customers with the full potential of the experience, with the tagging and the sharing and the social networking and all that kind of stuff, and they were overwhelmed because they didn't know enough about this business. This was going to be a new company, a new service. They didn't know enough about these people, essentially, and the business behind it to trust really embedding themselves with it. Jared: Right. Peter: And from that customer research, we were able to say, "OK. First, you need to build a basic sense of trust with your audience, through the basics of the service and delivering a sensible service that just works. As you gain that trust, you can then go deeper in the relationship." So the customer research definitely helped us drive that understanding of how to stage the release of the experiences. Jared: Now, what is the physical deliverable that comes out of this? Peter: The physical deliverable that comes out of this, typically, it boiled down to one page. There can be ancillary material that helps explain it in more detail, but it's essentially boiled down to one page. And it's a chart with three columns for each stage, and then some number of rows for things like value to the business, value to the customer, and then kind of enabling technologies. We don't want to ignore the fact that technologies are important. And so we've just been working on a consumer electronics project. And consumer electronics, it's interesting for us. It's a departure from the web work that we're known for. And consumer electronics, feasibility becomes a very interesting challenge, because some things are not physically possible to do, at least not yet. And so we had to know when-this is a consumer electronics device where we're considering things like touch screen or pen input, like a stylus input, and that is going to be a limiting factor. However much we as designers would like to ignore technology and just design the perfect thing and assume the technology will be there to serve it, you have to take in the technological limitations as well. And so, because of that, we recognized we could have touch screen with your fingers sooner than you could have what we called "any-pen" input, without needing a special stylus, because of the nature of the technologies and capacitive versus resistive screens. I won't get into those details. So, you marry the value to the customer, the value to the business, the technological capabilities, at each of these stages, to get a sense of what is the credible and complete experience that you can deliver at each stage that map over those. Even though it's boiled down to one page, it's the kind of thing that, when you see the final product, you tend to be a little bit unimpressed, unless you're an executive, because executives love things boiled down to one page. Jared: Right. Peter: The people working on the project, kind of in the weeds, are wondering where all the thinking is. Well, a lot of thinking goes up to figuring out how to distill that, because there's some jockeying back and forth. The values to the business and the customer can be fiddled with based on the technological capabilities. But, the point is that it all bubbles up into telling a complete experience story at that stage in the product so it doesn't feel like there's something missing. So, if you think about when the iPod was released, the iPod was released and "all you could do" is rip CDs and put them on it. But, it turned out that was a complete enough experience. When you used it before the iTunes Music Store, it didn't feel like you were missing something, because the experience was complete on its own. When they released the iTunes Music Store, it was simply kind of a new experience that they were able to provide, an evolution of that experience, but not one where, again, you felt like you had somehow been hamstrung earlier on: "If only I could download these songs directly to iTunes immediately..." They had created a whole experience. They had been able to carve that out so that it felt robust enough and felt complete. It didn't feel wanting. Jared: Right. Peter: So yeah. I mean, it's mapping the value to the user, the value to the business, and kind of the enabling technologies, at each of these stages, helping deliver success. Jared: Now, I want to go back to this idea about: you're focusing here on the level of experience, and you're not talking about the specific technologies or features that go into that experience when you're talking about that. And that's really important, right? Peter: It is. It is. Because you never want to launch something where the experience feels unfinished, where there's an obvious gap in what's being made available, but you're using it because these are the features that were simply available at the time, and here you go. You want it to feel whole every step of the way. And so, if we go back to that "Attract, Fulfill, Extend" services, where, again, you can even think of it a little bit like Flickr, right? Flickr had, likely, a similar evolution, where they needed to attract people into the system to upload photos and start sharing them. The "Fulfill" is, as you start kind of deepening your relationship and maybe getting into things like groups, and getting into new ways of organizing the photos in things like the Organizer and stuff. And then "Extend" is things like maps and the geo- tagging, and also things like printing and all these new ways for the photos to be used out in the world. And at each stage, it's never felt like Flickr has been incomplete. Those of us who were using it from the beginning got a lot of value from that set of stuff. But, as it's evolved, they've been able to kind of evolve in such a way that you have this kind of suite of capabilities that feel coherent and that map to kind of the evolution of that Flickr experience. Jared: And so, now you've gone through this process with clients. What sort of results have you seen from it? Peter: The primary results that we've seen is helping clients actually launch something, I think, is probably the single most important result of this process. Because one of the things that prevents launching a product is a desire to put too much in it. It's a desire to cram every last thing in it. And so I help clients to be able to tell a story about each stage of the release. They can launch with confidence a service, a website, that might not have everything that, internally, they know they want to bring to the world, but where it's complete and they can feel good about putting that out into the world because people will use it and have a whole experience, have a complete experience. So I think, the value is helping remove some of the kind of mental clutter of product development and all these ideas, help you set that aside, push it off until later, and focus on what is the important experience to deliver in the moment, and frankly, just get something done. Get it out there. Get it into the market, getting a complete experience out into the market. And that is probably the single biggest benefit: just kind of that clarity of purpose and focus that this process brings. Jared: It's really interesting, because we can look back at things like the iPod or Flickr or other services that, when you look back, it really feels like they had a plan. Every subsequent, major, new addition really dovetailed in nicely. And then we can look back at other products where it really feels like they just found an opportunity and they just added it, and they didn't really think about how they were going to dovetail the users' experience so that the new thing and the old thing just worked together. Either they go back and they re-jigger the old thing in such a dramatic way that users aren't familiar with it anymore and they got all upset because it's all changed on them, or the new thing just sort of hangs off the side in a way that it feels like two separate products-it doesn't feel like these people all work in the same building. Peter: Exactly. And that's pretty common. We've ended up doing a lot of work in financial services. I know that a lot of people in financial services attend your events. And this is kind of par for the course in financial services because, as new products or offerings or whatever are made available, they tend to get bolted on to this thing. And so that example that I was giving about the financial services firm, their experience up until the point we were working with them was very much this thing that you're talking about. They started off focusing on investing. But, then, as regulations kind of relaxed, they recognized there were opportunities to go into banking, or opportunities to go into insurance. And it became this kind of muddle. There wasn't coherence to how they were trying to relate this to customers as an experience. And so the advantage that they had in working with us, they could kind of at least hit pause, if not the reset button, take stock of all that they had, step back, and then start figuring out how do these things actually work together, how can they complement and improve one another, and then-also, thinking about their future-how are we going to successfully continue to deepen our relationship with our customers in the future, and let's start thinking about that. Let's have this on a plan, so that when we get to that point, there's a space for it, and it can dovetail, as opposed to we add a "click to chat" button on every page, and that's how you're going to have a better relationship with your adviser or something. Right? I think, one of the things that are interesting... I don't know if people recognize it when it comes to the iPod and the iTunes Music Store, but some research that I did for the book that Adaptive Path wrote-and we use the iPod as an example, of course, because you can't talk about experience design without using the iPod as an example, of course. Jared: You get fined $20 if you try. Peter: [laughs] If you don't. I actually think we should get fined $20 every time we do, but that's a separate story. Jared: [laughs] A little box: "iPod reference. OK. Put your $10 in." Peter: Exactly. It's like the swear jar. Jared: [laughs] Peter: Steve was talking to record labels, I believe, before the iPod launched. He knew that that's what he wanted to do. But, he also recognized that it was going to take a long time to get that lined up, and he didn't want to jeopardize his go-to-market opportunity. He needed to get something out there and to establish Apple as a player-particularly because they kind of prototyped it in the market a little bit. I mean, a lot of people forget, when that thing launched, one, it wasn't given a lot of promise. People didn't think it was going to go very far. And it was Mac-only. So, it was kind of this very niche thing at first. But, he was starting the conversations, or had been having conversations with record labels, even before the iPod launched. That kind of planning and foresight is clearly crucial, and understanding where you're going to be taking this. I guess that's something else that is worth saying about this Evolution Map. It can be often hard to know what you should launch next, if you don't have a sense of what you're going to launch after that, and after that again, because a single point isn't indicative of direction. Two points do make a line, but three points kind of provide you trajectory. And by having those three points and a trajectory, by understanding where you're going to be in that third stage of evolution, that helps you know what to do in your first stage of evolution that puts you on the trajectory of getting there. And I think, that's really crucial. I think, too often, what happens is you think about the next release, and you get it done, and, instead of having a trajectory, you're like a frog on a lily pond that's just kind of hopping from lily pad to lily pad, in a maybe not random order, but not a particularly planned order, and not with any goal in mind. Jared: Yeah. I mean, that makes perfect sense to me. The other thing that's really interesting about this is that we've been talking a lot to our clients about this idea of having a five-year vision: "What's the experience of using your design going to be like five years from now?" And so that's the long-term part of your piece. But what's interesting here is that you're extending that and saying, "OK. You've got this long-term vision. But, what are the intermediate steps that are going to get you there? What is the road map that gets you down to that long-term vision?" And I think, that's a piece that we haven't been so good at talking about. I think, this technique that you have is really going to help fix that gap in the way that we have been talking about this stuff. Peter: And that is explicit. It's not just us at Adaptive Path. I think, lot of folks in this kind of design/consulting world are seeing this. And it sounds like you are seeing it in some ways too. We do get asked to do these three to five year visioning projects. But, they are often as part of a, "We need to release something in the next 12 months, and we need to figure out who we are five years from now. Help us do both." The challenge that we face is that the solution for the next 12 months and the solution for four or five years out is often very different, right. It can be hard to design both at once. So, this technique provided a framework so that we could think rigorously and have a plan that gets us from A to B to C and manage these too. It's one of those things where if you're doing the release in nine months and the release in five years, you're potentially holding two conflicting opinions in your mind. It's one of those things that cause dissidence. By being able to suggest a set of staged releases proven by experience, that helps you recognize how you're going to get from here to there. Jared: Cool. Now this is just one technique that you're going to talk about in your full day workshop at the User Interface 13 Conference. That workshop, in case you don't remember is named Product Strategy and Planning Tools for Great User Experiences. You'll be co-presenting it with Andrew Crow. Why don't you talk about some of the other things that folks are going to get out of that session? Peter: Sure. So, there are a bunch of things that we are going to be teaching. We teach essentially three or four, depending on timing and depending on the mood of the room and depending on exactly what I am interested in that day, but three or four tools for product strategy. One is this Product Evolution Map. We actually end the day with a Product Evolution Map because it takes a longer time to get into it. It takes a lot of time to develop it and it builds on itself that we have done before. So, an earlier tool that we teach is we usually do Design the Box. But, it's essentially design an artifact. And it's a tool that you use very early on in product strategy sessions to get out of people's heads their ideas that they have for the final product as soon as possible. Instead of just having people talk about it and instead of just having people create PowerPoints with bulleted lists on them, which allows everybody to take something different away, we advocate that you create an artifact, something that feels tangible and real because that is something that everybody can understand immediately and react to viscerally. You want that kind of visceral reaction early on. So, we'll talk about techniques for how to create those types of artifacts. The role there for the designer, for the user experience person is actually often more as a facilitator of a multidisciplinary team trying to get all these ideas out of there. So, it is not about design really. It's about using a design technique to get at stuff that's underlying, some of the underlying issues that you'll be facing. Another technique that we teach is called the elevator pitch. The elevator pitch is set up like a Mad Libs for a value proposition. We found it is very helpful for focusing. Again, it forces a team to focus on what it is they are going to deliver. Too often teams want to do everything for everybody. The structure of the elevator pitch is that it forces you to in some ways position yourself, so set yourself apart from others and also do it in such a way that only you and only your organization could deliver on the promise of this phrase. So an example of the elevator pitch that we use in the talk -let's say we were doing one for JetBlue Airlines. So, the pitch goes, "For people who value comfort, economy and authenticity JetBlue is a low-fare commercial airline that gets travelers where they are going while treating them with friendliness and respect." "Unlike other discount airlines, JetBlue focuses all its efforts on the things that provide real value to travelers like a friendly attitude, on-time arrival and cool services." So the elevator pitch part here is that-a different elevator pitch for a different company would have, "for a different audience" - so you have "for an audience". And then you have, "The company is" - and then you define the company. "Unlike" is important because part of the point here is to set yourself apart from competitors. And then the final statement, "This Company delivers on the final value proposition." What's interesting about this one is it's a pretty good elevator pitch. Actually, the question here is could you swap out Southwest Airlines for JetBlue and would it work just as well? You could argue that it could with maybe minus the cool services, right - the TV in the back of the seats and stuff like that. But, the whole point is again to get everybody to focus on explicitly what it is they are about and what it is they are not about, which can be hard because everybody wants to be everything to all people when it comes to delivering product, especially online product, where it is so easy to just keep adding features. Jared: Super. Well, I mean, that sounds like a great day. I know that people who have gone through this seminar before really thought this was just, they just walked out of it with a set of tools that they felt they were going to be able to use right away. So, I think, that that's really the promise of the session. It's going to be a great day. I think, people are going to really enjoy it. Peter: I hope so. I look forward to it. We have taught this material all over the world now. Its road tested and has proven itself valuable. It's one of those things where it's not typical for designers to be thinking about these types of product strategy elements. They usually brought it in after the strategy has been set. But, what we found is by giving designers the tools to speak credibly around issues of product strategy, one, it gets them potentially invited earlier into the process. So, they are not just simply being handed requirements. And, by helping define the strategy that in turn leads to better design work. Jared: Yeah, and it also gets some of those questions answered that often get handed in assignments. They don't really have their head into the thinking. In many cases questions haven't been asked of anybody. So, then they get into the nitty-gritty details. And then they can't make the design decisions necessary because they don't understand this sort of long-term perspective or the bigger goals that are part of it. When you have all that in mind while you are creating, just how you label a field on a form can take a radically different approach because you understand what makes you different and how you are going to approach it and the tone you should use and the color scheme. All of that emerges out of this strategic thinking. Peter: Exactly. One of my personal missions is to try to get people working in the user experience field to, even if they are not interested in being strategists - that's cool. But, you've got to understand the context in which your user experience work is taking place in order to do the best design work that you can. Jared: Absolutely. Absolutely. Well Peter, thank you very much. This has been really great. I look forward to seeing you in October at the conference. Peter: Thank you Jared. I've enjoyed it and I look forward to it as well. Jared: Super. We've been talking to Peter Merholz. He is not the CEO of Adaptive Path but instead is the President. He is going to be speaking with Andrew Crow at the User Interface 13 Conference talking about product strategy and planning tools for great user experiences. He also co-wrote, with his other Adaptive Path folks, the recent book Subject to Change, which I highly recommend you take a look at. It's been a great conversation and we'll see you next time. Take care. [music] Jared: Don't forget, if you'd like to hear more from Peter Merholz, be sure to join us for our User Interface Conference this October 2008 in Cambridge, Massachusetts. Learn more at uiconf.com. That's u-i-c-o-n-f.com. That's all for this week. Thanks for listening. Goodbye. [music]