07 / Resisting Experience Rot

Read our blog post

---

About Jared

Jared M. Spool is a Maker of Awesomeness at Center Centre/UIE. Center Centre is the school he started with Leslie Jensen-Inman to create industry-ready User Experience Designers. UIE is Center Centre’s professional development arm, dedicated to understanding what it takes for organizations to produce competitively great products and services. In the 39 years he’s been in the tech field, he’s worked with hundreds of organizations, written two books, published hundreds of articles and podcasts, and tours the world speaking to audiences everywhere. When he can, he does his laundry in Andover, Massachusetts.

lti

---

Transcript

Joe: [00:00:29] All right so on today’s episode, we have Jared Spool, and I know a lot of our audience is probably familiar with Jared, we are. We know your work very well. We follow it. But for those who are not, can you please introduce yourself, talk about where you work, what you do, what’s your role overall in the world?

Jared: [00:00:48] Well I’m an internet sensation and teen heartthrob. I basically research what companies need to do to deliver better products and services and I help those companies and the designers within them become better at delivering products and services.

Joe: [00:01:14] Very cool. So you know, we’ve talked to you a lot recently and you’ve written and spoken on many many topics but one that’s kind of near and dear to our hearts lately with the work we do with our clients and all the conversations we hear about and have is this concept of experience rot. Can you define what that is?

Jared: [00:01:32] Sure. It has to do with what happens when you indiscriminately add features, right. There is this notion that a product with more features is better than a product with less features and that’s sort of reinforced by the product management behavior of sort of defining roadmaps in terms of features. So everything in the organization is sort of rewarded by features. And then the other sort of thing that happens is, you do some sort of competitive analysis and almost always that’s, “well what features do they have that we don’t have? And so now, okay, now we have a bigger list of features.”.

Jared: [00:02:14] So we start adding all these features and we add all these features, and over time, at first it’s a good thing, right. You know, we’re making the product fuller, we’re making it more robust where it can do more things, and people are like, “yeah, we should buy the thing that does more things.” But over time, you sort of hit this point where every new feature you’re adding starts to make the product more complex. And not just complex from a user experience perspective, well from a user interface perspective, of “well, there are more menu options and there are more settings in the program,” but all those things also increase complexity internally because every new feature is a new piece of code that has to work with the old pieces of code.

Jared: [00:03:03] And you get to this point where the design is you’re adding features that someone has put a big bag of money on the table and said, “you know if you build this one feature that I know you know only we need and nobody else needs, we will give you this big bag of money.” And it’s very tempting to say, “well yeah, sure, and we’ll just put an option in the settings that lets people turn that feature around or turn it off and most people have it off and that’s fine.” But what’s now happened is we’ve created this massive piece of complexity. And if I just want to add a new feature, I have to make sure it doesn’t break all the other features, and if the other features are controlled by settings, I then have to try all the different settings to get those features to turn on and then to turn off.

Jared: [00:03:56] And I was with a team and they had just hired a designer, this was a few years back, and they had never had a mobile version of their app, and they hired a designer and he was great. And he did this brilliant design for this mobile app. And the developers coded it up really fast because they were really motivated by it. They wanted to get this thing out. So they sat down, and in less than a week they had this thing running. And everybody was really excited. And then it got turned over to their QA team, and the QA team did with the QA team does, and they started turning on options. And it turned out there were 14 options in the overall ecosystem that affected this mobile app. And every time they turned one of those on, the design broke, because the designer, who was new to the company, didn’t know about those 14 options. Some of them were legacy for a long time and there was only one or two customers who used them, but the app would break for those one or two customers and their users. And when you we did the math, it actually comes out to 14 factorial. And 14 factorial means there were eighty-seven million combinations that QA had to test, right. So not only do we have this complexity of having really hard navigation and really hard settings and all this stuff, but now we have code complexity. And code gets so complex that people don’t want to touch it because they’re afraid of breaking it. And now you’ve lost your competitive advantage. All the competitive advantage you’ve had from adding all these features is now negated by the fact that all these features have made the product really complex and you can’t add code easily and your competitors can add things because they don’t have this. That’s experience rot, it’s when features increase, complexity increases, and the experience goes down.

Sean: [00:06:06] That’s great. In our world, we refer to technical debt. Experience rot’s kind of like experience debt, like you create these things you’re going to have to pay for in the future and they add up.

Jared: [00:06:19] Yeah.

Sean: [00:06:20] I like how you use the factorial as a mathematic structure. That’s exactly how they add up, right.

Jared: [00:06:25] Yeah, yeah. I mean they don’t add up, they increase exponentially. And that’s the problem. You walk into this thing, and the problem with exponential growth is it doesn’t seem like a lot at the beginning but suddenly it’s overwhelming. And if you’re not prepared for that, if you’re not watching for that, you wake up one morning and you’ve just got crazy and you don’t know how to control it anymore.

Sean: [00:07:03] Hahahaha, you’ve got crazy, I like that. So I have a question for you along those lines. So one of the big problems we often run into in our world is, there’s always that executive, let’s just call him the executive, who is super competent, right, and wields some sort of power in an organization. It can happen in clients, it can happen within our own company, and they always seem to know exactly what the user wants. So you try to argue, “well, let’s go get some data on that.” But it’s always a challenging personality. I’m just curious, how do you handle people like that when that when that occurs?

Jared: [00:07:42] Yeah. So the secret of this is in the pre-work, right. In pre-wiring the data. In my experience, if you get to the point where someone doesn’t have the data they need but they believe they have the data they need, it’s really hard to demonstrate to them that they actually don’t have the data they need. You’re better off showing them upfront what it is. So identifying who those potential folks could be who will at some point emerge as being the self-proclaimed expert on the user, and start by either showing them that they don’t know as much as they think they do, or in fact, proving that they are in fact a self-proclaimed expert. So that means building the research in earlier than when they come back and say, “well this is what the user needs.” And so this means structuring the project work so that the first thing you do is research. And I’ve seen this done a whole bunch of different ways and probably the most successful is to actually break the project work into phases and have a concrete discovery phase where everything is treated like a hypothesis.

Joe: [00:08:58] Yes, awesome.

Jared: [00:08:58] And it’s like, “well everything we believe about the user in this problem we’re going to go out and really explore the problem and focus on the problem, not the solution, but the problem.” If we’re thinking of solutions, we are only thinking of solutions as ways to generate our knowledge of the problem. So it’s like, “well, we think people need to have a way to export data. Well, let’s go look at all the places where they export data and figure out what they do with it and figure out what triggers that so that we can make sure that we’ve got the bases covered for this export data feature that we actually believe people want because every so often someone asks for it.” And you know, maybe someone’s come in and put a big bag of money on the table and said, you know, “if we had a way to export our data we’d be great.”.

[00:09:43] But without knowing how to export the data or what export the data for, the odds of us doing a good job are really bad. So we use that as leverage to do the research and say, “we really need to understand the problem that triggers the need for exporting data. Because it turns out, maybe the reason they’re exporting data is because they don’t realize we have that functionality in our product already, they’re thinking they have to move it into another product, when in fact we already do what they’re going to do in Excel, for example. Or maybe they’re doing something in Excel that our products should do, or maybe they’re exporting it into another app and we shouldn’t use an intermediate data file format that requires the saving of a file and then the loading of a file, we should just connect to their database in the other app and directly share data and let things move back and forth so that if they make a change in the other app, it changes in our system too,” right.

Jared: [00:10:43] So there are all these different things that, maybe exporting data isn’t the right solution, but one of the problems is that customers in general, humans in general, when we ask something of somebody else we tend to ask in terms of solutions, not problems. We don’t say, “hey I really need to be able to do X is there a way I can do X,” except when we say, “X is the solution I need.” Right. So we don’t talk in terms of the problem, we don’t talk in the sense of, “I somehow have to get this information to all my customers. How do I get this information our customers? Well I’m going to bring it into Excel, put it there, then I’m going to create a template in Word, and then I’m going to do a mail merge in Word, and then I’m going to import that mail merge in Word into email, and then I’m gonna send it to my customers.” Well that’s a nice solution, but that’s not the best solution for your your problem probably. So what we want to do is really start the project by identifying the problems and then making sure that all those potential people who are going to be self-proclaimed experts down the road are getting all that information. We are pre-wiring them with, “hey guess what we learned about the problem, this is the problem customers have, and this is the problem customers have, and we’re exploring this solution and this solution and this solution,” and that point, if they have an idea, it’s within the framework of the research you’ve already done or it’s out of their framework, but you can say, “well hey we should extend our research to figure out if this would actually solve the problem, let’s do that before we invest a lot in it and then suddenly realize it doesn’t solve the problem.”

Sean: [00:12:29] Got it.

Jared: [00:12:29] I don’t know if that helps you with your client.

Sean: [00:12:30] No, that helps, that helps. One of the quotes that I wrote down in my notes when you spoke at ITX UX was, “great designers don’t fall in love with their solutions, great designers fall in love with the problems that they solve.”

Jared: [00:12:44] Exactly. Exactly. You actually said it better than I think I said it. The reality is that we are enamored by solutions because solutions feel like forward movement. If you’re just talking about the problem, people get frustrated, “we’re always just talking about the problem, we need to move on, we need to get to a solution,” right. And we resist this desire to spend more time really understanding the problem. But that always, always pays off. And if we can start to see solutions as just a better way to understand the problem. You know, “I proposed the solution that we have a one click file export, but then I want to go back and watch people use it. And what I may find out is it really didn’t make things much easier. OK. And it created these other problems, like they don’t know where the file got exported to, you know it’s just export and it says, OK, you’re done. It’s like, where did it put it?” So we have to understand. And this is why processes like Lean UX and design sprints and all these sort of up-front problem understanding techniques have really come into fashion in the last couple of years because we’ve gotten really good at once we understand the problem knowing what to do. But we find out that we still fail at delivering great results, not because we didn’t build the thing right, but because we weren’t building the right thing.

Joe: [00:14:35] That really hits home for us a lot. You know I’m thinking about what you’ve been talking about with companies being so tempted to be in a race to add more features and as many features as their competitors or add the features that clients will give them money for. So is this a culture problem for companies, or how can they be comfortable with saying no more? To keep a simple product.

Jared: [00:14:59] Well, I mean it is a culture problem in that the best definition I ever heard of culture is, it’s the things we keep saying we do until we actually do them. And so it’s a culture problem in that we seem to think it’s acceptable to take on work that we should have said no to that we didn’t understand. And so you have to you have to establish a principle and then you have to follow the principle that says, “we’re only going to commit to a solution when we feel like we actually understand that the solution will make life better for somebody, and here’s how we’re gonna tell that.” And as with any principle you then have to iterate over it to understand, “well what does know that the solution is going to make things better? How do we tell that? What are our techniques for doing that? What are the rules we use?”.

Jared: [00:15:58] You know, it’s sort of like how laws work in that do you have a law that says, “every person who is arrested must be read their rights,” and then you spend 40 years defining every word in that sentence as to, “what does it mean to have been read their rights? What do rights mean? You know, who are the people we’re talking about? Are there some people in some situations where that doesn’t apply?” And you sort of really hone in on when does the principle apply and when does the principle not apply. You know, if you have real principles, you’re doing that all the time. Otherwise what you have is just lip service of things you put on the wall. So if you’re going to have a principle that says, “we’re not to commit to a solution until we know for sure that that solution is going to make the users’ world better.” Then we have to start taking that apart and understanding how do we know that, what do we mean by solution, what do we mean by better, what do we mean by users? And really sort of nail that down. When do we apply this principle and when do we not apply this approach. And it’s a shift, right. Because when companies are very young or organizations are very young or teams are very young, they’re sort of in this anything-for-a-buck stage where it’s like, “hey someone’s gonna pay us for this, we should just do it, right, they obviously find value in it, they’re offering to pay us, let’s just make it happen.”.

Jared: [00:17:38] And in the early stages, that’s what you have to do to figure out what you are and who you are. But at some point, you’re smarter than the people who are asking you, and you’re like, “yeah you really don’t want me to do that.” We don’t go into our car mechanic and say… well, I mean, some people actually do, right. I’ve sat in a car mechanic’s office waiting for my car to be fixed listening to the conversations, and people come in and they say, “I really want this tire on my car.” And the mechanic who’s an expert in tires, it’s a tire shop that I go to, will say, “actually that’s not the right tire for your car.” “No it’s a good price. It’s really good…” And the person came in with a solution and it’s like yeah this is not going to end well, right. This is the wrong tire for your car. You’re gonna spend more money and potentially put somebody’s life at risk, you know. And a really good mechanic would say, “yeah I can’t put that tire on your car.” They may lose the customer over it, but at the end of the day they’re not going to do something that’s gonna put the customer at risk or give them a bad deal. Somebody else might and they know full well that they could walk into a shop down the street and that person will be just as happy to put whatever tire on the car that the customer asked for, but I go to the one where they say no. And then I walk in and I say, “hey, I don’t know what’s wrong with my car. Help me figure it out.” And they say, “actually there’s not a whole lot wrong with your car. It’s just this little rattling thing and we put a tie clip on it because it’s a 10 year old car and it doesn’t rattle anymore.” I’m like, “excellent, thanks.”

Joe: [00:19:15] Yeah, it builds trust and reputation.

Jared: [00:19:17] Right.

Joe: [00:19:18] Yeah. So I’ve kind of heard one way to avoid experience rot is collect a lot of feedback, have a lot of ideas, a lot of problems to solve in your road map so you have to be more selective. Do you think that’s a true statement or an accurate way to look at it as well?

Jared: [00:19:35] Yeah, so a big way to feed to to fix experience rot is to shift from features to solving problems, right. Because every feature theoretically solves a problem. If you don’t know what problem it’s solving, A, why are you building it? B, how will you build it well? So you need to understand what problem it’s solving. I mean people want to export data. OK. No one wakes up in the morning and says, “finally, it’s the day I’ve been waiting my entire life, I’m going to export data,” right. That just doesn’t happen. So what we want is to understand, why do they want to export data? Right. Of course, they should be able get data out of the app, there is no doubt about it. But what are they going to do with it when they get it out of the app? Is it just a backup? Because maybe we shouldn’t call it export data. Maybe we should call it backup data. Is it something that’s getting used in another app because that app has features we don’t have or has features we have but nobody knows about?

Jared: [00:20:43] So we need to understand what the actual root cause problem that’s being solved is. And so if we restate export data as “port this into the invoicing software so people can invoice against it.” That helps us really quite a lot. But that’s still sort of a solution, let’s state it in the problem, which is customers need to invoice when the project’s done. OK. So that’s an interesting problem, and then we can extend it and say, “well maybe the real problem is that this is billable work and we weren’t treating it as billable work. So we need to start treating the work that people do in our app as billable because people are trying to invoice against it and other things like that.” And so now that’s really interesting because maybe that changes the whole framing of how we present things in the app like which moments are billable and which ones aren’t, can we give them control over what is billable and what isn’t, what gets what gets put into there, are there things like taxes that need to be applied, is there some sort of service charge, are there add on charges? Right. And so now we can explore the problem better and we’ve moved away from exporting data which inevitably will be imported into a billing system to something much bigger and richer for the customer. And maybe they don’t need to go into the billing system at all, maybe we just need to flag that an invoice has been sent, tell the billing software that’s been done, and give them a copy of it. And as far as they’re concerned, everything is happy with the bookkeeping system and they never had to fire it up. So it’s understanding the problem being solved as we put it on the roadmap that allows us to have this real detailed sense as to, well what does it really mean to produce an outcome that really delights customers and isn’t just reactive: “I need a way to export the data.”

Joe: [00:23:04] Yeah, one thing that’s cool about the problem-based roadmap rather than the feature-based one is this is something, you know, for listeners, you can go back today, right now, look at your road map and figure out, “is this problem-based or feature-based?” And start changing that essentially right away.

Jared: [00:23:18] Yeah, yeah. And the big thing that you’ll find is that half the things on there, or some percentage of the things on there, you actually are having trouble figuring out what problem is solved. Somebody asked for it and you didn’t really inquire, you just said, “oh that’s a good idea,” and you put it on the thing and then you walked away from it and now you’re coming back to it and you’re like, “I’m suddenly realizing I actually have no idea why the customer wants this.” Or maybe you’ve heard it from four different customers and they all ask for exporting data and you’re assuming they’re asking for the same thing. But if you went and talked to each of those four customers you’d find out that they’re actually trying to solve completely different problems with it and really need completely different solutions.

Sean: [00:24:02] That’s great. All right so I’m going to step back a little bit back to your mechanic story and your answer to Joe’s question about saying no. I’m going to try to sum it up in a shorter sentence. So what you’re saying around feature decisions is the more data that you have and the better you are communicating it, the easier it is to say no. So you always have to go back to that research question and the better you are at really understanding the problems, the easier it is to say, “no, this is what we’re gonna do and this is why.”

Jared: [00:24:35] Yeah. And I think on top of that you need a basic principle, which is, “we need to protect ourselves from future experience rot,” which is basically saying, “we need to make sure that we don’t exponentially increase the complexity of what we’re building.”.

Sean: [00:24:54] Right. And to pull on a couple of other things that you said that we definitely espouse here in our work and that is that you have to have a vision for your product that is very explicit about how you’re solving problems for the humans that are using your products. Very explicit. And the better you know what those problems are, the better you can come up with the solutions to solve those problems. And the more robust your vision is, the easier it is to get your team aligned around solving those problems and that vision and the easier it is to build better products because you’re all aligned, committed, and confident that you’re going to get there.

Jared: [00:25:34] Right. Let’s look at the example of an airline app. So this is an app, produced by an airline for their travelers to book flights, to get their boarding pass, to find out where the restaurants are in the airport, to track their baggage, and they’re always coming up with new features and they’re adding it in. So you know, now when I check my bag, it’s added to my itinerary record. Suddenly I get a notification that says, “your bag has been put on the plane. Your bag has been taken off the plane. Your bag is in a city that you’re in.” And so that’s all great and that’s useful, that’s that’s a really useful feature. And you keep adding these features. And it’s like, “oh, well we should add features about, you know, working with our partner airlines so that when you travel on one of the other airlines in the network, well, you can do it through our app instead of their app, but their data is a little different than our data, so we have to change the way we present the data.” So you’ve got all this sort of more and more added complexity. And one of the things that they often do is they just create new menu options. So you bring up the app, and the first thing it does is say “what do you want to do? Do you want your boarding pass? Do you want to check in for another flight? Do you want change your seat? Do you want to find food? Do you want to check your bag?” And it just gives you this list of things. And that sounds great except that, you know, “I’m in the TSA line and I’m running late for my flight and I’m fumbling for my license and my phone. I need my boarding pass on my phone, and now I have to bring up the app, and the app comes up, it and takes a while to start. Then I have to bring up the screen and I realize that I don’t have the boarding pass loaded into the wallet because that’s an extra step and I forgot to do that step. And so now I have to fire up the app and, you know, I’ve got a line of people behind me and I’m running late for my flight and I have to find the right menu and I have to get the right flight. I have to click on the boarding pass for this flight. And then it comes up.” Or you know, we have the technology. It could know I’m standing at TSA because that’s the Wi-Fi transmitter I’m most connected to at that moment or the cell tower that I’m talking to, and it could know at that moment that that I haven’t checked in to TSA because I haven’t gone through that process, and it could just bring the boarding pass right up. In fact, while I’m in the airport, why isn’t the boarding pass on the home screen” That’s the type of thinking, but you don’t want the boarding pass on the home screen all the time. We only want it when I’m at the airport. And the device knows I’m at the airport. It can see that I’m at the airport. So the app can see that I’m at the airport. So why is it not just giving me my boarding pass until I’ve used it to actually get on the flight? And then it should come up with something different like how I connect to the Wi-Fi, or how long the flight will be, or the status of the flight, right. And if we thought about the whole experience we would actually change how the app reacts based on that without me having to explicitly look for the menu option that gets me there. And that immediately reduces complexity because it’s anticipating my needs.

Sean: [00:29:13] Right, weaving it all together in context.

Jared: [00:29:19] But to get that right, I have to do a boatload of research.

Sean: [00:29:22] Right.

[00:29:23] I mean you cannot just get your way into that because you will find yourself in a context that doesn’t make sense. And so you need to really understand what that passenger’s travel journey is like to make sure that you’re always giving them the options that anticipate their needs at exactly the right moment.

Sean: [00:29:46] Brilliant. Alright, so weaving this all together. One last sort of subject here and then I know Joe’s got a question or two for you. Let’s go back to that confident powerful executive who’s telling you what you need to build into your product, right. So I believe that, along your lines, when you’re setting up your product vision, it’s got to be solving problems for the people that are using the products. And if it’s not, everything else along the way gets broken. And we constantly are up against this mindset. We call it the fixed mindset. If you follow Carol Dweck’s work at all, it’s aligned with some of her thinking around how people evolve. But this mindset of: “we have this money, we’ve got to get these features out the door, here’s a list of features and we’ve got to get them out the door by this date.” And when that’s the vision that the whole team is marching to, “we just got to get the product out the door by this date,” everything sort of breaks down because we’re not focused on the problems that we’re solving. Do you have any examples of companies or teams that have managed that whole process well? Because at the end of the day the executive is doing that because he’s probably made some commitments himself, and at the end of the day our teams might be afraid of rubbing them the wrong way or losing the work and it’s this balance in the real world that we have to figure out how to meet.

Jared: [00:31:10] Yeah, so again, the first thing we need to realize is: that executive’s on the team. Right. We often want to position the team and the executive the sort of separate entities…

Sean: [00:31:22] Good point.

Jared: [00:31:23] …and say that the executive is not on the team and now the team has to respond to what the executive said. What we need to realize is, that executive’s on the team because that executive is influencing the work of the team. And anybody who influences the work of the team is on the team. And so we need to treat them as being part of the team which means that the executive needs to see themselves as part of the team. They need to be thinking if they’re making a commitment somewhere else that, “I’m taking this back to the team and we’re going to talk about this,” and that we is because the executive is part of the team. And, you know, some of that’s cultural, as we’ve talked about before, it’s just making sure that that we keep telling the executive that they’re part of the team. “You are part of our team because you are bringing us insight into what customers need. And we’re also learning insight from other sources. So we need to keep everybody up to date on all the insight we’re getting. So we need to include you as part of the team. Now you’re a very busy person. You can’t come to all the same meetings that we go to. So what’s the best way for us, as members of the team with you, to make sure you have all the insights you need so that when you’re making commitments, you’re making commitments that are going to be the things that we can execute effectively as our team representative and that we can make you look good, because, you know, part of our role as a team member is to make everybody on the team shine.”

Jared: [00:32:59] So we need to treat the executive in that regard. And that means that the executive needs to be fully aware of how we work and understand that we work best when we are really understanding the problem. And so that means teaching the difference between a solution and a problem which, for a lot of people, it’s a hard thing to identify the solution and the problem. Because the first thing you do is you start gravitating to bigger solutions. “I need to export data” becomes “I need to get this into the billing system.” That’s still a solution. You haven’t told me why we needed to get into the billing system. Right. So, you know, people play the game of five Y’s, or other types of root cost analysis to sort of get to, “oh wait a second, this is the thing that triggers this, the project is done and we need to signal that to the customer so they know to pay us for the project because that’s the way the project is set up.” So OK that’s really important to understand that there’s this moment in time where we have to signal that. And now we need to work in and through that direction. So that’s what we’re looking for, right. That’s the moment we’re trying to get to, and understanding that that executive is a member of the team is critical to that. So that’s one piece of it. The other piece that’s I think really essential here is realizing that you do your best work and the customers are most happy when you’re solving problems. And so solutions inevitably have to come. But problems are really the focus at the early stages of the work. And then they become the focus all the way through. And so getting all the language around problems, right. And we see this all the time.

Sean: [00:35:04] Right.

Jared: [00:35:05] Here’s an example: I was working with a team that had a research project called video sales, and its entire purpose was to figure out how to use video on their e-commerce site. So they contacted me and they were like, “so what are the best practices for using video on the e-commerce site?” And I’m like, “well there are lots of best practices around using video, there are lots of best practices for e-commerce, what specifically are you talking about? And they’re like well, “we want to integrate video into our e-commerce site.” I’m like, “OK why?” “Well we were hoping you could tell us.” But how would I know? “Have you observed problems that users are having?” “No. But you know, there’s all this video technology out there and we can do things like personalize videos. So when you bring up a product, it could actually address you by name because it gets that name out of a database somehow and inserts it into video. And we want to figure out how to use that.” I’m like, “well why do you need to use that?” “Well we were hoping you would tell us.” I’m like, “I don’t have an answer to this. Have you done user research?” “Yes.” “Has has any of that user research taught you that this is something that you need to do?” “No, that’s why we’re asking you.” And I come to learn that the project name is the interactive video team and if they don’t produce an interactive video, they fail. So they’re off to produce an interactive video even if it’s just a solution in search of a problem. So the way we name things, when we name things the mobile team, or we name things the data export team or the data export project, suddenly that project’s a failure if we don’t export data, even though exporting the data may be the absolutely wrong way to solve the problem. So we have to be very careful when we even create our projects and name them, and create our teams and name them, because we may be doing ourselves a disservice because we create this this moment of failure that is inevitable because we named the thing the wrong thing.

Joe: [00:37:38] Great example. Why, why are you asking me?

Jared: [00:37:41] Exactly. It was so crazy. I did not understand this conversation at all.

Joe: [00:37:50] Well just to close us out on experience rot and then we’ll just ask our final standard question we ask everyone, but, is there like a company and/or a product that you think does a really great job avoiding experience rot or managing experience rot?

Jared: [00:38:07] Yes. Well I think, I mean we saw it in the early days of the iPhone and the iPod. Apple was very good at keeping the functionality minimal, and then they sort of fell into the trap and now, you know, there are so many things that the phone can do that people don’t know that it can do, and it suffers from complexity rot like everybody else. I think the folks at at Basecamp are fantastic at this. Jason Fried and DHH and the folks who run that operation there have been very explicit over the years of keeping spirit to a point where they go to an extreme. They don’t just automatically change products on people, they create a new version of their product (they’re now on their third version) and they leave the other two versions running. And if you don’t have a reason to switch, you don’t switch to the new version. They don’t add any new features to it, they only keep it upgraded for maintainability and security. So Versions 1 and 2 are still out there, and your data is still there, and you can still access it. And they’re happy with that. And they completely rewrite the code from the ground up for Version 2, and then for Version 3, and it’s a different UI and it works differently because they’ve realized that the product needs to be something different. But if you don’t want to switch, you just stay with the old version. But the new customers all come in on the new version. And that’s worked really well for them.

Jared: [00:39:57] And I think there are lots of examples of things like that. Intuit, for example, when they created there, they realized that people were using the Quicken product to manage their rental properties. You know, they had an apartment, or they had a house with a couple of apartments, and they were trying to manage all the expenses and classify them because you have to report them on your taxes differently, and when you go to sell the property, you have to be able to pull out all the improvements you’ve made to the property because that adds to the basis. And so people are doing this with Quicken, which it wasn’t created for, and they were asking for solutions. “Can I classify data this way?” And they finally went out and studied people asking for those things, and found out that they were hacking the product to do this thing it wasn’t intended to do, and instead of just supporting that in the product, they just created a whole new product. They created Quicken for rental management, and it’s one of their best sellers. It’s a high growth product for them. It has a small niche market, but now they can actually tailor it to the actual problems of managing rentals.

Jared: [00:41:18] And I think if you take on solutions like that and you’re very creative about it, you can make sure that you in any given product you don’t have experience rot because you’re actually growing your business by creating separate products, where you can control the complexity, that all work together. And you know, Quicken has a core code base but then they have forks off of that code base that go for the main product for the rental property product. And so, you know, security and basic integrity stuff go in the core product, but things related to tracking and classifying data go into each of the sub products. You know, it’s a bit of work, but it makes it much easier for them to make changes and to grow each product.

Joe: [00:42:08] That was a very cool example with Basecamp. I think that’s a really novel way to approach it. So to sort of close this out, the question we ask everyone: is there a favorite book you have at the moment or that you like to gift out related to product, UX, innovation, any of the likes?

Jared: [00:42:26] Well that’s a good question. Which would be my favorite? Well I have I have so many books that I really like. The ones that I tend to focus on that I refer people to the most are around team building. Marcus Buckingham’s First, Break All the Rules book, which is from the Gallup Organization, and Lou Adler’s Hire With Your Head, which is a book about hiring which is essential for building great teams. Both of those books are really essential for building great teams. So I very much like those books. Kevin Hoffman’s new book on meeting design is fantastic. Scott Berkun has a, it’s not a new book, but it’s it’s a fantastic book on innovation and I’m trying to remember the name of it. If only I had a little box that could tell me the name of any book…

Joe: [00:43:37] Somebody could make a buck off that.

[00:43:39] Oh yes. So Scott Berkun has a book called The Myths of Innovation and anybody who’s interested in innovation needs to read that book because it communicates right off the bat that innovation is not about invention, it’s about adding value and that the way you get to innovation is by doing research. You just spend a lot of time studying problems. There isn’t a team out there that I’ve ever met who, if they really understood the problem, they couldn’t come up with 15 viable solutions to solve that problem right off the bat. People who are trying to innovate who struggle at innovating just don’t understand the problems they’re solving. So that’s sort of the core message of Scott’s book, and it’s brilliant.

Joe: [00:44:30] Those are great, we haven’t heard those ones yet. Thank you.

Sean: [00:44:33] That’s great. Well you never disappoint, Jared, this is a great interview. We really appreciate you spending time with us. Thanks for joining us today.

Jared: [00:44:44] Thank you. This is this has been fun, and now since I never disappoint, that’s something to achieve. I will add that to my bucket list.

Sean: [00:44:53] I’m going to end with one of my favorite all time conference quotes that I heard you actually utter these words as you closed out the ITX conference in Rochester. Heroin is delightful.

Jared: [00:45:16] Heroin is delightful.

Joe: [00:45:16] Alright, so that’s it for today. Thanks for listening. And we’re not going to just talk to talk, we’re gonna walk the walk, so we would love if you go into your podcast products and leave us a review. Sean and I guarantee, we are committed to reading absolutely every piece of feedback we get there, and not only that but you’re helping other listeners. By getting that feedback in there, it helps us move up the search rankings so that other people can find the episodes. So thank you everyone.