Episode 15: Determine System Requirements (w/ Joe Kepley)

Hello, this is the Web Project Guide Podcast, and this is episode 15, Determine System Requirements. I'm Corey Vilhauer, director of strategy at Blend Interactive, and co-author of the Web Project Guide. Later we'll be joined by Joe Kepley, chief technical officer and founder of Blend Interactive, and naturally, my boss. But first I'm joined by my previous boss, senior director of content management research at Optimizly, Deane Barker. Hi Deane.

Hi Corey.

Do you remember when you were my boss?

I was your boss, and Joe was my partner. So this is going to be a call like the one we had with Sam a few months ago where Joe and I and one other person founded Blend Interactive back in the day. And so Joe and I had a whole lot of experience doing the things that he's going to talk about. I just want to point out that Joe was much better at it than I was. I was terrible at it, which is why I'm no longer in services.

I want to start the episode off the way I often do, which is I make a statement and then I just assume you're going to talk about it.

Hit me.

When we wrote the book, we kind of focused a lot on parceling out this information into obviously individual chapters with a few exceptions. One exception was the idea of planning, which we kind of spread across the first four chapters, about getting your ducks in a row chapters. We talked about making sure you had a good team and making sure that you understood why you're doing things in the first place. And the other big exception were these chapters that we're kind of jumping into now, which is 15, 16, and 18, really focused on the three sides of a pretty common question. How do you figure out what tool you're going to use to build this website that you've now planned?

(01:44)
And so really, there's three sides to this coin. It's a three-sided coin, which is not real. But there's figuring out what you need the tool to do. There's figuring out whether or not the tool can do the things that you need. And then there's finding the team that can help you implement the tool. We'll talk to Joe later about the specifics of figuring out how to translate site needs into technical requirements. But for now, which of those three sides do you feel is the most difficult? Or they all seem equally difficult to be honest. So which of those three sides feels the most crucial?

Well, I think the thing that we're going to talk about today is probably the most crucial. I mean, you're going to make decisions. You're specifically needing to decide what part of your dream you want to technically support and how you're going to approach it. I can tell you that picking the team and picking the software is the scariest because you're actually making commitment to other people. You're actually paying money, you're actually writing checks. And some people get really freaked out about this.

(02:45)
But at this stage of the game, this is when somebody like Joe sits down and evaluates what you want to do, and figures out at a large scale how you're going to do this. And this is separate from picking a CMS because many of the things you do may have nothing to do with the CMS. Or they may be global no matter what the CMS is. So this is far and away the most crucial part. I mean, assuming your plan is good, assuming the things you want to do are going to provide value to your organization, and assuming, Corey, that someone like you has done their job well, now is the point where we decide... Now is the point where a carpenter hammers two pieces of wood together, and this is the point where decisions are made that will affect the technical stability of the project.

(03:23)
So this is far and away the most important point of that three-sided coin, as you put it. But it often doesn't feel as important because any decisions you make here, you kind of feel like you can change later on. When you buy a CMS or you engage with a team, that feels like much, much more of a commitment and people labor over those decisions far, far more.

Yeah, totally. Let's go right into this interview, Deane.

Let's do this. This is going to be a homecoming because the three of us worked together for 12 years, I believe.

That's true.

And you and Joe still work together so-

Still do.

... this is going to be a homecoming conversation with the boys.

Joe Kepley is a co-founder at Blend Interactive where he currently serves two roles, chief technical officer and technical strategist, and we'll talk to Joe after the break. But first, this episode of the Web Project Guide is brought to you by Blend Interactive, a web strategy design and development shop dedicated to guiding teams through complicated web and content problems. Blend's been building great websites for over 17 years. And as we'll talk about later, the principles have been building things for even longer, and we're always looking for our next partnership. So visit us at blendinteractive.com. All right, let's welcome our guest, Joe Kepley. Hi Joe.

Hi Corey. How are you doing today?

I'm good.

Now we've probably talked about this already in the intro, but there's history here, like there was with Sam.

A bit, just a touch.

In 2005, Joe Kepley and myself and one other person founded Blend Interactive. And so Joe and I were business partners for, how long, Joe, 15 years?

Yeah. Somewhere around there.

And so much like Sam Otis, Sam being the senior designer at Blend, there is a lot of history here and there will be probably a lot of war stories, our years in the trenches battling away in professional services. So what we're talking about today is we're talking about the part of the job that, boy, I don't know if this sounds cynical, but the part of the job we liked the least, or maybe the best. I don't know, it depend.

(05:27)
But we're talking about the situation where a customer came to us with an idea, and Joe and I were often tasked with trying to take that idea and to wrap some technical parameters around it to figure out what their actual requirements were. And you'll encounter this on any project. A lot of people have great ideas in theory, but it needs to be reified, turned into something that can actually be implemented. And I did this quite a bit at Blend. And I found it very frustrating, which is why I'm no longer in professional services. Joe, what was your gut feeling about it?

Yeah. Well, I think it used to be that we struggled with this a bit. And I think anytime that you have somebody that comes with an idea, and they're non-technical, and I think especially since we've got so many amazing things on the web now, you think about the scale of something like Google or Facebook, and all the amazing things they can do, and it seems to kind of happen by magic. And I think people's expectation, if you don't know how all that works, is that that'll just kind of happen and it'll be fairly easy to do. So you have that on one side.

(06:44)
And on the other side you have developers, programmers, designers, people that are going to actually build the thing. And how do you explain to them what it is we're building, and the real trick is explaining in a way that both a technical and non-technical person can understand it. Because what we're really trying to get to is understanding and making sure that we're on the same page for what we're building. And I know especially in web projects, and particularly when a CMS is involved, we talk about 1,000 things during the course of the idea phase of that project.

(07:22)
But eventually it's going to come down to a budget and a timeline, and when can we get this done, and how do we do it? And really having a good understanding and nailing down how to do that is really key. So that's something that at Blend, and I think particularly since the past couple years, Deane, so maybe since after you've left Blend is we really tried to-

Clearly, I was the log jam there.

Yeah. No, now that we've got rid of-

After I left, you got it all figured out.

Now that we got the detritus out of the way. No, no, I think we really saw it as a need and it kept coming up. And so we really tried to nail down what is a process that we can do around this that works and a repeatable process that we can use on a lot of projects. And we have taken that over the years from just a notion of how we talk about things to really dialing down now to even having some supporting software that we've put together that helps with that. And this is a big part of Corey and I's job, and Sam as well.

(08:28)
And so the three of us, along with another designer, are what Blend calls our strategy group or content strategy department. And our job is really to work with clients at the start of a project, help them understand what's possible with the CMS, what can we do, what's a good idea based on other projects we've done and projects in their market or in their vertical. And then really nail that down in a way that the development team's going to understand what the client's goals are, and then understand what we were trying to get done with the plan.

I think that it's we would always talk about, I don't know how much dirty laundry I'm airing here, but in professional services, in general, you always talk about how crazy a client is. And that's obviously very insensitive to people with mental illness. But the idea of how attached to reality or detached from reality is the client. And over the years I came to understand that that was an unfair characterization. It's just clients are coming to their project from an entirely different perspective than we are. And I think to some extent, you're just trying to reconcile viewpoints, and also trying to dig under what they say they want to figure out what they actually want. But I mean, to what point, Joe, did you think that your job was just to rain on people's parades?

I think you can certainly approach the job from, well, we're trying to get this done within time and within a budget. So you get a Wikipedia page, and you can put a picture on it and we're going to call it a day, right? But no, I think it's really about enabling. Because I think the other part of it, we approach it from the software side of we have to build something, but the other part of it is really understanding what the client's needs are, and using that to maybe open up some things that they didn't know about.

(10:22)
So a lot of times, particularly with CMS systems, and particularly with what we are now calling digital experience platforms where there's a lot of services offered in those suites, and a lot of times more than a client can use, but we know about those because we work with these pieces of software all the time. And if you just buy it off the shelf, you may not know it does that. So one of the things we really start with is when we're working with a new client is we walk it all the way back to, particularly for a corporate website, what are your mission, vision, and values look like? What does your organization do? What's important to you? Because what we really need to align on is get a really good understanding of what does your job look like, what does your goal look like?

(11:05)
And one of the key questions we ask at the start of a project is, what does success look like? When we looked down the road, if we had a time machine and we hopped in our DeLorean and drove to the end of this project, and we looked at, we're having the kickoff party and everybody's celebrating, what does the project look like now? And we try to capture those things and boil them down to, okay, well what are we measuring? So if you're saying, well we are getting bad accessibility scores now, and that's not helping us, or we're getting poor SEO, or people just aren't able to find their way around the website, we try to boil those things down to, okay, well how do we measure those things? How do we look at those metrics?

(11:46)
Because it's really key, not only for people to understand that we're having a successful project, but also when you look at these systems, whether you're building it in-house, or whether you're working with a firm like Blend to build it, you're going to either buy a piece of software or get an open source piece of software. But regardless of how you do it, you're spending a lot of time and a lot of money. So you're making a big investment in making your website better. And what we want to make sure we can demonstrate is that there's a return being provided on that investment.

Let me play you two off each other for a second because you two work together.

Play us two off each other?

Yes, this is going to be fun.

Oh boy.

No, we're an unshakable rock. It's not possible.

You two work together and you're involved in this process collaboratively. And then I think you're both a study in opposites. Corey is not particularly technical and Joe has an appalling lack of social skills. So I think between the two of you, you're at opposite ends of the spectrum. So let me say, when you're working on this type of, and you guys have been doing this together for a long time, what drove you insane about how the other person would handle this process? But historically, and how did you kind of reconcile that? Joe, when you would get wireframes in from someone like Corey or from Corey specifically, I mean what part of the wireframes were you like, what the hell am I supposed to do with this? I mean, what was the most frustrating part of that for you?

Yeah, well I think with wireframes in particular, I will say that Corey is very good about not doing this. And that's partly because we work together and partly because he and Sam and I always get together and go over each batch of wires to make sure that what we're delivering, we're all in agreement that we can do it. Because we've learned from the past that, if we don't do that, sometimes we embarrass ourselves.

(13:42)
But I think it's really common at the wire framing stage to just kind of draw a box and say, well, this box looks cool here, and it's got this button in it because that feels right. But then I think a lot of folks will not have a plan of what that button does. Or just say things like, "Well, this is going to list our top trending topics on our website." But then people don't think through, okay, well how are we going to understand what the top trending topics are? Is that what people are searching? Is that what our editorial team wants to highlight?

(14:13)
So I think there's a danger, particularly if you just start with the wireframe side and don't have some of that framework of what are we really trying to accomplish, and you just start drawing pictures, you can draw some very nice looking pictures that, A, may be difficult to implement, and B, may be things that when you sit down and align with what your goals are don't really make sense to implement. So you can spend a lot of time doing hard work that doesn't benefit you.

Tony Byrne called that seduction by wireframe.

Yeah, yeah. And I think we used to talk about, Deane, software that demos well but doesn't particularly work well, I think is really common. It's very easy to make something look good in a sales demo because it does something cool. But what you really need to do is sit down and think about how your organization needs to use the software. And I think you guys will probably talk about that when you get to CMS selection.

Related content was always my favorite box on a wireframe. Well this is where we're going to have related content. From where? How are you going to determine that? I remember an internet project where they also wanted to do top searches. I thought that'd be cool. We just have a box of top searches. So I asked them, "Well, how are you going to determine the top searches?" And he says, "Well, we're just going to count up what people are searching for." That worked really well until the number one search was layoffs. That worked really well. So they didn't think that part through.

Yeah, the one you see sometimes too is, well, we're going to bring in things from Twitter that have our hashtag on them. Okay, well have you gone out on Twitter and search what your hashtag is? And have you done it on a day when you release bad news because let's think about whether you really want to do this or not.

So Corey, let's give you a chance to talk some smack about Joe. When you-

First of all, Deane, Joe's technically my boss. Come on.

Come on. But this is a free zone. What happens on the podcast stays on the podcast.

That's right. I forgot. This is all sort of a private thing that nobody listens to. And Joe, actually, we're going to mute Joe's headphones, so he won't actually hear this.

Yeah. You can mute me for this part, and I can guarantee that because my own voice is on it, I won't listen to

No. So this is my question though, Corey, because you work with our customers. Our customers. I haven't been at Blend for three and a half years. They're our customers. You work with customers to define a vision. Do you ever or have you ever experienced frustration where you felt that something should have been technically feasible, but you were told that it was not? I mean, is there frustration for you and technical reality wreaking havoc on your vision?

No, but I think the struggles that I have ever run into when it comes to translating user design and translating the actual the work that they want to see or the design that they want to see into something else, it's usually past the requirement stage. It's usually at a point where we're diving into editorial requirements where we're like, this could be easier for the editor to tackle, but it's more difficult because the developers developed in a way that is easier for them, if that makes sense. The ease of development overtook the ease of editorial creation.

(17:24)
And I think a lot of that, like Joe mentioned, a big part of our process now is that I have moved away from creating something that I know can't be developed because we do touch base once a week on all projects to make sure that our designs are transferrable into either the selected content management system or within the constructs of content management itself. I think what that's done is highlight a lot of the types of requirements that are sometimes shielded from editorial need.

(17:58)
By which I mean related news is a perfect example of this. There is an editorial way to handle related news. That editorial way is incredibly time consuming. That editorial way is a thing that everybody will be excited to do when they launch the site, but nobody will ever do once the site is already launched. And explaining the technical side of that, explaining that this isn't magic to the client has helped kind of curb a lot of those items of functionality before we ever make it even to design. I think we've gotten a lot safer when it comes to how to turn design into development because our design team has worked so closely with a content management system for its entire life.

Yeah. And I think too that our team very, very seldom will say it can't be done. I think we do often try to understand what it's going to take to do it. And to Corey's point, that is both in terms of invested time in building whatever the thing is, as well as, okay, what are you going to have to do day to day to keep whatever feature that you've designed up and running, and understand what you're signing yourself up for? And really that's what a lot of this is is being smart about weighing the cost benefit of adding anything to a website.

(19:18)
I think a lot of what we do now, and Corey mentioned we've changed process over times and evolved a process, and I kind of look at it as, really, you think back Deane, when you and I started, when you showed a client a website, what's the first thing you did? Well, somebody sat down in Photoshop and for a number of days worked away at some really cool looking thing. And you didn't even think about could you implement it or not? And you showed it to them and maybe you had spent the afternoon designing some really interesting new feature, content feature, and you'll spend the entire meeting talking about whether that's really the right font to use in this spot. So a lot-

Figured the corners were rounded enough.

Oh yes, we rounded a lot of corners. Gradients too.

The years before border-radius. If you're young and you've always lived with border-radius, you don't remember the joy of trying to round corners.

Yeah. We were putting things in tables to lay them out. It was the Stone Ages. But yeah. No, I think really what part of our process is now is directing the decision making process from large to small. And really that's what wires and technical plan and setting requirements is about. That you start with who are we as an organization, what do we need, what do we want this to do? And then that takes Corey into discovery and working with clients on understanding, talking with all the stakeholders in the project. So the people asking for the site, the people that are going to be running the site, the people are going to be using the site. And really looking at what is the model of this thing in everybody's head. And then he bakes that down into, okay, well we need these types of site maps and wireframes.

(21:05)
So you talk at that site map level of this is our customer journey, or this is what we want users to do on the site. You move from there into wireframes, which is kind of your first shot at visual. And the reason we use wireframes is because they're low fidelity somewhat of the idea that I can see how the thing is laid out, but everybody understands it's just names and boxes at this point. So there's not going to be a discussion about color around font, around imagery. We are all just looking at logically do these pieces fit together on a page?

(21:44)
So then you move from that into designs that are informed by that because those decisions are set now. So now it's time to talk about those colors and fonts and images. And then we really start walking through individual pages and individual blocks and components. So the whole process is that kind of idea of directed focus on what decisions need to be made at each stage. Because if you just try to do it all at once, you tend to look at a piece or get down in the weeds and you're not going to necessarily make the right decisions that are going to lead you to your successful goal.

I have a question for the two of you, since we weekend... I can do this also. I can do the same kind of question to you.

You can't pit us against each other because we don't work at the company anymore.

I'm not going to pit you against each other. But here I think we know next episode we're going to talk about specifically selecting a CMS. We're going to talk more about the details of what you need when you go into selecting a CMS. But there's really kind of two parts to this. There's the requirements you need of a CMS, and there's also the requirements you need within the CMS, if that makes sense. There's like how do we decide what it is that will help us make the decision on what CMS we choose, but then requirements for building within that CMS?

(22:56)
And a lot of times they're the same thing. A lot of times it's like, well, we needed to handle pages this way. We needed to handle blocks this way. We needed to have this level of security and other stuff that I don't know about or care about. But I guess what I'm wondering is how does that process differ between those two? Is there a line there or is the idea of determining requirements before knowing a CMS versus determining requirements after already selecting a CMS, are they ultimately pretty similar?

Yeah, I mean think Deane and I probably have slightly different perspectives on this because there's two selections, like you said, that happens there. One is do we use this CMS software or not? And a lot of that is based around the features of we're kind of investing in this ecosystem and all of our stuff is going to be in here, so we're going to put hundreds of hours potentially over the life of this software, probably much more than that, into working in the system and filling it with information. And that's going to be at least somewhat hard to move. So we really want to really pick something that can do everything, including the stuff we haven't thought of yet.

(24:08)
So I think as a CMS vendor, and Deane and I used to, I think, make fun of this a little bit because it seems like everything has every bell and whistle, but I think there's some value to that because the software needs to be flexible and needs to have a lot of features that can enable things. I think sometimes it gets a little maybe silly because really what you need is software that's very flexible, but you have to demonstrate that flexibility. And so sometimes you have features that may or may not be useful. I think that's gotten better than it used to be with software, that I don't think there's so many kind of showroom features on a lot of the CMS systems we use now. But as an implementer, really what I'm looking at is does it enable me to do the stuff I need to do now? And again, I don't think we get in a lot of situations where we say we can't do something. So the question is with this software, how hard is it?

So much of it is just table stakes now. Every CMS should be able to build a page. It should be able to pass through a login. Because that stuff isn't tied to the CMS itself, it's tied to the implementer, it's tied to the people who are building within it.

Yeah, I always felt it was interesting when you're looking at requirements because are you looking at these requirements in general, or are you looking to fit these requirements into the capability of a selected CMS? Those are two very, very different questions. Because if the world's totally open and you haven't selected a CMS, there's a million different ways of doing things. If you have selected a CMS, there's one way of doing this. And so can I get this to work or can I get this to work in this particular CMS are really two different questions.

This is more of a comment than a question, and I just want you two to riff off of it. I'm working with a friend of my mom's who runs a church site. And they run it on Squarespace, by which I mean I run it on Squarespace, and then they send me an email that's says to update a thing. And I was thinking yesterday-

You're the CMS.

I'm the CMS. Yeah. I was thinking about how interesting it is that big corporations can afford big CMSs. They have a whole team of developers. They have the need to develop a set of requirements. Whereas this organization has one person who does it sometimes. And they don't have a list of requirements, they just have the requirements that come with the package is.

(26:25)
And I guess the reason I bring this up is, Joe, you and I are working with a content management system called Umbraco that has kind of its own pre-packaged Squarespace sort of option. And I think we're both really trying to figure out the place for the idea of creating a set of requirements when you don't really need to. They're already built. There's already stuff. There's nothing you can go in there and say, hey, we actually need this to do this, this, or this because it's just already built. The stuff's already kind of taken care of. I don't know, just a thought. Somebody jump in there.

So I maintain that a very helpful thing is for a CMS to be bad cop sometimes. There were times where I would talk to customers, if they had a CMS selected, and it was very nice to be able to tell them, "Well, this is the way the CMS works." Because it took their mind off of concentrating on stupid things. You could just take decisions away from them. What's that line that says something is not perfect when you've added everything that can be added, but something is perfect when you've taken away everything that can be taken away. And I find with your experience with, what was it, Shopify?

Squarespace, he said.

Squarespace. Right. So something like Squarespace has a limited feature set, and it's just the way the thing works. So it's less of what's the best way to do this, and more of how can I do this within the system? And you think, oh, I don't want to be constrained by that, but the fact is, the best way to do this and how to do this within the system are very, very close together and not much different. And by just forcing you to do it a certain way, you save an enormous amount of time wasted on considering the alternatives.

Yeah, yeah. I mean I feel like most websites at their core are about communication and either delivering your message, telling a story, providing some type of resource, information to people that they need. And so I think people that do web professionally kind of look at something like a Wix or a Squarespace or something and say, well obviously that's so simple, but the reality is that a lot more of the success of that communication, telling that story, bakes down to how are you telling it and how are you working with it?

(28:51)
So if you know those design constraints, you know how those work and what are the tools in my toolbox? I can drive out to the other side of our state out near Mount Rushmore, and there's a town called Keystone. And on the main street of Keystone, there's a guy that makes things with stumps and chainsaws. But he makes amazing art with stumps and chainsaws because he knows his tool very well and he can make anything with that chainsaw.

(29:19)
And I think even if you have a fairly crude set of tools, if you understand how you're going to use them and have a plan for what you're going to do, you can still make amazing things. So I think obviously there's value to a really good CMS and a lot of marketing tools. And that value is more around how do I maximize the efficiency and the effectiveness of my message, of my story, because I can customize it to the user or I can understand how it's working and tune it over time.

(29:53)
But at its core I think you've got that what is my message, what is my story? So if I have a Squarespace account and they give me eight different components to work with, how am I using those eight and how do they fit with what I'm doing, and am I using them in the right way that make them effective? I mean that I think at its core is that level of planning. And there are situations like that where it's like the tool may not do as much, but that just means I need to plan how I'm going to use it even better.

When you look at these projects, projects are a bundle of hundreds and thousands of different decisions. I've always wondered, of the thousands of different decisions you make in an average project, which ones are critical? Which ones are ones where if you decided the opposite way you did, the project would fail? How many of these decisions are just naval gazing where you're just like you're putting time into something that is really not going to have any material impact on the project? What decisions actually will have a material impact on the success or failure of the project? And I think part of experience is knowing which one of those decisions matter and that you should put some time into.

Yeah. I think ultimately the decisions that really sink or from a project come down to people. And I'm sure this has been a recurring theme for you guys that a lot of this comes down to people.

We were waiting for somebody to talk about it, Joe.

Somebody finally brings it up, right?

Every conversation goes back to human nature and social factors. I maintain if you're listening to this podcast and you are a counselor or therapist of some kind, you have a big future in digital. Come on over, we could use you.

Yeah. But I mean if you think about it, you mentioned that there are a lot of really technical decisions that happen on a project. But if you have a team, so if I'm corporate marketing and I'm sponsoring a big project, and I have a team that understands how I work and what I need, and I have a good relationship with these folks and I care about what they do and they care about what I do, then if we make the wrong technical decision, we can always reverse a technical decision. I mean it gets progressively more expensive the further we go, but we can try to figure out the right thing to do.

(32:16)
I think the projects that really become unsuccessful are ones where you're working with the wrong team, or on the agency side, maybe you have the wrong client. Because I think there's definitely a partnership that has to happen there. And if that's not forming, if you don't have that trust, and good, open, honest channel of communication, then you're opening yourselves up to a lot of trouble as you try to make these decisions. Because really I think a lot of it comes down to trust. That we work with a lot of folks who, by and large, are building one website maybe this year, maybe this decade, and we build a dozen a year.

(33:03)
So I think the relationships that work really well, they trust us that we have done this a bunch, and we understand how to at least give them good advice. We have to be certainly humble enough to know that we definitely do not understand their business better than they do. They understand their core business. And that's really where we have to rely on subject matter experts on both side of the fence. On the agency side of Blend, we have to rely on our digital team to understand the best way to implement things. And we have to rely on our clients to understand what their customers need, what their stakeholders need, and what they are seeing as success, and how they're going to use the product and be empathetic with that and make sure we adapt our plan to fit it.

Well, Joe, what can we promote for you? It's funny. What can we promote for you, or what are you up to? This podcast is technically your podcast because it's owned by Blend Interactive.

A couple of folks at my company have released this great book called The Web Project Guide, which is now available as digital PDF. And so if you weren't set on the website and didn't want the ebook, then we have a PDF you can add right to your digital library. Blend Interactive is of course always interested in talking to amazing teams about amazing projects, and we would love to be a part of them. You can find us at blendinteractive.com, or just listen to this podcast again next week.

Next month, Joe. I can't do this every week.

No, we've moved you up to weekly now actually. I don't-

Corey and I can barely tolerate each other.

... [inaudible 00:34:39].

Has anyone told Deane, or is it just me for the other three weeks every month?

You have to have enough clips of Deane on the floor now that we can just play unused clips of Deane, and kind of fill things in for the-

My opinions vary so wildly you can pretty much wrap them around anything. Well that's it for Joe Kepley. Joe, thanks for your insight there.

Thanks Joe.

Great talking with you guys, and we'll see you again.

All right, we are back, Deane. That was Joe.

That was Joe. And Joe is a great guy, and one of the most talented developers and architects I've ever worked with. But that entire conversation was just flashback to the part of the business that I was never really good at. So I'm glad to see that Blend has actually got this down to a refined repeatable process. And we didn't bring it up on the call, and I should have asked this question, but Blend has a tradition of naming things. And Blend names everything. And I think maybe that was my, I used to name everything, and we named everything at Blend. And the system that you have used, the procedure and mechanism you've used to implement or plan implementations has a name, Corey. Tell us what that name is.

It's SPECIAL, which stands for Spec and IA Library.

And that is just so classic Blend. That is just classic. But it is neat that you have the one thing that professional services firms never do is put some kind of repeatable process behind this. And this unfortunately is so fraught with risk because you risk two things. Either you risk pissing off the client when you don't deliver what they wanted, or you risk having to deliver what you misunderstood and going underwater on a project. And I can tell you the 15 years that I was a partner at Blend, that would happen. We would misunderstand something. And Blend, we were always desperate to make our clients happy. And there were many, many times we kind of took it in the shorts and went underwater on a project because there was a misunderstanding.

(36:41)
And we at Blend, we were very, very slow to blame the client for misunderstandings. We would generally always think, well, clearly we screwed that up. Probably to our own detriment many times. And we would spend a lot of money fixing problems for clients. And I don't want to say that happened all the time, but whenever you do professional services, especially in a space like digital, there's always the threat of misunderstandings.

(37:04)
Because you're coming at it from, like we talked with Joe, there's two wildly different perspectives. The customer has this dream in their head, and it's just bouncing around in their head with no kind of technical limitations or anything. And then someone like Blend exists in the real world where you have to make something work technically. And not only work technically, but work economically. Work in such a way where you can make a profit on the deal. And so reconciling those two viewpoints is very, very tricky. And there's a great potential for misunderstandings, and that would happen occasionally. And when that misunderstanding comes up, who ends up paying for that? And at Blend, we were more likely to fall on our sword than we weren't [inaudible 00:37:41] client with it.

Yep, absolutely. Well that's our show. Thanks to our guest, Joe Kepley, chief technical officer at Blend Interactive. I'd say I'm proud that I was able to keep the two of you away from talking too much about 20 year old projects, but it still happened every once in a while. The 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. Everything from strategy to the types of technical requirement planning that we just talked about.

(38:13)
We're dedicated to making great things for the web. And this podcast is one of those things. This is also episode 15 of the Web Project Guide, which corresponds with chapter 15 of the book, Determine System Requirements. You could read the full text of this chapter at webproject.guide/cms-requirements. They all have one word names, and this is the one where it had a two word names, so there's a dash in it. Is it a hyphen?

Just threw you for a loop, Corey?

Well, it kind of did. So it's webproject.guide/cms-requirements. Or would you say CMS hyphen requirements? Doesn't matter.

I don't know why it's even cms-requirements. It should be-

It should be just be requirements.

Because I think we established that this is really not CMS related.

Yeah, I don't know.

Misnamed that title. We apologize for the URL. We'll do better in the future.

We'll try. Yeah. We have some exciting news that unfortunately Joe spoiled. And that's that we have, in addition to being able to order a physical copy of the Web Project Guide, which is a beautiful book that, as a listener, you are kind of required to own. So go buy one already. We have also begun featuring two new items in the Web Project Guide. Store visit order.webproject.guide to grab one of the two things, A Web Project Guide gift set. Deane, did you know there's a gift set?

No. Can I have one?

You have everything from it. It's the book plus the socks.

Okay. I do have the socks.

The socks are great. We have a wonderful picture of Deane wearing the socks on his hands for some reason. I don't know why.

That explains why I wasn't good at requirements analysis. I didn't correctly analyze the requirements for wearing socks.

So anyway, it includes some Web Project Guide swag and the ability to add a personal note. But we also have a digital copy of the Web Project Guide that's direct on our site. So if you're not an Amazon fan, we've got you covered. And as always, you can order all of that directly from order.webproject.guide. And then finally, this is your monthly reminder. Leave us a review on Amazon for the book, or leave us a review on Apple Podcasts or whatever podcast app you follow. I'm going to start reading some of these positive reviews as long as we get some positive reviews. So get out there. If you want to hear your thoughts on this podcast, I will do it. And I will even send you a pair of socks. I'll send somebody a pair of socks. I'm not going to send everyone a pair of socks.

Trust me when I tell you to wear them on your feet.

They go on your feet is the important thing to know. And anyway. With that, thank you for joining us for another month. Subscribe, share. Check us out next month when we continue the CMS discussion into actually selecting a tool. And until then, go do amazing things.

Good luck.