Episode 24: Maintain and Improve (w/ David Hobbs)

Hey. This is Corey, co-host of The Web Project Guide. This is episode 24 which corresponds with the last chapter of The Web Project Guide. We will be taking a few months off to refresh and rejuvenate and rethink the future of The Web Project Guide. So stay tuned and we'll hopefully talk to you again in 2024.

(00:26)
Hello, this is The Web Project Guide podcast and this is episode 24, Maintain and Improve. I'm Corey Vilhauer, Director of Strategy at Blend Interactive and co-author of The Web Project Guide. Later, we'll be joined by David Hobbs, author of Website Product Management, Keeping Focused During Change. But first I'm joined by my cohost, Deane Barker. Hi, Deane.

Hi, Corey. You said episode 24?

That's it, yeah. I did say episode 24.

And we have 24 chapters.

Yeah.

What does that mean, Corey?

Well, it means we have three more episodes, one for the foreword and one for the introduction and one for the conclusion.

What about the index? We're going to read the index?

We're going to read the index in order.

This is it, chapter 24.

That's it, yeah.

We have called in all of our favors to all of our friends. We have no friends left that's why we have to end the podcast. Nobody.

No friends left.

Wants to talk to us anymore. But hey, today we're going to talk to a guy I have known for a number of years, David Hobbs, based in DC. And David is well-known for helping organizations on large-scale digital transformations. And the thing about David is that he doesn't concentrate just on the super glamorous part like in the actual build. In fact, I don't think David actually does implementations and builds himself. David concentrates on the super boring parts, which is how are you going to actually make this work going forward on Day 2? And so that can be a unique space. What would you call that, Corey? I would call that web operations or governance?

I think so, which is what we talked about last month. A few weeks back, I guess. Yeah, and it's interesting because it is a part that I don't really have a lot of experience in because we very rarely are working with at least the content teams or the design teams after a site launched. We are... Blend's a web firm. Once the site is launched, it is somebody else's product at that point with the exception of potentially helping them out with some dev fixes or new features. And so I'm always interested to hear how people are putting together the people that go into maintaining this. It's almost like maintaining a website is a full-time job that somebody should just be dedicated to doing.

So just the people, but it's the rules. How do you set guidelines and rules around how you're going to manage this thing going forward? My son just got married. Got married in June. And he had a wonderful romance with his now wife and now they're married and this is the first time that they've lived together. And suddenly they are running into fascinating things like who unloads the dishwasher and who makes the bed and actually-

How do you load the dishwasher?

How do we actually live together as a couple, whereas I would say for many couples, the relationship stage is artificial and temporary. And then I have now been married for 24 years and I can tell you that 24 years of marriage is very, very different than the 15 months we spent in a relationship because you run into very, very pedestrian concerns like who's going to take the garbage out and how are you going to discipline the children and how much money does something have to cost before you need to check with your spouse, things like that. And so this is an important topic and it's probably not a really glamorous one, but it's one that people don't think about enough and I think sinks a lot of projects over time. They don't go down in flames during the development but they slowly wither away into irrelevancy over time because this stuff wasn't handled.

Yeah. This is the final stage of our ongoing architecture and home ownership metaphor in which you need to keep your house up. Otherwise, you are not going to resell it and it will not... The houses degrade over time. Nature wants its space back and it's going to try to take your house down whenever it can.

We have beaten that metaphor to death, haven't we?

There's nothing left to beat. So yeah, let's maybe go on to our guest then. David Hobbs is a digital transformation consultant who helps organizations make big digital changes. And he's also author of two books, which is kind of being a show-off. Well, not to you Deane, I suppose, but to me. Website Product Management and The Website Migration Handbook. But first, The Web Project I podcast is sponsored by Blend Interactive, a web strategy design and development shop dedicated to guiding teams through complicated web and content projects. Blend has been building great websites for over 18 years and we're always looking for our next partnership. So visit us at blendinteractive.com.

(05:07)
All right, let's welcome our guest, our final guest, David Hobbs. Hey, David. How are you doing?

Hi. Thanks a lot for having me.

So interesting note here. Normally, when we're doing these guests, it's people that we know but maybe haven't seen in a while. David and I had breakfast three days ago in Washington, DC. I was in Washington, DC for Content Marketing World and I called up David and said, "Do you want to get together?" And we have now, we've established a tradition. There's a bookstore called Kramer Books and it has a little cafe attached and some of the best breakfast I've ever had in my life, but that's now our official tradition too.

(05:47)
So David, you're bringing up the rear on this. Chapter 24, this is the end. We've launched our website. We're good to go. It's been very glamorous, very exciting. Great things have been happening. It's been like the sexiest, glamorous process in the world, and now we've launched and it's the day after launch, David. Why does this not feel as glamorous as it used to on Day 2?

Yeah. Well, I often think of the website as even when you're planning on launching a new site or relaunching or redesigning or whatever is to think about its birth and after even before you start working on it. So a lot of what I do is actually thinking, working with the customers on designing how are they going to maintain it over time? I actually think it's something that if you're just thinking about on Day 2, then you are probably going to have problems because a lot of it is how did you structure the site? Did you also implement the publishing system so that it makes it easy to do the right thing? Did you implement the site templates so that you can optimize broadly over time instead of doing it on a one-off by one-off side?

(07:03)
So I think a lot of people when they are at Day 2, they just haven't thought about managing the site over time, haven't thought about why is it that we had to do the redesign. Sometimes it's because of a technical reason that necessitated the change, but sometimes it's because there were internal process problems that exploded the site or created all these microsites or something. And if you haven't thought of that before you design and then implement your site, Day 2 is going to be hard. It's going to be hard to just all of a sudden dive in and say, "Okay. Now, how are we going to maintain it?"

Okay. So Day 2 is not the time to do this planning, so let's back up. Is the time to do this planning during the development process or is the time to do this planning before we even start to plan the new website? How far back do we need to go?

I think before now, I'm a big fan of organizations first lining up what they want to do before they even send out the RFP or whatever for web shops to do the work so that they're clear. Now, of course, you don't totally define a site early on but you first can decide, well, broadly speaking, we know we need to publish a lot of articles. And that's been a problem to date and how we've been publishing them. It's been difficult to do so we have to do all of these hacks and therefore it's like, "Well, we know that we need that to be streamlined," for example. And so when you go out to the RFP, you're already thinking, "Well, we know these are the kinds of things we need to do over time."

(08:40)
Also, I think that in an RFP, when I'm involved in an RFP, I also make sure that the organization is even put in for the vendors that are implementing to suggest how they're going to maintain it. So the different relationships after launch, of course, but still to be thinking about that beforehand so that you're also not caught off guard from a budget perspective. If you haven't thought about this and you say, "We have this much money," and you put all the money to implementation, and let's say you don't have the internal resources to do the maintenance over time, well, now you're screwed because you don't even have the resources to do, let's say, the more technical things over time.

(09:28)
So I think that the time to be thinking about maintenance is very early. And of course throughout the design phase and implementation phase, you're constantly making priority decisions. Realities come up that you weren't anticipating. You have to cut things or whatever. And I would argue that that's also an important time to make the right decisions for maintenance as well.

David, I don't know if you know this but we wrote a book and it's called The Web Project Guide. You wrote a book called Web Product Management, and what I want to know is tell us what you mean when you say after launch that a website has moved into becoming a product. What do you mean by product in that sense?

Broadly speaking, when I'm thinking about a digital presence needing to be treated like a product, I'm thinking about maintaining it for high quality over time. And a lot of what that ends up meaning is when you're making changes to be business first, so prioritizing based on what the business needs and to think broadly and long-term. And a lot of where the rubber hits the road is actually in features because that's an amplifier. And when you spend money on your site by implementing a feature, especially in the publishing process or maybe in the front end. It's this amplifier. It's not just you're paying for the one thing.

(10:57)
So one of the main aspects of product management that comes out in practice is managing features. Instead of putting band-aids on things, figuring out how to change the machinery so it works better over time. So again, project versus product is project is we've got to get this scope done in this budget in this time. And of course you pick only two and all that stuff. But still it's those things that you're controlling. Whereas in product, you're managing more over time. But I would argue that a lot of thinking about the product again is early. So it's like way before that Day 1, Day 2, you're already thinking, "Well, we want it to do these things. We want it to do these things well. These things are higher priority than these other things." We need to make sure that we implement things so that things that should be streamlined are streamlined and that you're thinking too that we know we're going to be changing over time.

What about the triage of inbound requests? You get a ton of inbound requests. "We want to do this to the website. We want to do this to the website." Can you speak is there some kind of logic in how to manage these? Because you want to keep everybody happy and it's probably not the best thing for the website to just do what the highest paid person asks you to do. Is there a triage process you recommend?

Yeah, definitely. And I've got a little generic workflow that folks can download, but I see it as getting back to this idea of what should be streamlined. One of the most, the highest leverage things you can do in this type of process is when you see a lot of the same kind of requests coming in instead of, for instance, it may be a lot of people come in and say, "We need this new feature." And you start saying, "Oh, I'm going to allow you to put in whatever JavaScript you want so you can put in whatever charting you need or whatever." That's one possible approach. So if you're used to saying no a lot and you're getting hammered for saying no, you might want to be the good guy and say, "Okay, we're going to open up the floodgates and you can put in JavaScript." But really you've created a problem because now if you want to optimize over time as an organization, change how sharks work or whatever, then that's a problem.

(13:23)
So the reason to go through all that is that I think that one of the key things to do when you're looking at requests coming in is to be thinking, "As a business, do we need to streamline something? Are these a bunch of one-offs that we're dealing with? Or really, can we reframe this as something that we needed as a business?" And if you can reframe it that way, then what you do is instead of just making it so these 10 pages can have the charting they need, you can think, "Wow. Yeah, we are an organization that needs to present data better and let's think about how we need to present data in let's say articles or whatever." And so then you end up shifting the conversations more where you instead of like, "Hey, I want to look good. We want to show how many tickets we've closed," or whatever and then you start just responding quickly and thinking you're doing a good job when really you're kind of destroying the quality of the digital presence, that you're trying to shift more to how should the machinery change?

(14:29)
So back to your question, that was a preamble that I think is an important part of how this works. When requests come in, the way I look at it is if something already is streamlined and it meets what I think of as the entrance conditions. Let's say you do a lot of conferences. An organization does a lot of conferences and so you've over time realized, "Man, we have to have a way that really deals with the conference lifecycle in a useful way and automatically points to the latest version of the conference," and you've implemented all this stuff, well, if a new conference request comes in, it's like you already have an SLA on it. "We've already implemented it so we can give that to you in a week if you provide these things. But then the entrance conditions would be like it has to actually be a conference. You're not just using this template because you like the way it looks, and really you're going to put up a board game site or something, some arbitrary thing."

(15:23)
So then when a request comes, if it meets the streamlined requests, needs, then you just follow the normal processes. And then if it's a massive issue, of course you deal with it. Site's down. No analytics are being sent. Something drastic, you deal with it. But then otherwise, I recommend going into a quarterly hopper of what you're considering what to do. That gives you the time to reflect. So if it hasn't already been streamlined, you don't just knee-jerk say, "Oh yeah, sure. We'll put in this hack. You can do a microsite," whatever. Instead of doing that to feel like you're responding to people but eroding things, you put it in this hopper and you're not saying to anybody whether it'll happen or not but you just know that everyone knows the process that's going to be followed. So then when you're looking at it quarterly, you're looking at it through multiple lenses and you're saying, "Is this a technical infrastructure just needed?" We've got to upgrade to the next version or something. And then you look at is it really responding to a business need, et cetera.

(16:42)
I ran into a situation when I was at the World Bank, for example, using a process like this. Well, before I had a process like this I should say, and we had said, "Look, it needs to be an institutional priority before we're going to make a functionality change." And so people would just start saying," Hey, this is an institutional priority," but we didn't have all of the processes in place to combat that. It was just like my word versus this person's word even though anybody that walked in the room would know it's not an institutional priority. It's just something people wanted. So then we moved to voting and all these other things.

(17:17)
At different organizations you might need different kind of levels of how you support this, but broadly it's if it's streamlined already and it's a legitimate streamlined request, you do it. If it's an emergency, deal with it. If it's not one of those, put it in the hopper and then look at business needs, technical needs, and different things to decide what to do.

Your comments about streamlining were interesting because I think there's a constant tension when a request comes in. Is this a one-off request or is this something like we just didn't account for that we should have and people are going to want to do this again and again. And it's tricky when those dribble in because you get the first one, you're like, "Okay, we'll just hack our way around this." Then the second one, you're like, "Well, this is still a one-off." And then the third one's a pattern and you're like, "Holy cow, they're going to ask us to do this over and over again." And that's the point where I think you need to step back and say, "This is maybe a usage pattern we didn't account for."

(18:13)
The other thing I heard you say there is that the gist I was getting was that you need to actively defend your project. And to do that, I feel like you need to make sure that you have somebody up the org chart that's willing to help you wield a big stick.

Yeah, I think there's that. But then I also do think that there's a little bit of building trust amongst folks too. So I agree with that, but I don't think that's all it is. So for example, at the World Bank where actually this report had come out that slammed what I had been doing, actually, because it had said, "Hey, we're giving undue priority to people that are louder," et cetera.

(19:05)
And so then we came up with this process. But at the beginning of the process, people were very skeptical. So the first time we came out with the work program, everybody's contesting this, that, and the other, and you really have to stand up and take some arrows. But then over time people start seeing like, "Okay. I can see that my request didn't happen, but there's a legitimate process happening here. I could see that sometimes my stuff happens but then sometimes the other group stuff, I could see how different groups wanted things."

(19:38)
So anyway, I think that there's definitely a little bit of the top down for sure but I don't think that's enough. I think also there's that building trust that people see that it works. And I also do think that part of it too is how you architect the systems, the technical systems too. I don't think it's... This isn't just a people process either. It's when we're even building the site in the first place, what are the things that... How does this need to work?

(20:12)
And so for really a big digital presence is I'm a big fan of introducing the concept of site types. So again, these other models so that you're rising above any specific request. Somebody can't say, "Well, because we are this specific site, we need whatever." You can say, well, actually you are a disease or condition site and we do know some things about how that should be done.

You were talking there about building trust. Let's reverse that for a second. What's the most efficient and effective way a web management team can destroy the trust of the organization?

I think one thing is not doing what they say they're going to do. That's a big one where you're trying to be nice and come up with these plans but you can't execute on them. And then you hit that tipping point where all of a sudden you say, "Oh my gosh. Yeah, I'll open up JavaScript. That's something I can do." It might be that you totally screwed up the implementation and whatever, but it's like, "Oh, I can do that." So I think that one thing is not delivering on what you say you're going to deliver. And I think this is really hard when you get into a situation where the system doesn't match really what the organization needs. It really does need a redesign, but you're not at that step, stage. That's a hard time. But anyway, I think that that's a big one.

(21:37)
And I think that also once you give in too much to the one-off kind of request in general, because what happens is it's like the fastest way to being inflexible and what you can implement is being too flexible. So if you start letting... If everybody starts asking for things and you just give it to them, give it to them, give it to them, all of a sudden you've created this complete mess that you can't maintain. Or more accurately, maybe you can maintain elements but you can no longer make broad changes that are good for everybody because now you've got, "This team wanted this so we implemented that thing like that. This team wanted that, we've implemented this." So you've been "flexible" but now you can't do anything. Now you can't make any big changes. You can't make things streamlined anymore because everybody has their own things. So you can't make it so it's universally faster to put up the conference sites or whatever.

I think there's a big difference between somebody who is helping pull together a project within as a part of an internal team, somebody who is part of an internal dev team and they've got this project or this specific feature they want to push out, and somebody who's more along the lines of what Deane and I are familiar with, which is an outside vendor is coming in and they are creating a new site for you and now it's yours. Talk through a little bit of what an organization might need to know as they move from an external vendor to taking on this product even, especially since they may have only been involved really with feedback up until that point.

There are different elements of maintaining the site. There's still there's the content production. There's the technical side of things. And I do think it's really important to be thinking and talking about that even when engaging or considering engaging with vendors so it isn't a surprise. But I will say yeah, that handoff part time is hard. I definitely have... I'm very concerned about that for clients, and that's something that I take seriously. And when I'm helping organizations pick vendors and stuff, it's a big part of it.

(24:02)
But still it can fall apart. It is really challenging. I think that I know also coming from working at a web shop before, I know that the management side is also hard for the web shop. So it is definitely this hard thing. I think that the biggest element for me is one, thinking through in advance, do we have the budget part? Can we take it on? Because there's certainly some organizations that do have the tech resources. They just can't. They're not specialists in whatever that technology is and so you contract that out. But then they know they can take it again. I think the hardest part is the organizations or the hardest situation is organizations that don't have, they know in advance that they can't really manage it totally technically after the fact. And so you might try to set something up, but sometimes it falls to pieces. The organization might offshore it and then all of a sudden there's all sorts of additional complexities in that.

(25:14)
So I think that that's the hardest one I don't have the best answer for because even really carefully trying to control for that, that still is a tricky time. That handoff time is definitely tricky. I think that the biggest thing is to try to plan in advance for it and try to leave budget for it. So even if you do have to change vendors or bring in different resources, that you still have budget to do that. So it's not just this big surprise at the end. But I highly recommend thinking about that in advance. It's still hard but try to have budget for it.

When somebody takes on this new product, they're more likely to be excited about, "Here's all the things we can do with it. Here are the enhancements we might add. Here's what we're going to do in phase 2." But in reality, a certain percentage of that excitement and time ends up just going to ongoing maintenance of the site, upgrades, bug fixes, things like that. Is there a good balance between... How do you prepare people to understand that, "Hey, all the cool stuff you want to do later, you're still going to have to just do all this maintenance stuff and helping them balance that"?

Yeah, I think that's important. I think that one thing that's useful is to think what are your threshold? What are your baseline needs? So for example, with one customer recently, one of the points that I made is so it was a strategy thing that yes, you need the key engagement funnels to be fast upon launch. But if they ever are not fast for any reason, technical, whatever, whatever, at any time you need to respond to that quickly. That is so important. But it's easy to overlook because you can miss the forest for the trees so these engagement funnels of signing up for membership and stuff like that is really important. So anyway, I think that part of it is the prioritization process and hopefully folks can get that nailed down. It's not really about a percentage thing but it's more like if ever it takes one more step or things slow down like one second for this, that becomes the priority. Forget everything else.

(27:44)
Another thing that I would point out is that I think that it's really important to never plan far in advance once you're launched. And this gets to Deane, what you were saying of when trust erodes is if you come up, this backlog during launch happened, happened, happened, and then all of a sudden you've got this huge thing and you've said, "Okay, for the next year we're going to do all these things," you've totally screwed yourself right out of the gate. Because new things come up, you don't have time. The budget gets crunched, you can't deliver on it. So I definitely recommend you have this hopper of what could get done, and there may be some major things that you do need to plan. But I think that that's another thing that people really get caught up in is too much planning for what that phase 2 should be and then it doesn't even leave room for the maintenance.

(28:35)
So it's like you've got to be more fluid and say, "We know this is a complex thing that's happening. We know that these things are the priorities. And we know that the budget might change. So we're going to have a hopper and every quarter go through and come up with what's best next." So I think that helps a lot with that maintenance versus enhancement thing, to be set up to be more fluid and to give yourself space so that you don't feel like because the request comes in, you have to decide immediately. It's like well, if it's not already streamlined, you're not going to do it. You're going to wait. And then you've got time to reflect on it. So yeah.

David, you've got two books. Tell me about them.

Website Migration Handbook is about migrating content, and so that's about includes things like setting a good vision and how to transform content, et cetera. And then Website Product Management is about the kind of things we've been talking about on this call.

Well, how can I get them is what I'm trying to say.

Oh, okay.

I'm trying to let you sell stuff.

Yeah. Amazon is where you can get Website Product Management. And then actually Website Migration Handbook is now totally free on my website on David Hobbs Consulting.

I appreciate you jumping on here for our last episode regarding the book, at least. And maybe sometime when I'm in DC. I'll get to go to-

Sure.

... lunch with you and go to a museum.

I feel like we should toast something to our last episode. I will note that right after David and I had breakfast, I was walking back to my hotel and I was passed by some type of motorcade, which I thought was very fitting that they would escort me back to my hotel like that. But I don't know if it was presidential motorcade or what, but DC is such an exciting town.

Yeah, awesome. Well, thanks David.

Thanks a lot.

Thanks, David.

Deane, it was great to talk to David Hobbs. Again, for you, again.

I know. I just talked to him three days ago. We had this place that we go to breakfast. We ate there about two years ago and I remember telling him at the time, it's the best breakfast I've ever had in my life until Friday where I had now the best breakfast I've ever had in my life. It's a little cafe attached to Kramer Books in the Dunlop Circle, Dunlap Circle area of Washington, DC. And it was wonderful. And as I took the Secret Service Center motorcade to escort me back to my hotel, which was very, very nice. DC is a full-service city. I do love Washington, DC. It's one of my favorite places in the whole world, and I had a great time out there.

(31:16)
David, talking about very, very important things. And I feel like it comes back to the reoccurring theme throughout our entire series, has been a lot of this comes back to human factors. And I think I feel like David now is running headlong into the humanest of human factors. How do you balance competing priorities which is never easy?

Yeah. I remember when we were writing this and I was always concerned about what things went into the 1st chapter and what things went into the 24th chapter because there is enough overlap really enough in the two around planning and understanding people and knowing what's going to happen versus actually acting on what is happening. So I suppose this is probably the point where we're supposed to look back at the 24 episodes that we've recorded so far regarding the book. I don't want to. I don't have anything to say about it that we haven't already spent literally almost 20 full hours nonstop talking about.

Yeah. I would like to thank all of our friends that came along for this trip. Corey and I called in pretty much all the favors that we have and we managed to assemble what I think is a star-studded cast of people for this podcast. And I love talking to them all. And they're all great friends in the industry that I will see again. And so hopefully they've enjoyed their time enough that they're still willing to talk to me when I run into them. But time will tell.

Yeah, we'll see. All right. Well, that wraps it up for us. Thanks to our guest, David Hobbs. Again, his book, his Website Product Management, Keeping Focused During Change, you can order that on Amazon or you can learn more about David at his site, David Hobbs with two Bs, Consulting, davidhobbsconsulting.com is the website there.

(33:05)
The Web Project Guide is a product of Blend Interactive, a web strategy design and development shop that builds websites and guides teams through complicated web and content problems, from content strategy, design, CMS implementation, et cetera. We're dedicated to making great things for the web. And this is one of those things. This is episode 24 of The Web Project Guide, which also corresponds with chapter 24 and the last chapter of the book Maintain and Improve. You can read the full text of this chapter at webprojectguide/maintain.

(33:32)
And again, this is the last episode but technically we didn't cover everything. There's an intro. There's conclusion. You can catch that on the site. Or there's also an exclusive foreword from our friends and former guests, Karen McGrain and Jeff Eaton. That's only available in the print version or the digital version and you can get those at order.webproject.guide, either physical or digital. Read the book on Amazon. Rate the podcast in pod catcher. Thanks for sticking with us through all 24 chapters. We're actually going to take a break for the next few months and at least see what and if what we come back with, we're going to figure out who we're going to talk with and what the topics might be and what happens after this. So we'll talk at you as soon as we can. And until then, go do amazing things

And as always, good luck.