Avoiding Overrun (and Lawsuits) through Better Project Management with Jessica Hall

Jessica Hall: Technical debt is not bad. It’s like any other debt. We are going to take it on at some point, and as long as it’s not too much, then we’re OK.

 

Joe Casabona: That was Jessica Hall telling us that technical debt is OK and that if you do any web project or any programming or technical projects for some amount of time, you’re going to have technical debt. Jessica Hall is the vice president of product strategy and design at 3Pillar Global, and we are going to talk about something that made a bunch of news a couple of months ago. That’s the Accenture/Hertz case. If you don’t remember the Accenture/Hertz case, Hertz hired a firm called Accenture to redo their website and mobile app. They spent a bunch of money, $32 million dollars, and claim they had nothing to show for it. Jessica is going to go through the four pitfalls that this project went through and how to avoid them. With some time behind us since the story broke, we’re going to sit back and look at exactly how it happened, and like I said, Jessica is going to show us how it can be avoided. There’s a lot of really great actionable advice and information in this episode, and the show notes are plentiful. You can find those over at HowIBuilt.it. Let’s get into this interview without further ado, right after a word from our sponsors.

 

Break: This episode is brought to you by our friends at Ahoy! The easiest way to increase customer engagement on your WordPress site. Install Ahoy! Create a message box, configure a way to display it, and start seeing conversions come in. You can create messages for cart abandonment, up-sales and cross-sells, custom support, and so much more. Ahoy! Has flexible conditions that let you choose exactly where and when you want your message to be displayed. I’ve recently installed it on my own WooCommerce site, and I’ve already seen increased engagement. I know this because of Ahoy! and it’s powerful analytics and reporting. You will see ROI within days of installing Ahoy! If not sooner. That’s even more true for listeners of How I Built It. You can get an exclusive 20% discount on any plan. Visit UseAhoy.com/HowIBuiltIt and use the code HOWIBUILTIT at checkout. Use those today and increase your engagement in sales on your WordPress site. Thanks to Ahoy! for their support of this show.

 

Joe: Hey, everybody. Welcome to another episode of How I Built It, the podcast that asks, “How did you build that?” Today my guest is Jessica Hall, the VP of product strategy and design at 3Pillar Global. Jessica, how are you today?

 

Jessica: Great. Nice to be here, thanks for having me.

 

Joe: My pleasure. Thanks for coming on the show. When you and your team reached out to talk about the subject that we’re going to talk about today, I was pretty excited because it was timely, and I think very interesting. But before we get to that– I guess it’s not a big reveal if people see the title of the episode. But before we get to that, why don’t you tell us a little bit about who you are and what you do?

 

Jessica: I lead the product management, user experience, and consulting teams at 3Pillar. We’ve been in business for about 13 years, and we’re a product development services company. We help clients from a small size to enterprise figure out what’s the right client and what’s the right product to build, and then help build it and help continue to improve and evolve their products so that they can drive their businesses forward.

 

Joe: That’s fantastic. That makes you perfectly positioned to talk about the Accenture/Hertz case, which is a few weeks old as we record this. This episode is coming out over the summer but for those who need a reminder, what exactly went on in the Accenture/Hertz case that we’re going to talk about today?

 

Jessica: Usually, when a big company is involved in a challenging project, you don’t hear much about it. But every once in a while, it goes so wrong that someone decides to sue somebody else. They’re so pissed off that they can dish all the dirt all over the internet, and in this particular case, Hertz had hired Accenture to redo its website and its mobile app to improve the Hertz customer experience. Every company right now is competing for customers and customers are in charge, so you need to provide a quality experience that’s easy to use, that has the right features, that’s attractive. Because everybody else can go somewhere else. So they engaged Accenture to do this work, and they spent about $32 million dollars and had nothing to show for it. $32 million dollars and they said the work that was done was so bad that they had to spend an additional $10 million dollars with another company to get to something that could be done. It’s pretty amazing to think that you can spend all that money and things are going to go wrong. Now, I think it’s important to say that all Accenture has said here is that they intend to fight this and that this is not the truth. So we’ll never know what happened in Hertz and Accenture, but if you read the complaint– It’s about 16 pages and not that hard of a read, you can get an understanding of “Why did this go wrong?” What are some of the things that happened here that I’ve seen happen in lots of other companies and companies that are a lot smaller? I think there’s a lot to be learned from digging into a situation like this and trying to understand, “Why did it go wrong? Where did it go wrong? What can I learn in my next project to prevent something like this from ever happening?”

 

Joe: What a fantastic summary and primer, because you’re right. Especially for probably a lot of the folks who listen to this show, $32 million dollars is a ton of money. It’s exponentially more than I’ve ever charged for a project, though.

 

Jessica: Me too.

 

Joe: Quite a bit more than– I’ve worked on big projects too, but nothing in that multiple. You do wonder, “How does a $32 million dollar project go wrong?” Like you said, we probably won’t know the gritty details, especially if they settle– If this is not a matter of public record. But we have seen high profile projects like this go sideways before, Healthcare.gov is one that came to mind as I read this story. In this episode, we’re going to talk about how both you the freelancer, or you the agency, and you the hiring party, can prevent that from going wrong. Does that sound about right?

 

Jessica: Yeah, that sounds about right. I think there’s a couple of things that are specific to this case, but there is about four pitfalls that I’ve seen pretty commonly. We’re going to talk a little bit about what happened here, what those four pitfalls are that we see time and time again, and then what to do about it.

 

Joe: That sounds great. For those who are regular listeners, this might not be a show in the usual format. But I think that there are– There’s going to be a lot of value here. Let’s start off with the four pitfalls and then we’ll go from there if you want to say them as bullet points and then we can expand them out.

 

Jessica: Sure. A couple of things I think were specific to this one, it was surprising to look at this complaint and see that they tried to do everything all at once. They tried to do the whole website and the whole mobile app all at the same time and launch everything together. That’s pretty– People used to do that, but that’s risky. There’s so much that could go wrong. And we’re talking about hundreds of thousands, or potentially more dollars if you get it wrong, that experience, rather than doing it in pieces and making sure that we have the right thing. They did too much right away. They also didn’t seem to test it very much. Their complaint said that there were a lot of security and vulnerabilities, that they only tested the “Happy path.” Meaning, what people would do if they did everything right. I can tell you for many years of doing this, and nobody does that. Nobody knows what they expect you’re going to do. Or, what you expect them to do. That’s actually where to me it felt a lot like Healthcare.gov. They just dropped it all at once and hoped for the best, and they didn’t test along the way. We also never saw a mention in the complaint that they were actually engaging with customers, that they were doing testing or doing research or trying to figure out what the right answer was for Hertz’ customer, which is crazy on something that stale, to think that they are going to get it all right and that they know the answers on what those customers really need. The other two things that jumped out at me when I was reading the complaint was, one is that they got stuck in the middle. A lot of times people will say, “We’re just going to do a redesign. We’re just going to skin it.” There’s the phrase of, “We’re just going to skin it.” OK. That’s a bunch of crap that never, ever happens. You go into it, “We’re just going to change the colors and fonts,” they always want to do more stuff like that, and it always means back end changes or integration layer changes, and that ends up being a whole bunch more work. A lot of people don’t understand when you open this up, and other stuff is going to be there, you can’t just change the color. Maybe that’s the way it should be. Maybe that’s the way that technology is done. But in reality, there’s always such messy stuff once you get into this, and a lot of people get stuck in that middle ground, or they think, “I’m going to do a mobile website, a mobile app.” The mobile app piece of it is just the smallest, where the bulk of the work is going to be on all the integrations with other systems or the services and making sure all of those things work. So many people only see that top little bit and think that’s what they have to do, and then they’re completely surprised and frustrated when they discover that’s not it. One of the other things that hurts when you do it is a lot of extensibility so that they own multiple properties, so dollar and thrifty. They wanted something that was going to work on all of their different brands so they could immediately expand it, and that’s good in practice up until the point when it’s not. Because dollar and thrifty in these other brands, they have different brand promises, they have different target customers, and they may require different things. Extensibility is good until the point where you’ve made it so consistent and so basic that you haven’t been able to provide a good experience for that different customer. The other thing is, “Do we get that extensible? It’s going to cost a lot of money and a lot of time.” These are definitely common issues, but they relate to the four things I think people mess up the most. This is going to be like, “Let’s talk about all the bad stuff, and then we’ll talk about the good stuff.”

 

Joe: I think that’s a great point. They tried to do that, all of this at once. They never engaged in Hertz customers, and they were stuck in the middle as “We’re just going to skin it.” When you said that I had visions of my former jobs, and then there was maybe too much extensibility, where they’re like “We’re going to make something so general that could be used for everything.” But something that general needs to be architected well, and it needs to– There’s a lot of blanks that you’ve got to fill in if something’s that general. So, let’s start with they tried to do all of this at once. Because there’s I have a master’s in software engineering, and we studied some statistics for our software projects, and in the 90s, during the period where the waterfall model was the most popular, something like 96% of all software projects failed. It’s probably akin to this reason, and people were doing everything at once. Now there’s the Agile method and other methodologies that allow you to do things more piece-meal. Create an MVP and then iterate, and because of the tools and the platforms we have, we can do that today. So if I’m a potential client and I need a project of this size, what do I do to make sure that they’re not going to try to do things all at once?

 

Jessica: I think that’s a really good point. It’s funny you talked about the 90s because The Agile Manifesto was written in 2001, I believe. It came on the back end of it. Not to say that Agile doesn’t have its challenges.

 

Joe: Sure.

 

Jessica: But if you’re someone who has got a website, or a mobile app, or some product and it’s time to make a big investment, it can be tempting to say “I’m going to do it all at once.” I want people who are going to execute against this plan. The funny thing about Waterfall, it’s the most efficient way to make software. It is. If you designed it all at once, and then you build and architect it all at once, and you build it all at once, that would be awesome. The problem is, we don’t know what the right thing is when we start, and things change along the way. That’s why you need Agile. The way I think of Agile is about swimming in open water. If you want to get from here to here, Agile is good about being efficient with your stroke and making sure that when you’re swimming you get as much distance as you can out of that stroke. But you’re on open water, and there’s a wind, there’s waves, there’s boats, there’s other people. There’s some things around, so if you are swimming and you’re not looking where you’re going or making adjustments to make sure you’re getting to your intended destination, then we’re not going to get there. A lot of people, they say “We’re Agile, we’re doing Agile, we have sprints [and we haven’t] [inaudible],” and all this other stuff. But they’re not looking where they’re going. They’re not saying, “Are we headed the right direction? Is this the right thing to do now? Did we know that that was the right answer?” They get locked into this execution mode, and they forget that there is still experimentation that needs to happen time and time again. We still need to make sure, “Do people understand the text on this button? Does this flow work? Does that screen make sense? Is this the way that people think about shopping for this, that I need to adjust?” What I think people forget to do in these situations is they’re trying to do everything at once and say, “Let’s do one flow. Let’s do one thing, one piece of the pie that we can carve out, make sure that works. We learned how to do it, and we’ve now got the new services. You go end to end, then let’s add and build upon that and then start to take away those other things.” You’re going to do a couple things. One, you’re getting that opportunity to learn from your customers and make sure you have the right thing. Two, from a technology perspective, you’re making sure that it works end to end. I can find something, and I can choose something, I can see more about something, I can take action on something. When you know you have that end to end experience, then you learn a lot about what to do. Then you can build on that learning, and teams can get going. It’s hard to do because people don’t necessarily think like that. I think we have this notion back from when you’re in school, and you got an “Incomplete.” An “Incomplete” was terrible, and it was just better than an “F.” So we don’t want to be incomplete, and we don’t want to slice things up, so you’re worried that “I’m never going to get this thing if I’m willing to give this up.” It’s being willing to say, “I’m going to take the first step, and I’m going to trust that there’s going to be more steps after it. I will have more opportunities to do things and to bring them along.” A lot of times what I tell people is, “Think about– Carve it into pieces. Is it one flow? Is it one persona? Is it one piece of the experience? Is it one–?” To try and look at and say, “What’s the smallest thing?” I could attack this piece of it and get started. One of the other things is having worked with a lot of clients, and people usually like– We usually like the “Get to know you” project. It’s small, it’s self-contained as best as possible, and it gives all of us an opportunity to work together, to learn how to work together, to make sure we can deploy software. Because a lot of things go wrong when you’re trying to make a deployment. When you’re trying to carve off this piece, then you have an opportunity to get to know each other and get comfortable with things, and you’ve done everything. When people try and do too much, then there’s just so many dependencies and so many challenges, and they get frustrated. But, yes. Small, self-contained, go end to end and make sure you can push something to production. Then you have a good chance to start off on a strong footing. The other thing people mess up in these situations is they forget how much context matters. A lot of times, if you’re dealing with an agency or a contractor, “OK. Here are the stories. Go write the code.” Or, “OK. Here’s the design,” or “Here’s the brief,” or “Here’s this something. Go off and do it.” The number one thing I see people do wrong, whether they’re sitting next to each other, they’re in the same time zone, they’re on opposite sides of world. People have to understand the context. They have to know, “What is this business? How do we make money? What are we trying to do with this project? Who is our customer, and what are we trying to do here?” If they have that in mind, and we call it the product mindset, then they can build for outcomes. But time and time again, I see people don’t invest in context. They’re like, “Here’s the roadmap. Here are your stories.” You’re like, “OK. What am I supposed to do with this?”

 

Break: This episode is brought to you by Pantheon. Starting a new project? Looking for a better hosting platform? Pantheon is an integrated set of tools to build, launch, and run websites. Get high-performance hosting for your WordPress sites, plus a comprehensive toolkit to supercharge your team and help you launch faster. On Pantheon, you get expert support from real developers, best in class security, and the most innovative technology to host and manage your websites. You can sign up a new site in minutes with a free account, and you only pay when it goes live. That is my second favorite feature to Pantheon, only to the easy ability to create dev staging and live servers and push to GitHub. It’s very easy to set those things up on Pantheon, so you can head over to Pantheon.io today. Again, set up a free account and pay only when it goes live. Thanks so much to Pantheon for their support of this episode and this season of How I Built It.

 

Joe: I just finished a project with a few friends where we created 40 videos for– We created 40 tutorial videos for a company, and we started off by doing one. Getting the intro and the outro right, doing the music and the pacing, and we sent that to them for approval before we started to do all 40, or all 39 of the other ones. Because if we had just disappeared and did 40 videos, then we come back and “All of these are wrong at this point,” or “We don’t like the music you chose.” That’s a lot of sunk cost.

 

Jessica: Yeah.

 

Joe: Then, the other point that you made about understanding context is really important too. With Agile, you do have user stories. With the Waterfall method, you lay out the whole project all at once, and that does work if people know what the right thing is and what they need. But if you say, “I need a form.” “What kind of form, a login form? Are you sending secure information? Does it need to be on SSL? Do I need the password field? How am I storing it?” There’s a lot of information aside from “I need a form for this user.” The second pitfall– I will say that under the first pitfall you also mentioned “Testing the happy paths.” We’ve talked about that a bunch of times on this show about– I know I’m a developer, and I’m very bad at testing my own code because it’s like building a chair and then slamming it against the wall to see if it breaks. I’m just going to tap it against the wall. But somebody needs to test that chair because I don’t want people sitting in it and falling, so I think that’s super important. But the second pitfall you mentioned was that they never engaged with Hertz customers. Right?

 

Jessica: If they did, they didn’t mention it. It wasn’t mentioned– There were 16 pages in there, I never saw one mention of “They engaged with the customers.” It says, “Accenture was there to make all the decisions about what the experience is,” which is just nuts. Even as a service provider, Why? No. You don’t abdicate all your decision-making ability. But it struck me that a project of this scope and scale that’s dealing with something that is highly commoditized like car rentals, where people are just making– For a lot some people– Some people have loyalty programs. I think I am a Hertz Gold member. I don’t rent cars hardly ever, but maybe if I was a hardcore business traveler who always rented a car, I would go with the place that I have loyalty. But when I’m traveling with my own money, I’m going for whatever has got the best deal. If you’re going to be a pain in the butt, I’m not going to do it. So it’s shocking to me now with everything we know, that you wouldn’t be testing with customers, you wouldn’t be understanding. But I definitely run into people who think that they know. They know what people need, and “I don’t need to test it, that’s just going to slow us down. We got this.” I can tell you from all my many years of doing this that I know I don’t, and every time I learn and test with people, I get better, and the team get smarter, we get smarter as a company. We better and more understand by engaging with people in a very human way and understanding them and how we can better serve them. We find new ideas for new things by being engaged. That doesn’t mean I can’t have vision, that doesn’t mean I don’t have a good strategy. All those things can be true, but then strategy without testing is just guessing. You’re guessing, you’re guessing in a pretty deck that sounds authoritative, but you’re still guessing. So why don’t we go find out?

 

Joe: Absolutely. If you build something that isn’t usable to the customers, then it’s not usable. You’re not building– This is something that I’ve had to tell my own clients over the years, “I’m not building this website for you. I’m building this website for your customers and your potential customers.” As a freelancer or a small agency, what can I do to help try to convince my clients that maybe I should test and talk to the customer? Because $32 million dollars for a project, they probably have the money to do the user testing that they need to do, and the surveys and stuff. But if I have a client that’s a $10,000 dollar product or a $5,000 dollar project, how do I convince them to invest the time in listening to their customers?

 

Jessica: That’s a great question. I have seen it go and decline throughout my career, where I had to fight hard for it, and I’ve had to fight less and less as the years have gone on. But there’s definitely still people who aren’t interested. I think one of the things that’s the reservation is they feel like it’s going to slow them down, and it’s going to cost a bunch of money. So, let’s deal with that. We believe that UX research and testing should be fast, flexible, and focused. Fast, flexible, and focused. We want to do regular testing, we want to do weekly or two-week sprints where we’re working on figuring stuff out, and testing and learning and iterating through, and working in those small chunks. That’s the fast part. We don’t need more than five people. When three people have told you the same thing doesn’t work, stop. You don’t need 20, and you don’t need some crazy sample size. Just stop and fix it and then go and make sure that you got it right. Nielsen Norman Group has looked at this many times, diminishing returns kicks in incredibly quickly. Three to five people look at something, you’ve got a pretty good sense of whether that is going to be right or not. You’re able to move quickly, and we’re able to test in lots of different ways. There are lots of different panels and user groups, and moderations, and remote tools that allow you to be able to test things without having to have a device lab or spend a bunch of money on sending people out. I’ve definitely done it on the street and found people, so you can find– There are lots of companies that– We do work with user testing and other organizations, and they make it easy for you to do this. Cheaper and way easier than when I started out, so you can do it fast, and you can do it flexible, and you stay focused on the most important question. If my login screen is like Facebook or Google’s, I’m good. Maybe a little testing, but I don’t need to spend the time. If there’s something that’s important to my brand promise or that I’m not sure about, I’m going to invest my time in testing that. So if you’re doing this regular testing and feeding the machine, you’re going to go faster because you’re not going to spend as much time on rework. You’re going to go faster because your engineers are going to have better context as to the problem we’re solving and who are solving them for. You’re going to have a lot less waste and a lot less risk, so even though you think it’s going to cost a lot and slow you down and not get you to the right place, we can speed up. We can have a better product, and we have less waste and less risk because, for the most part, very few things are going to go like Hertz. Go down in a $32 million dollar trash talk on the internet. Most things are going to go down with a thud. I don’t use it, and I’m just going to move on.

 

Joe: Yeah, absolutely. I love what you said here. There are a few things that reminded me of tools that could be very helpful to those who are looking to do fast, focused, and flexible testing. One is Hotjar, which is just a free tool for the basics. But it’s screen recordings of people who are using your site so you can see exactly how people use your site. Then Google’s a/b testing. You said to focus on the most important question if you have a landing page, are you going to test the banner color or the call to action? The call to action is the thing that you’re going to want to test, because that’s more important, and a/b testing can help you do a little bit of that focused testing.

 

Jessica: Those are great tools. We use Marvel, and we use user testing, we use a couple of other providers and things that have definitely sped up our tools. I think our toolset unit goes back and forth and is a pretty reasonable cost for us. In some cases some of these vendors and everyone I talk to I’m like, “Listen. I need to be able to do this [path’s pass through].” One of the things I do that might be useful is when we’re doing a project that involves this right from the get-go, I might need help recruiting, here’s what that cost looks like, I’m going to pass it through, here’s how it’s going to affect the timeline. I think one of the things if you want to do user testing and user research in a project in your own agency, make sure you have that conversation upfront about what you’re going to do and what you might need, so that when or if you need it maybe they can do recruiting. Some people can. Some people can provide enough customers that you don’t need to do your own recruiting, but you want to be prepared to have that already. You’ve already talked about it, you’ve already established what the baseline pricing would look like. You maybe even put it into your contract so that when you need it, now you can pull the trigger. You’re not going to get stuck behind– Because what will happen is now your research will drag on. That may mean everything else drags on, and then you’re going to cause some problems for yourself. Get that done early, know where and what you want to do, have the plan, have a plan for recruiting so that when you start you are ahead. Because if you get behind, everything else is going to get behind.

 

Joe: That’s fantastic advice. Start early. Fast, flexible, and focused testing as early as possible. We are over the halfway mark, and there are two more pitfalls– There are two more pitfalls that we should discuss here. I want to make sure I got them right. They are “Don’t get stuck in the middle,” And “Too much extensibility.” Are those two that we still need to cover?

 

Jessica: Yeah, those are definitely the two that I thought were specific in this. In things that particularly if you are an individual contractor or an agency. Getting stuck in the middle is tough, and that can cause a lot of pain. Because a lot of times when people are starting this, even you and I might be talking to a client, we’re like “OK. That seems easy, seems straightforward. OK. I think I have a notion. What’s the Slack? OK.” Then you get– Just be prepared for when you get in there, it ain’t going to be what you think it is. Some of it will make sense, and some of it will not. That’s not a bad thing. Technical debt is not bad. It’s like any other kind of debt. We are going to take it on at some point. As long as it’s not too much, then we’re OK. As long as we’re managing, as long as we’re thinking about it, then we’re going to be in a company that doesn’t have any technical debt, and we’ll probably go out of business because they didn’t get a good product to market that anybody wanted to buy.

 

Joe: That’s so great. They probably iterated too much, they never released something, and then people started to use it. They just kept redoing it in– Whatever, VUE, React, Angular. Going back–

 

Jessica: They made something that is technically awesome but that nobody wanted, so “Who cares? It doesn’t matter.” It’s OK to– You’re going to find things are going to be harder than you expect them, and that’s OK. Then we’re going to, piece by piece, start to untangle it and pull things out and replace them and put in other things. I watched a talk from a VP of engineering at Stitch Fix a couple of years ago, and he’s like “All of these major companies, they all went from monolith to micro services, they all have to rewrite the whole architecture every couple of years. This is just a natural part, and these things are going to happen, it’s going to be messy. We’re going to have to rip it out.” Just making sure that when you go into one of those deals, you’re like “OK. We’re only focusing on the front end.” But to manage expectations of your client, that these other things could happen and if they do, that could have a significant impact on both the timeline and the cost. It’s like watching one of those home improvement shows, and they start taking walls down– They’re like “Here are the termites. This electrical is not up to code. Now I have a fire hazard of some sort.” When you get in there, those things are going to happen. That’s another reason for just really making sure you’re going all the way through. You can do something, and you can deploy it, and everything’s going to work, you’ll be able to monitor it, and you’ll keep yourself out of trouble. But you’re definitely going to have to do some work to manage expectations that this messiness exists. Even when we’re all sitting around the table thinking it’s going to be easy, it may not be. Somebody is going to end up paying for that, and you don’t want it to be you.

 

Joe: It’s either you’re going to pay for it in lost time and sunk costs in the project, or your client’s going to pay for it, and that’s going to be an unexpected cost for them. I think that’s– I love what you said about technical debt because you are always going to have it. I know a lot of people who listen to the show work in WordPress, I’ve had projects where it was just “We’re just going to skin it. We’re just going to change the theme.” Then we get in there, and every page was hardcoded into the theme. The content was so deeply embedded in the theme that I was like, “We can’t change the theme without losing all of your content.” So then we had to export all the content, and that added a ton of complexity right there. You’re absolutely right. If somebody says something to the effect of, “We think this should be pretty easy for you,” or, “For an expert, you probably know what you’re doing, it’ll be really easy.” That’s always a red flag for me. I don’t want somebody to tell me it’s easy, and I want to get in there and determine, “This is easier than I thought it would be.”

 

Jessica: There is no such thing as [inaudible]. People always think that it just doesn’t, and I’m like “Nope. It doesn’t. No. Sorry. Never happens like that.” Not as long as I’ve been doing this, and that’s been a while.

 

Joe: Yeah. Same. Assume the worst. If it is just easier, everybody’s going to be pleasantly surprised. Your client’s going to be happier, you’re going to be happier, and then you could do either some extra for them, or take some money off of the cost, or launch faster. That’s better than having to bring bad news to your client.

 

Jessica: There will be the person who’s just going to ignore and hope for the best, who’s going to lowball it, and so what I typically tell people is “Anybody who thinks– Who is overly rosy and optimistic about these things, that’s probably not a good sign. If they’re not talking to you about risks, then that doesn’t say to me that this is a person who has bruises and scars. This is a person who’s done these things before.” Because any of us– You certainly shared some, and so have I. Any of us have been around the block, we know that these things are happening and we’re talking about them. So if you are someone who wants to buy, you’re in the market, and those folks aren’t talking, “Here’s the things that could possibly go wrong and let’s talk about those ahead of time. Let’s think about–” If everyone’s like, “It’s great. Yeah. No, it’s $40K, four weeks, no worries.” I don’t trust that person. That person is either maybe not being entirely truthful, or they’re maybe not entirely knowledgeable about what has to get done.

 

Break: This episode is brought to you by Creator Courses. Do you feel confused and overwhelmed by the amount of tools to help you build websites? Are you worried that you are not using the best tools for the job? Do you feel like you ought to spend more time building and less time researching? Like you, I thought I needed to learn every tool, language, and platform under the sun to be a good web professional. As somebody who’s been doing this for 17 years, I can now tell you, you don’t. Creator Courses offer short focused courses, tutorials, and webinars to help you learn the right tools quickly. Then you don’t have to waste any more time researching, and you can get back to producing billable work, confident that you’ve made the right choice. Now you can access all of those resources by becoming a Creator Courses member. You’ll be able to take any course we offer, including member-exclusive mini-courses on how to use specific tools. You’ll also join a great community, and listeners can get 15% off the already low price by going to CreatorCourses.com/Build. Spend less time researching and more time building. Visit CreatorCourses.com/Build today.

 

Joe: There’s a reason that sites like Kickstarter require their project people to post risks. Because if they haven’t thought of the risks, then they’re maybe misrepresenting their project. So always consider the risks, even if it looks like an easy five-page brochure site. Maybe the client takes you two months or four months to get you content, and now the whole timeline is blown out, and you don’t know when you’re going to get to it. So there’s a lot of things to think about. It’s always nice to be optimistic, but also be a realist. The last point as we wrap up here is extensibility. This is an interesting one to me because as a software developer I’ve always been taught, “If I’m going to use it more than once, try to generalize it and try to make things as a sensible as possible.” But as you mentioned earlier, there could be some pitfalls to that.

 

Jessica: I think it’s going to show up in a couple of places and in general, as a rule of thumb you shouldn’t invent a lot of extra stuff. I think the question to ask yourself in this situation is, one, “Is that right for the business?” If you’re in a situation where we’re a fast-moving startup, we’re just trying to get going, and we’re trying to get revenue, we’re trying to launch. We’re up against it, and we’re not entirely sure about this thing, we need to get it out there and figure it out. It probably makes sense to not necessarily make it extensible, to make extensibility a problem for another day. Thinking about the business and “What does the business need right now? What does this business need at this moment? Will it be OK to go ahead with that, or are we going to have to pay that down tomorrow, or are we going to have to pay that down in a couple of months and be willing to make that decision?” Being willing to think about that from what makes sense. One of our architects likes to say “Solve for today with tomorrow in mind, but you don’t solve for tomorrow because tomorrow is not guaranteed.” We may not have that. So that’s the thing. If that’s OK and you make the right call, and you get to tomorrow, and now it’s not working for you. OK, now we’ve got to fix it. Now we’ve got to build it the right way, but we’re building it the right way knowing it’s what we need, and that’s a big difference. Was it [Martin Beck] or [inaudible] who said “[Yagni, Yig] going to need it?” The idea is when you built it for the– You tried to build everything all at once, and you got there, and you found out it wasn’t right, so don’t do that. The second thing is to ask, “Is it right for the customer?” For example, if you have– In this particular case, there were multiple brands. Each brand has a bit of a different customer base they’re using. They have a different brand positioning, they have a different value proposition, forcing everybody to be the same– I’ve read some recent Forrester research about this. What Forrester was saying is that their customer experience index that they do every year had been largely flat, that people weren’t seeming to grow, that they hit it and their hypothesis in their research was that– There was so much sameness. That everything was the same, and everything’s about the easy– Nothing stood out. Nothing provided unique value to the organization, and they kept lining up all these pictures of “These are all the check-ins, and these are all the buys, and these are all the other things,” and there were all the same. So one of the questions to ask yourself is, and this is super dangerous by the way, I’ll tell you why in a minute. “This is great, and it’s extensible. But is this what my customer needs? Have I sacrificed customer experience or an ability to delight a customer, or create something that’s uniquely valuable to a customer at the altar of extensibility? The downside here is then you get people who are like, “Let’s make everything different just to be different.” And not test. Like, “No.” This is a very carefully calculated decision, one that I would encourage to do research tests around. To say, “Should this be different? Because we need to solve a problem that’s unique to this customer, that’s different from those other customers.” That’s why the login experience shouldn’t be different or check out, or if it’s something that all those products have done that’s very tactical, and everybody knows it– If somebody had a different ATM experience that might be problematic. It’s Avis actually, while we’re on the rental car thing. Avis created a form– Please, I hope I got the right name. That might be the wrong rental company. They used Asterix for optional fields. You at home may not be able to see the face that he just made. The surprise face. Normally an asterisk means that something is required, so when they used asterisks for things that were optional and things that were required did not have asterisks, everybody was confused. It’s a delicate balancing act between having consistency that provides ease, and having and knowing that there are certain things where you want to deliver for your customer and differentiate and have this value proposition. Something really special that’s going to make people want your product. Knowing what that is and not just getting stuck in, “It all has to be the same.” Because that may not be the right answer.

 

Joe: If you’re going to make an omelet, differentiate it from the stuff you put in the omelet. Don’t swap out eggs for pancakes, or something like that.

 

Jessica: Well done.

 

Joe: Thank you. I love that. I keep saying I like that, but you’re saying a lot of things I like. Definitely ask what’s right for the business and the customer, and solve for today with tomorrow in mind. I think that’s something that a lot of people need to remember. It goes back to when you’re launching your product, get that MVP out. Don’t focus on making it perfect because perfect for you isn’t going to be perfect for your users, and I’m reminded of my favorite learning management system plugin for WordPress, which is LearnDash. They launched something quickly, and then they realized maybe they didn’t do things the “WordPress way,” where there are certain guidelines that you should follow. But it’s software, and they were able to iterate on that software and push out updates pretty quickly for those things. So they got out a good product, people started to use it, they listened to their feedback, and they pushed out updates. That’s the beauty of being able to write software today.

 

Jessica: One of our principles are the product lines that we teach our folks, and it aligns well too. That’s a great example, by the way. I love that one. I’m going to have to remember that. We say, “Minimize time to value,” so our goal is to get something to our customers’ hands as fast as possible. If it’s on your machine, or in a dev environment, or it’s a mock-up, or it’s sitting in a prototyping tool, you have not created value. That’s activity. Value exists in the hands of your customers, so how fast you get it into their customers and figure out if it works for them and go from there? So minimize time to value is one of those key things that people often get wrong because they want it to be complete and they want it to be perfect, and they want it to be completely extensible. They want to be able to serve 10,000 customers before they serve 1,000. I think the question to ask yourself is, “Are we minimizing time to value? Could we deliver something quicker? Could we learn faster? Could we speed this up?” Almost pushed yourself to the point where you if you feel a little uncomfortable with how fast or how incomplete it is or how not perfect it is, that’s probably OK. That’s probably a good indication. I think it was the founder of LinkedIn who said “If you think it’s good, you probably spent too much time on it.”

 

Joe: That’s a quote that keeps cropping up in my circles too. Or some permutation of that. “If you don’t look back on your first version and cringe, then you probably spend too much time on it.” That’s fantastic. We’re a little bit over time, but that’s OK because there’s a ton of value here. But I do want to wrap up with my favorite question, even though you’ve given us so much great advice today. Do you have any trade secrets for us?

 

Jessica: Trade secrets. Lots. I have many NDAs. I think the one thing– I was telling somebody on my team this, and it’s more about how to deal with a client and how to make a good product, but I think it works with what we’re talking about. Some people hold their ideas very closely, and if you want to challenge their ideas, you are challenging them. So what you want to think about, if you want to challenge an idea and that person holds that idea tight– I started off as a designer, so I got my butt kicked for the first part of my career. I don’t hold my ideas very closely. That’s how I protect myself. But some people do, so create that distance. Ask a lot of questions, try to understand how it furthers the objectives, and how it’s going to help solve for these– How are we going to manage these kinds of risks? How is it going to help us achieve these things?” Push into it. Don’t just challenge the idea right away, ask a bunch of questions, probing questions about what the outcome is going to be from what they’re trying to do, and you’re going to feel a moment where they start to detach from that idea. That’s when you need to– As a freelancer, as someone in an agency, it’s that moment where they’re willing to– They let go a little bit, and now you can suggest an alternative. It’s not going to come from a defense– They have separated. Now that they’re going to come from– They’re not going to come from defensive place. Now they’re contemplating the idea, and now they could say, “Have you thought about this? I think this could help in these couple of ways,” or “Building off your idea, here’s something we could do. Here’s an experiment we could do to figure it out.” If I was going to give you my trade secret, what I teach all my designers and product people is to create that space. When you feel it open up, that’s when you go after the idea and challenge the idea.” That tends to work a little bit better than just “Yeah. That’s dumb.” That’s not very productive.

 

Joe: Yeah, absolutely. What a great trade secret. I love it. That, and something else you said about knowing that you don’t know. Reminds me of I went to a Jesuit college and we studied Socrates a lot, and those are two very Socratic things. The Socratic method is essentially “Ask a bunch of questions to get your– In this case, your opponent into a corner.” But you’re asking, “This is great. Have you thought of this? How does it do this?” Then they realize maybe they didn’t think it through as well as they did, and now they’re open to feedback because now you’re helping them make the idea better. You’re not just shooting it down.

 

Jessica: Yeah.

 

Joe: Fantastic. Jessica Hall, thanks so much for joining me. Where can people find you?

 

Jessica: I have a book coming out in the fall called The Product Mindset. If you go to www.ProductMindset.com, I said the Ws, does anybody even do that anymore? If you go to ProductMindset.com, you can find out all about the book, and there’s some research coming with it as well, some additional research. It will be out in September, which is very exciting. We just got the advance copies today and don’t entirely believe this is happening.

 

Joe: That is super-duper exciting. Congratulations on that.

 

Jessica: Thank you.

 

Joe: If it is your first book, I just assumed–

 

Jessica: Yeah.

 

Joe: Very cool. I will link that, ProductMindset.com in the show notes as well as a whole bunch of other stuff that we talked about because this is a resource and advice-rich episode. Jessica, thank you so much for joining me. I appreciate it.

 

Jessica: Thank you so much for having me. It was a great conversation, and I will definitely be checking out those resources myself.

 

Joe: Thanks so much to Jessica for joining me this week. I love that we talked about this topic because it’s not necessarily how she built something, but it does have a lot of really great themes. I love what she said about “If a company doesn’t have technical debt, they are probably going out of business.” I think that’s so great. It’s something we’re all afraid of, and I don’t want to have technical debt. But the truth is that as soon as you launch, you’ll probably have technical debt. Anyway, thanks to her again and thanks to our sponsors Ahoy! Pantheon and Creator courses. Without them, this show would not happen. My question of the week for you is, “What has been the biggest nightmare project that you’ve worked on?” You don’t have to be specific if you can’t name names, but I’d love to hear some of those horror stories, and I might even make it a bonus episode out of it. Let me know by e-mailing me, Joe@HowIBuilt.it or via Twitter @jcasabona. That’s it for this week. Until next time, get out there and build something.