Corey Vilhauer & Deane Barker - The Web Project Guide
Corey Vilhauer is the Director of Strategy at Blend Interactive, and Deane Barker is the Senior Director of Content Management Strategy at Optimizely. They are authors of The Web Project Guide and hosts of a podcast that dives deeper into specific aspects of the web project process.
In this episode, we discuss the multifaceted nature of a web project. Corey and Deane first tell us the origins of their book and their podcast, after which we tackle some of the key factors impacting the web project process, from the overall complexity of the web, the importance of content strategy and client relationships, to agility and the placement of the web project into a broader digital context.
Links & mentions:
“And that’s the thing about business – just because you change how you do something, doesn’t mean it was wrong, it just means the circumstances have changed. And so that’s when we talk about agility. You need to make sure the organization can change, and if it does change, it doesn’t mean that it was wrong before. It’s just, circumstances have changed and you need to adapt with it.”
Welcome to the Agile Digital Transformation podcast, where we explore different aspects of digital transformation and digital experience with your host Tim Butara, content and community manager at Agiledrop.
Tim Butara: Hello everyone, thanks for tuning in. We have a bit of a special episode for you today. It’s actually the first time on the show that I’m joined by not one, but two guests – Corey Vilhauer and Deane Barker, the authors of The Web Project Guide book and hosts of a podcast with the same name. Corey is the Director of Strategy at Blend Interactive and Deane is the Senior Director of Content Management Strategy at Optimizely.
We’ll be discussing the multifaceted nature of a successful web project and Corey and Deane will be sharing insights from their book, as well as from all the conversations that they’ve been having on their podcast. So, welcome Corey, welcome Deane. Anything to add before we jump into the meat of it?
Deane Barker: You know I think what might be some important context to add is that I was a founding partner in Blend Interactive, the company that Corey works for, and I worked with Corey there for 10 years, 11 years?
Corey Vilhauer: I think so.
Deane Barker: And I left there to join Optimizely. When we started this book, Corey and I were working at the same company. And in between starting this book and finishing this book, I left that company and went to work for Optimizely. But Corey and I were coworkers for a decade, and we did these projects together for a decade.
Corey Vilhauer: Deane hired me, actually.
Deane Barker: I hired Corey over some very bad chicken wings. They were terrible.
Tim Butara: Awesome. I’d love to hear that story another time, in a more informal setting. But first, you definitely have a unique perspective, kind of having worked together on this when you started, and then worked at different companies once you finished it. And I’m sure that that will come into play as we go through the questions. But, can we first, before we dive into the specific insights from the podcast or the book, can you just tell us a bit more generally, a few words about the podcast and the book that the podcast is based on?
Deane Barker: So, the book got its start in the parking lot of a cheesecake factory in Omaha. I was returning from taking my daughters to a volleyball tournament and I just got to thinking – everybody sleeps when I drive, my whole family goes to sleep – and I was awake and I was thinking that Blend was a services company and we had no really written description of our process. And I handled the sales at Blend. And people would constantly ask me, can you walk me through the process? And I built this kind of rapport over a phone call of explaining what we did, and I thought, you know what, I should write that down.
And so I sat in the parking lot of a cheesecake factory and my family was inside waiting for a table. And I wrote down, I think 26 steps that we go through. It was pretty rough. And then I turned it over to Corey, Corey was our head of strategy, and I said, can we flesh this out to some kind of marketing piece? And Corey did so, he took all of those steps I put together and he grouped them into logical groups or sections, and then we wrote two or three sentences for each one. And we used that as a marketing tool at Blend, we would send it to people and say, this is what we do.
And then I got to looking at it – I was spending a lot of time in Europe in 2018, I think – and I got to looking at it, I thought, I wonder if I could flesh this out to a book? I had written one book already by that point, I wrote the O’Reilly book about web content management back in 2016.
And I took one chapter and I kind of fleshed it out and made it chapter length, and I thought, ok, well, this went pretty well. And then I did one more chapter, and then I started looking at the totality of it and I realized I was not the guy to write half of this. Cause half of it was about content strategy and UX and user research, specifically what Corey does. And so I pulled Corey into my office, and I don’t believe I threatened him, but I offered him the opportunity to write a book with me, and Corey ended up writing more of the book than I did. So, does that match with your recollection, Corey?
Corey Vilhauer: Yeah, it was exactly like that. It took us a while, it was an interesting project because we actually released the chapters for free – and they’re all still for free – but we released them two at a time on the Web Project Guide website. We looked at this purely as an educational project. I think what I used to run into a lot, and I still do, is that people need help understanding both the scope and also the context of what goes into a web project.
So I always tell people, this book doesn’t really help you know how to make a website, but it helps you know how a website is made. It kind of sprouts up from this question that clients would have, which is like, ok, we’re done with this, now what do we do? Or like, they’re bombarded by deliverables and deadlines and all these different tasks, and this kind of helped us show, here’s how all these things fit together. So, when you’re done with this, there’s a good chance that this will happen; or we’re doing this because of this.
And it was a lot of fun. I learned an awful lot just from reading Deane’s technical stuff, and it was interesting to have to try to take our two voices and smoosh them together for the final round of what this book ended up being. So yeah, it was weird to me that there wasn’t a version of this book out there already, honestly. It’s kind of how it went. It seems like a really simple concept.
Deane Barker: Corey alluded to something that was really interesting at the end. When we were done, we didn’t actually have a book. We had 12 sets of two chapters written by two different people. And we went through this, we called it collaborative edit. So whenever we were done with a chapter, the one who wrote that chapter would give it to the other one to edit. What did we call it, objections?
Corey Vilhauer: We called it the opposing edit.
Deane Barker: The opposing edit. So, Corey would write a chapter and I would get the opposing edit. And then I would put some changes in the sidebars – we wrote the text of every chapter, it’s collaborative, not indicating which one of us had written it, but then the opposing edit would be the other person would write their thoughts. And then we had little sidebars, call out sidebars with their little heads that were in our voice, and so the other person would add sidebars to that. But Corey wrote the first 12 or the first 13 chapters?
Corey Vilhauer: I think so.
Deane Barker: No, 13 or the first 14. I know you wrote one chapter more than I did. But we went back and forth like this, and then at the end– we had released them all online, and at the end we took these 24 – we started with 26 and we realized there was some overlap and we ended up at 24 – and we had to make them make sense.
We had some situations where we were referring to prior things that we’d edited out, and we had to go back through and make this thing to one cohesive whole. So at the end Corey and I did this big collaborative editing process, so, getting two voices to sound vaguely cooperative was tricky. Corey and I argue a lot, so, that was easy. But getting us to sound like we weren’t having an argument was a little more difficult.
Tim Butara: But then when you moved to the podcast, it was ok for you to argue again on the show.
Corey Vilhauer: That’s the point, I think. The podcast was sort of a natural progression from the book, because– listen, Deane and I were experts on maybe one very small piece of this entire thing. But really we’re kind of like riding the shoulders of a lot of different experts. And the podcast made a lot of sense because we can actually reach out to those experts now.
We wrote a really high-level view to connect everything, but not to dive deep. Because there’s other people who have done that already. There’s already an information architecture book, there’s already a hundred thousand development books. Our goal was to connect all of those, and now the podcast is, now we’re gonna reach out to somebody who wrote a book on information architecture. We’re gonna reach out to an expert on research. Eventually we’ll get into the more technical chapters here soon. And so it kind of became this sort of natural progression which has been a lot more fun, I actually really enjoy doing the podcast because Deane and I have a pretty good, I don’t know, rapport.
Deane Barker: When somebody starts researching the web development process, it’s very very easy to go deep on one particular thing. But it’s much harder to get the big picture, right. We kind of look at our book as the glue that holds all the pieces together. And what we hope is that– here was the goal. This was the theory. And I’m gonna go back to the parking lot at the cheesecake factory in Omaha, Nebraska.
I actually researched, I sat in that parking lot and I researched the average reading speed of a college-educated American. And it’s 350 words a minute. And so I thought, you know what, I wanna write something that a person that is facing down a web project, can read one chapter every workday in ten minutes, and then at the end of the month, have the big picture. And so 10 times 350 was 3500 words. So that was the original goal, is that each chapter was gonna be 3500 words, maybe a ten minute read. We went way past it. I don’t think any one chapter came under 3500 words, I know one of them is 7000 words.
But that was the original goal, was that we were gonna be the kind of glue that fit the whole thing together, and our dream is that a project manager or someone in marketing that had been tasked with a project like this could read our book 10 minutes at a time for a month, and then go deep on the parts that interested them or they thought were gonna be challenging. But we wanted them to get the big picture, see the lay of the land, and then decide, ok, I need more information on this, this and this.
We originally, at the end of every chapter, we originally included a resources section, we included links to articles and books that would go more into depth on that particular thing. And for some reason, and maybe Corey can remember, we stopped doing that, but I’ve always kind of hoped we would revisit that, because I would love to, at the end of a chapter, have someone be able to see where to go. Now, obviously, we’re not gonna republish the book, and it’s harder to do in a book, because it’s not clickable, but there is a website, and the entire book is published online, so it’d be easier to do there.
Corey Vilhauer: Yeah, that’s the resource slot. In the physical book, it’s just that, they’d be outdated after a while, different versions, and books kind of fall on and fall off. But they’re still there on the site, so if you get done reading, you know, a chapter on front-end development, there is a list of resources where you can go find the big names, your Ethan Marcottes and your Mat Marquis and all those people who have done a lot of really good front-end work.
Tim Butara: Ok, so now that we’ve introduced the book and the podcast and your work on it more thoroughly, we can actually start talking about the web project process itself. And I want to start by asking you, and maybe Deane, since you’re the one who works more in sales, more with clients, as opposed to Corey, you work more in content and UX and stuff like that, maybe Deane will be the right person to answer this. So, what are the most important preliminary considerations for kicking off a web project successfully?
Deane Barker: This is gonna sound like a totally cliché answer, and I’m sorry, I wish I had something that seemed less cliché – but you have to understand what the point is, what the goal is. And in particular, you need to understand, do you have an online conversion, is your website gonna host a conversion. The pure definition of conversion is when somebody converts from a prospect to a customer, but in general, conversion has come to mean when I take some action on your website which is the end goal of the website.
And if we take e-commerce for an example. The end goal of e-commerce is somebody checks out and gives you money. That’s the entire point of the website. But with other websites it gets harder. The classic example I use is, let’s say you own a company that builds interstate highway. Well, no one’s gonna put a hundred miles of interstate highway in their shopping cart and check out, that’s just not a thing. Like, what is the conversion to that?
And if you are in marketing for this customer– and this isn’t theoretical. I had a long talk with a customer once who was head of marketing for a construction company that built massive stadiums, for like NFL football teams. What’s the conversion there? No one puts a stadium in their shopping cart and checks out.
Additionally, the initiation of the process of finding a company to build your stadium doesn’t really happen online. If you need to build an NFL stadium or a major league soccer stadium or a premier league stadium, you’re not gonna google who builds stadiums, it’s not a thing you’re gonna do. The way that the customer is going to be introduced to your organization is gonna be very very relational, there’s a small group of companies that do this thing. So, they’re not gonna find you online; so, really, what is the purpose of your website, what is the conversion?
And honestly, if you take that not to a sort of extreme, the point of a website in that situation is for that customer to come there and look around and think that, yeah, you know you’re doing, and this is a company that’s qualified to do this, and six months down the line, when the city’s municipal council is voting on which contractor is gonna build the stadium, they kind of remember your website and say, oh yeah, they had those case studies of that thing.
And that’s really it, there’s no conversion there. And that is an entirely different situation than, say, e-commerce. And understanding the end goal of your website, like what is the conversion point? Do you want them to fill out a form? Do you want them to just learn your organization? Is it just social education? Do you want to share this on social media? You have to know what the goal is. So before you start a project, you need to sit down and map out a positive interaction with my website, a conversion. The moment when my website has done what I intend for it to do looks like. And if you can do that, you are way way better off.
Corey Vilhauer: I think, what you’re doing when you set those things up, and this I think is a thing that gets overlooked a lot at the start of a project, is you’re also setting expectations for the project in general, being able to go in there and say, hey, this is what we think it’s gonna do.
So if somebody from a different department or a manager who isn’t really paying attention to things, they may come in there and have very very wild expectations on what the site will do, and being able to have that project charter that Deane’s talking about, to be able to say, this is what everything is and this is what we’re planning to do with it in a realistic format within the specific budget and within the specific timeline, having those expectations out there makes it a lot more positive of a project.
Deane Barker: That also prevents other people from co-opting the process. In fact I included this anecdote in the book, but we had a customer, it was a government agency in Canada, where we worked with them on strategy and we laid for them exactly what the purpose of their website was. And they used that document as a weapon, as a defensive weapon, to ward off people in the organization that wanted to do dumb things to the website.
They would come in and say, oh, we’re gonna have the website do this. And then this company would pull out this document that we wrote and say, nope, that’s not the plan, this was the plan, this is what we’re doing, if it’s not in the plan, we’re not doing it. And so it allows you to kind of focus that and prevent wasting effort on things that aren’t gonna help your organization.
Tim Butara: I think we’ll return to some similar examples a little bit later. But I wanted to say that, obviously, one big factor is also the complexity of the web. We’ve seen it become more and more complex, and the digital experience in general becoming more and more complex. It requires both a diverse range of knowledge and a diverse skill set to create experiences for the web, as well as to navigate experiences on the web.
And, maybe, Corey, you’ll be able to answer this really well because you’re more into UX and stuff like that; how does all of this, how does the complexity of the web, the complexity and the changing habits in how users navigate it, how does this factor into the entire web project process?
Corey Vilhauer: The hardest part about building a web experience, the hardest part about building a website, the hardest part about taking all of these things and integrating them within the systems that are already in place within your organization, the hardest part is finding the people who can do the really good work, the really deep work, who can do something at a level that does allow for that complexity, but also can work with a group that might have a really high-level overview of it.
Web projects require a really interesting balance of deep thinking and high-level understanding. And the good projects have somebody who sort of understands the different disciplines, but also kind of trusts them to take care of it. Somebody who can roll in and say, listen, we need to spend a lot of time doing some level of user journey work to figure out how somebody is getting from our mobile ad through to the final conversion, but also knows enough to let those people do that work. So when it comes to the overall project and the complexities that come into it, that’s where we see the biggest benefit. Can you find and hire people who will be able to sort of both complement and dive deep into their individual areas of expertise?
Tim Butara: And I guess the web is so ubiquitous that it’s probably more so than ever before, it’s the case that the people who are creating these experiences are also the people using the same or similar experiences. So in a way, the person creating an experience is very often the user of that same experience, or a very similar experience. And I guess that kind of alleviates a little bit of the complexity and of the abundance of everything.
Corey Vilhauer: Some of that complexity does come in when you have to then translate that knowledge that you have into something that the end user or something that a client or something that somebody from another department has to then understand. There’s also both the here’s how we’re going to do this, and it’s under this veil of expertise. We moved some boxes around and we interviewed some people, and now ta-da, we’ve got a user journey map. But there’s also being able to translate that user journey map into something that everyone understands so that they trust that user journey map, so that they trust the process they’ve just gone through.
Tim Butara: This is a good segue, actually, into my next question, which I guess will be a little bit more relevant for Deane, but I’d love to hear both of your opinions. So, we just talked about helping bring others on board and helping them understand the thing that you’re working on. So, how should companies and agencies approach bringing their clients on board and guiding them most effectively throughout this entire process? What should the main considerations be here?
Deane Barker: It’s hard to talk about this without sounding negative. And, again, I go back to – make sure, help them understand their goals. Make sure that they understand their goals. Cause a lot of people, when they come to agencies, they think the agency does handweaving magic – there’s something magic happens and our business gets better.
No – you need to tell us how your business is gonna get better and how we can get you there. If an organization comes to me that builds interstate highway – I don’t know anything about building interstate highway. They do. It’s my job to harness their domain knowledge and their business knowledge and turn it into some kind of actionable plan. You need to explain to the agency– there are some agencies that specialize, highly specialize in a particular vertical. But even then, they don’t know the idiosyncrasies of your particular business.
So, you need to set the customer’s expectation – and this is the part where it sounds negative – you need to set their expectation. Because they will come to you and they believe that you’re magic, they believe that you’re a wizard that does amazing things and makes everything all work out. And we don’t, we’re a force multiplier. Agencies help multiply your knowledge and apply it in a different angle to achieve a goal digitally.
So, managing expectations and breaking the veil of magic, that this is just a very practical thing and I have just a different specialized set of knowledge than you do, and I’m gonna focus your domain knowledge on a particular problem – that sounds so less glamorous. Like, you’re not gonna sell any services that way, and so the people doing sales for services company tend to concentrate on the magic, and then you bring them back down to earth when the project starts. You’re like, ok, there’s no magic, this is kind of how we do this. That sounds cynical, I don’t mean it to.
Corey Vilhauer: Deane, it’s a language thing. I mean, it’s all about, some of the bigger sticking points are that there’s language and definitions that define specific industries, just like anything. If you were going to go into, even higher ed, but especially medicine or law or any of these disciplines that seem very difficult to even parse on a basic level because they use a really specific and specialized set of words, of definitions, of jargon.
And just being able to sort of break through that jargon, to be able to say, hey, when we say this, this is what we mean, it helps them understand that there are, even though the project is different than something they may have ever worked on before, there are a lot of parallels.
I think, what we often do, and it’s the really easy way to define what a web project is, but we will use the metaphor of a building. So, you get your information architecture, and that’s your architectural plan, and then you’ve got your building of the actual house, which is HTML, and you’ve got all the different systems – your integrations are the HVAC, etc. It becomes a very tired and very thin metaphor by the end, but I think what it allows you to do is bring all of that discipline and all of the weird deepness to it up to a level that somebody is gonna be able to understand within their own context.
Tim Butara: I think it makes a lot of sense to make this metaphor. It’s very tangible; it’ll be hard to find somebody that has a good experience with the web that doesn’t have an experience with living in a house or in an apartment or something like that. So, yeah, this is again a little bit related to my next question. I wanted to ask about content – so, how should content be treated, how should content creation or content strategy be approached in a well thought out, well organized web project? And, maybe as another point, has this changed in the past few years, so since Covid started, or what’s the situation here?
Deane Barker: Ok, Corey’s gonna have a lot to say about this, so I’m gonna slip something in first. I think one of the key things you have to reconcile is that developers and the business look at content differently. Developers look at content as simply information that has to be managed – has to be modeled, has to be managed, has to be updated.
Content is really a business asset, it’s a business asset that provides value over time, and I think the business that way. And so, if you go to a developer and talk to them about content, they’re gonna be like, well, we’re gonna have a field for this and a field for this and a field for this – ok, well, how does that result in more revenue? It doesn’t; the business looks at content in another way. And so there’s a dichotomy there that has to be reconciled. And with that I will let Corey with this one.
Corey Vilhauer: Yeah, content is still the reason that people come to websites. I can’t think– I know there’s examples, but I can’t think of very many examples that don’t have content as the driving force of why you go. You don’t go to a website to look at the header site – unless the header design is the purpose of the site, and in that case you could argue that the header design is content.
But ultimately, when you look at how you might create a site– what Deane was saying earlier, the reason you actually put together the actual driving force of a site to begin with. You can build a site to be informational, you can build a site for commerce, you can build a site for entertainment purposes, so, like, Netflix; you can build a site essentially to persuade people to do something, or you can build a site that might be administrative. And the administrative websites are the ones that are probably the furthest from traditional content and more toward like, I need to update my Playstation Plus account.
So, Deane’s 100% right, it’s a business asset. Ultimately the goal of I guess even just the entire concept of digital transformation is to help streamline all the different places in which content and data occur, and to tie all of them together to create a seamless experience. Deane talking about– content modeling is part of content, the modeling itself provides some level of data and metadata to make that content work toward what it needs to be, the development side of things, the design side of things, it’s all ultimately serving the idea of getting that communication out into the world.
Tim Butara: Yeah, that makes a lot of sense. And now I want to go back to something that we started talking about briefly earlier, Deane. Actually I’d like to offer some contrast to that, because you mentioned earlier that one of the most important things is having a goal and sticking to the plan that you initially set out for yourself. But what happens now when you introduce agility into the context?
Because, the way that I just described now is very much akin to the waterfall approach of project management and product development. But now in the past two years, so since Covid began, since we moved more into the digital, more with remote working and everything, agility has kind of become a more and more prominent player for a lot of disciplines, a lot of fields, not just software development as we saw before, but for basically any kind of web or digital project. How would you say agility factors into all this?
Deane Barker: So, a great book, weirdly, about digital strategy is a book called How Buildings Learn. And How Buildings Learn is a book about physical buildings, and how buildings change and morph over time. I hate to beat that building metaphor to death, but it’s called How Buildings Learn, it’s by Stewart Brand, I have a copy on the bookshelf right behind me. But it’s a very oblong, very long book, and it’s a book about how buildings change over time.
And he has a sidebar in that book which has become somewhat legendary, where he talks about what he calls “shearing layers”. Shearing layers are the different layers of a building and how they shear across– to shear means to move across, and how the different layers of a building move at different speeds. The very top, most agile layer of a building is the furnishings of a building. I mean, if you want a table on the other side of the room, you move the table to the other side of the room, it’s very easy to change that layer.
The bottom layer is the site. If you decide you want the building facing a different direction, well, you can’t really do that after the building is built. And then there’s things like the structure, and the HVAC, and the services, they all start with an ‘S’. But these are the shearing layers of a building. And I think that a digital strategy has shearing layers as well.
I think the most agile of digital strategy is the content that you publish. You can content publish very quickly and easily, you can change content at will. I think the next layer would be the campaigns that you run. A campaign may be planned over two or three months, and if a campaign is not working out, you might end it early, but it takes a while to care of a campaign. And the next layer might be the basic message that your digital presence is pushing, like your basic value proposition. And all the way down, I mean, the most immovable layer of your digital strategy is, it has to help your company make money, make revenue.
And so when you look at agility, I think you can look at it at many many different levels, and your job is to enable agility as far down the chain as possible. Obviously you want people to be able to publish content whenever they want, to run campaigns whenever they want, all the way down. At the very bottom, the most basic level of agility, you want them– the digital presence, your digital estate, has to help your organization succeed.
The next layer up may be we exceed by increasing our revenue. But maybe that might change. Your organization might say, ok, we’re not worried about revenue right now as much as we’re worried about recruiting, we need new employees, we’re gonna die unless we have new employees. And so that has to change. And so when you look at these shearing layers, just understand that organizations move at different speeds, and your job is to enable that agility as deep into the stack as you possibly can.
In business, one of the biggest things I learned – I was a partner at Blend Interactive for 15 years. I’m not a very good businessman. I’m very good at a very small number of things, but I was a terrible businessman. The CEO of Blend got grey hair trying to manage me as a partner, I was terrible at it.
But one thing I did learn about business is that things can change and it doesn’t mean that they were wrong. And I remember that we used to have at Blend, every Monday morning we would have a two or three-hour meeting to go through all the projects. And there was a point in time where that meeting just got too big, there were too many people there, there were too many projects, and so we stopped doing that meeting.
And I remember going back to my desk after we announced that we were gonna stop that Monday meeting and thinking to myself, boy, we screwed that up, obviously we made a mistake by having that Monday meeting. And then I came to the realization that no, we didn’t. It worked until it didn’t. It worked to a certain period in time and then it didn’t work and it changed.
And that’s the thing about business – just because you change how you do something, doesn’t mean it was wrong, it just means the circumstances have changed. And so that’s when we talk about agility. You need to make sure the organization can change, and if it does change, it doesn’t mean that it was wrong before. It’s just, circumstances have changed and you need to adapt with it. So, your goal, with any digital estate, is to enable an agility and adaption as deep into the stack of layers as you can.
Tim Butara: I love that answer. That was so perfectly said, and a lot of really on-point points, thanks, Deane. Corey? Any thoughts here maybe?
Corey Vilhauer: If you’re looking at agility from the development side of things– Blend’s interesting. I mean, I think any professional services organization that works outside of an in-house team can fall into a struggle when it comes to agile development. I think what an agile environment has, like a traditional agile environment, obviously, you’ve got a site or service, it’s being built and maintained. You have your own people, and they can kind of do what they need to do, and you can run that in whatever way you need to run it.
When you work as a development firm from the outside, we still have deadlines and we still have budgets and we still have all of this stuff that we can’t really– we end up still doing, just from the more project level side of things, we’re still as agile as we can be, but we still have to work on the whims of the fact that we have other projects we’re working on and we can’t shift and change and add months onto a project just because we decided to change the direction halfway through.
It’s really interesting to see the whole revolution that came with agile and try to fit it into a traditional services type of organization. There’s this sort of idea that every web project comes with a multinational enterprise-level organization of people, like a 10-person team who can do all these things.
And in reality, most of the projects out there – think about just sheer numbers. There are a lot fewer of those projects than there are projects that have one person who is kind of struggling to maintain this, and every level of agility can be difficult, the project level, the building a website level, the making organizational changes, the marketing changes, all of that stuff can be really difficult because they can move fast, but they also don’t have anyone to bounce their ideas off of. It’s like, how do you balance that?
You talked about Covid, too. I don’t know, Deane, maybe you ran into this too. I don’t think we ever had any issues changing as far as our own agility at Blend or with a lot of our clients when it came to Covid. It’s weird to say, but with the exception of trying to maintain culture, our projects got easier, because we learned how to just be available and we needed to be available, and also remove the idea of, hey, I’m gonna randomly walk by and take you of whatever zone you’re in because I want to talk to you about this other project that’s over here.
I think we kind of were able to force timebox in a lot of the work and still just make sure we created that culture of having meetings and being agile to a point. But also, we’re all still available, we’re actually more available now, because we’re all used to using the same tool.
Deane Barker: We’ve had long conversations at Blend about agile methodology and professional services, and it can be hard. When you look at agile project methodology, in general – it’s easier to do when it’s inside the organization, but what we would find is that customers came to use and they wanted a number. Everyone wants a number, right?
So I actually wrote a blog, one of my more well-read blog posts was called “Everyone Wants a Number”. Because they come to you and you’re like, well, we’re gonna do this agile process, we’re gonna let you change your goals over time, and they’re like, ok, give me that number down to the penny. And you’re like, well, I can’t do that.
And so it became very very difficult for us to implement, like, a pure agile methodology at Blend. I mean, unless the client was willing to go on some kind of monthly retainer, which is becoming more and more common, it was much easier to do. But customers at Blend for a long time were still very much kind of inculcated into the idea of waterfall methodology. You’re gonna do step one, two, three and four, and then I’m gonna get an invoice for this amount of money. That can be a tough habit to break.
Tim Butara: I think this ties back to what you were talking about earlier, Deane. About letting, or adopting agile processes as far down the line as you can. So, for some companies, that might mean just dipping their toes into some agile practices and just maybe being a little bit more flexible. And I think it’s really a kind of a case by case basis, it really depends on the company, it really depends on the industry they’re in. There’s just a lot of factors, and I don’t think there’s a uniform, concrete, one-off answer to all of it.
Deane Barker: Yeah, if I can be totally cynical for a second.
Tim Butara: Go ahead.
Deane Barker: People want agility until they get it and then they don’t know what to do with it. A lot of people want – I can see you’re laughing now cause you know this is true – a lot of people want a very well laid out structured path. What I found in business is that people don’t like blank slates.
This is why canned products do very well. This is why a canned project management system or a canned internet do very well. Because people just don’t know what to do with the tools they have. They don’t want a blank-slate CMS because they don’t know what to publish, what content types to have. They want someone to give them a prepackaged solution that’s a bundle of both a software platform and effectively a bundle of consulting and opinions.
And so that’s where you have waterfall methodology. People are very comfortable with that, and I’m not saying it doesn’t have drawbacks. But there’s a level of comfort there because they don’t know which direction to go in, they want you to tell them this, they want you to lay these train tracks down in advance for them. And it takes a more sophisticated customer and a more confident customer to say, I’m just gonna have you start doing this for a while and then we’re gonna shift a little bit later on. There are a lot of customers who just do not have the maturity to pull that off.
Tim Butara: That was a very important add-on, yeah. And I must say, I’ve really enjoyed our conversation so far. It’s been great, great points, great insights from both of you. And I just have one final question for the both of you. And maybe it goes a little bit more broader, because we were talking specifically about the web project. But I’ve been wondering, like, at what point should we stop just treating it as the web project and maybe start treating it in a more integrated manner, as a digital project, or a digital experience project? What would you say?
Corey Vilhauer: A web project is part of a digital experience project. I think it’s important to treat them both as they are. You need to make the larger digital experience project plan, but also know that the website is its own thing. You don’t create software and you don’t create databases and you don’t create social networks and sharing platforms in the same way you create a website, they’re different elements within a larger concept.
So they should always, obviously, be created, when possible, as a part of that overall project. But a lot of times, and I think Deane was sort of alluding to this, the issue that– small steps are better than being paralyzed by the larger project. If all you can get through is a web project, then it’s better to get that web project through than it is to be, like, wait, hold on, we need to get our entire digital experience thing figured out. Eventually, websites can be pretty easily integrated within a larger digital digital experience given, obviously, the right time and budget. But as long as you know that the web project is a smaller part of the digital experience and not completely separate from, I think you’re probably starting off pretty well.
Deane Barker: Yeah, I’m gonna make a very unpopular and controversial statement for some people. And to say, a digital estate – and the phrase “digital estate” refers to anything you do digitally – a digital estate is normally always anchored by your website. Now, there are some exceptions to that, there are some app-focused organizations.
Someone did come up to me after a conference presentation once and called me out and said, it’s very different in Asia. Asia is less about the web and more about mobile apps, which I totally get. But for the western world, certainly, your digital estate is really anchored by your website. And I understand multichannel publishing and omnichannel publishing and all the different places we can push content, but let’s face it – your website is kind of your home base. On the internet. It always has been.
We called the book “The Web Project Guide” fundamentally for approachability. Like, “The Digital Project Guide”, we thought, just, marketing people wouldn’t understand what that was about. And we actually talked about this, Corey, I think in the first chapter we talked about the fact that we are gonna talk about websites, but this is really applicable to everything else.
And so, I believe – and this will be a very controversial statement for some people – but I believe in the primacy of the web. I believe your website is the anchor for your digital estate. You can go all sorts of places from there, but if you don’t start with a really solid web presence, for most organizations, that’s not gonna be a great strategy.
Tim Butara: I love it, Deane. You just tell it like it, what you think, even if it might get some people, might make them feel unpleasant or unhappy. So, thanks for the honesty.
Deane Barker: That usually gets me in a lot of trouble.
Tim Butara: But, hey, you gotta do you, right?
Corey Vilhauer: Deane doesn’t always have to do him, but he does.
Deane Barker: True, true.
Tim Butara: Thank you so much, Corey, thank you so much, Deane, this has been such an awesome conversation. I’m really glad I had you on the show, I’m really glad we got to have such an honest, smooth conversation. We got so many great points, great insights out of all this. Just before we wrap up our great conversation – if people wanted to reach out to either of you or learn more about either one of you, or learn more about the podcast or the book, where would you point listeners to?
Corey Vilhauer: It’s almost all located at webproject.guide.
Deane Barker: It’s almost like that is the anchor of our digital presence. Did someone just talk about that? I feel like someone talked about that.
Tim Butara: No, I don’t think they did, I don’t think anybody mentioned anything similar to that, Deane.
Corey Vilhauer: No. Yeah, the whole site’s there. The book is there available, chapter by chapter, online. And then you can also buy a physical copy through there, there’s a link to that, and the podcast, you can access it through there. Otherwise, I’m at Blend Interactive, we’re a small firm in the midwest. Deane works at a CMS company.
Deane Barker: I work for Optimizely, we make a large enterprise-level DXP. And you can find me there.
Tim Butara: Awesome. Well, thanks again. I wish you a great day, and I hope we get a chance to speak again.
Corey Vilhauer: Thanks Tim.
Deane Barker: Thank you.
Tim Butara: And to our listeners, that’s all for this episode. Have a great day, everyone, and stay safe.
Thanks for tuning in. If you'd like to check out our other episodes, you can find all of them at agiledropcom/podcast as well as on all the most popular podcasting platforms. Make sure to subscribe so you don't miss any new episodes. And don't forget to share the podcast with your friends and colleagues.