Deane Barker: Content Management and Modeling – Episode 111

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS

Content programs need to be guided by a sound model and built on a strong foundation. They need to put people first but to also account for the technical systems that handle the details of turning abstract concepts into tangible and useful content artifacts.

Deane Barker has been modeling and building content management systems for more than 25 years. In this conversation, he shares some of the insights gleaned during his long and successful career.

We talked about:

• his work at Optimizely (formerly Episerver) on the CMS component of their digital experience platform (DXP)
• the importance of reifying abstract concepts with a content model before trying to put them into a content management system (CMS)
• how content modeling provides a solid foundation for a content program
• the consequences of failing to model your content at the correct level of granularity
• the hazards of embedding logic in rich-text content objects
• the “smell” of bad content modeling
• the crucial differences between suggestive and literal wireframes
• how CMSs are fundamentally about setting boundaries around content and the benefitsw of using boundaries
• the importance of crafting a good editorial experience
• the three levels of content: content, artifact, and qualia (the user’s experience of the content)
• the difference between content authoring and content producing
• the “race to the middle” in the CMS world: headless CMSs adding artifact-creating capabilities and conventional CMSs providing content-management APIs
• the concept of the MRU, a minimum reusable unit of content
• the failure of many organizations to follow through on content-personalization plans
• the crucial role of understanding human behavior to do good content work

Deane’s bio

Deane Barker is the Senior Director of Content Management Strategy at Optimizely. He’s been working in content management for 25 years and has written four books about the patterns and practices of modeling, creating, managing, and delivering digital content, including “Web Content Management: Systems, Features, and Best Practices” for O’Reilly Media, and the “Web Project Guide: From Spark to Launch and Beyond,” published in Summer 2021.

Connect with Deane online

• DeaneBarker.net
• LinkedIn
• Twitter

Deane’s books

• Web Project Guide: From Spark to Launch and Beyond, 2021
• Things You Should Know: 25 Lessons I’ve Learned About Buying Content Technology and Services, 2020
• Real World Content Modeling: A Field Guide to CMS Features and Architecture, 2019
• Web Content Management: Systems, Features, and Best Practices, 2016

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 111. When you’re creating a content program, it needs to be guided by a sound model and built on a strong foundation. It needs to put people first but to also account for the technical systems that handle the details of turning abstract concepts into tangible and useful content artifacts. Few people have as much experience with modeling and building content systems as Deane Barker. In this conversation, he shares insights gleaned in his 25-year content-management career.

Interview transcript

Larry:
Hi, everyone. Welcome to episode number 111 of the Content Strategy Insights podcast. I’m really happy today to welcome to the show, Deane Barker. Deane is the Senior Director of Content Management Research at Optimizely. So welcome to the show, Deane. Tell the folks a little bit more about what you do there at Optimizely.

Deane:
Thank you very much, Larry. Optimizely used to be known as Episerver, and our core product for many years was a content management system, and we’ve since changed our branding. We’ve become Optimizely and we really sell a larger DXP, digital experience platform, now, including experiment and personalization and all that. But my job is specifically around the CMS, the content management system, portion of our suite. My job is to research the market and talk to good people like you, and talk to customers and find out what they’re looking for and help plan the future development of that product.

Deane:
I am a CMS guy at heart. I’ve been working in CMS for, oh, goodness, 25 years now, and I kind of live, eat, and breathe content management. So my job is to sit around and talk about and think about CMS all day long. So I have the perfect job.

Larry:
I’m a little envious. I’ve been doing this almost as long as you, but doing a lot of different things and your focus is incredible. And it really is hard to imagine anybody is knowledgeable about content management systems.

Deane:
Oh, so it’s funny that you say that, because I just tweeted the other day that… I just turned 50 years old and I’ve now I’ve been working in the CMS industry for 25 years. I’ve written four books about it. I’ve spoken a of conferences about that. I’ve basically, eaten and breathed CMS for over two decades. I am objectively the smartest and most knowledgeable I ever have been in my life, but I feel dumber and dumber every single day. Every day when I wake up, I feel dumber than I was the day before, and I think that’s healthy.

Deane:
I think if you don’t ever feel dumb about your industry and your area of expertise, you’re probably not pushing hard enough. But every single day I feel stupider. This industry moves so fast and it just seems to moving faster every day. So I thank you for saying that, but let me assure you that every single day I have an existential crisis about what I know.

Larry:
I love that. And the way you said that it’s like, yeah, we’re all struggling in our own ways to keep up with this crazy, ever-accelerating pace of change and . . .

Deane:
Anybody who says they know it all, by definition does not.

Larry:
Exactly. One of the first things I’d love to talk about is you’re so knowledgeable about content management systems, but, ideally, before you do a content management system, not always the case, you want to do some modeling of the content that you’re working with. I would assume that’s an optimal way to put together a content program, is to first model it, and then build it. But anyhow, but can you talk just a little bit about how you see the relationship between content modeling and content management?

Deane:
So one of my favorite words is reification. And reification comes from the Latin prefix res, R-E-S, and it means to make real. And so to reify something is to make it real, to make it concrete. And we have abstract notions of content all the time. And I always envision a bunch of people sitting around in a conference room and saying, “Hey, we should create a database for all of our press releases.” Well, that’s a great abstract ideal, but that’s not something a computer can manage. I mean, there’s no CMS in the world that sits back and goes, “Oh, okay, database all your press releases, I’ll handle that.” No, you have to describe this. You have to reify this concept. You have to turn your abstract ideas into concepts that a CMS or a computer can manage.

Deane:
And that means defining what different content types you want, and defining which properties you want on those types, and defining the different validation rules around those types, and defining the different aggregations that you can fit content into. CMSs can do a lot, and they’re very advanced and they can abstract users away from the nuts and bolts of it, but at the end of the day, you need to describe your information.

Deane:
And so I look at content modeling as foundational, and unfortunately, if you screw up the foundation of a building, you have vast problems with the building later on. And the same is really true of content modeling. I think there are very few aspects of content system or a content platform that aren’t impacted by the model in some way, either negatively, by being handicapped by a poor model or positively, by being kind of set free and liberated by a great and flexible model.

Deane:
But to go back to something else that you said there about how you need to model it and then manage it. Models, aren’t static, they change over time, and one of the keys to content modeling is to build your model in such a way that you don’t paint yourself into a corner. And so I agree that you do want to, in general, model before you build something, but at the same time, give yourself some room on the margins, because things are going to change and morph over time. And you need to make sure that your model is flexible enough to adapt. I hope that was helpful.

Larry:
No, it was. And it reminds me, too, that everything is more and more iterative every day it seems like. That every business process, every design process, every content challenge, you don’t just write a book, publish it, and go off . . . All of the content, every little nook and cranny, there’s something iterative going on, so that happens at a high level here. And something you just said, too, makes me think that you might have one or two case studies in mind, when you talk about people painting themselves into a corner. I guess, could you talk about some of the common pitfalls of modeling and management of content?

Deane:
Yeah. So the biggest thing you see is people not making their model granular enough to start and then loading content up and having problems later on. And the example I always use in my college course is, let’s say, that you’re storing a list of people and you just decide to have a name field, and you’ll type the person’s name in this field. Well, then later on, after you’ve got 50,000 people in this, someone comes to you and says, “We’d like to order them by last name.” Well, what do you do now? I mean, you’ve got to somehow turn the singular data in your name field into a first name and a last name field. Because the only we can order by last name, is to isolate the last name.

Deane:
Well, so you think, okay, well, I’ll go through the name field, and I’ll split that on the space. So I’ll take every value and I’ll split at the space. And the first part will be the first name, and the second part will be the last name. Well, that works fine until you get to Mary Jo Smith. Well, what do you do with her? Or you get to my good friend, who’s the mayor of Sioux Falls, his name is Paul TenHaken. So he has a space in his last name.
And so now you’re really painted into a corner. You have 50,000 records in here, and you made a fundamental modeling mistake early on. And how do you fix this without a ton of manual work? And the question is, you probably don’t. You probably don’t. And I’ve seen a case study of this exact thing. And the customer had to go through and count the spaces and all the values in the name field. And if there was a single space, then they used the algorithm, before the single space for the first name and after the single space for the last name. And if it had more than one space, they just compiled the list and a human being had to go through and manually split those up.

Deane:
So that’s an example of painting yourself into a corner. You get into a situation where you made a mistake and then you loaded up your model with content. It’s easy to fix problems when there’s not content in there, but once you get 50,000 content records in there, it gets much, much harder. So anyway, that’s an example. That’s the classic one I use for my college course.

Larry:
Part of what you just said, too, is a reminder of the failures of Lorem ipsum, working with real content. I think just in the issue of names, I’ve come across recently, like a lot of Latin American countries, people have like three, four, five names, sometimes, or you have Cher or Madonna or somebody like that with just one name. It’s . . .

Deane:
And Ethiopian names tend to be just a single. And you run into problems, too, with people depending too much on rich text. A lot of people do things in rich text that they really should model. Like for instance, they create these kind of vast formatting structures like tables of data, when they’re typing the same fields and these tables of data on 50,000 content objects. And what they should really be doing is breaking those fields out to individual fields, individual properties on the model, which they can then validate and then outputting them via templating rather than just rich text. And they don’t come to this realization until they have 3,000 articles written, and then they want to change one thing, and they realize that they have embedded logic in 3,000 different content objects. That’s another common mistake you see.

Larry:
No. And that’s that generic issue we’ve all been dealing with, at least I have and a lot of my friends, for the last 25 years, is that separation of content from its presentation of the manuscript from the publication, all those distinctions. How do you help people, like as a modeler or when you’re working with clients or educating people about, like the course you teach in Graz, how do you alert people to that concern, and then account for it as you’re building your models and your management systems?

Deane:
So just at a certain point, there’s a smell to it. At certain point, bad modeling has a smell, and you can see it right away. And this just comes from being born from experience. I maintain you can’t do a good content model till you’ve screwed up five or six of them. The biggest thing that I do, in a practical sense, is I get whatever artifacts somebody has, wireframes preferably, and I mark up the wireframe, literally, take a pen and I draw circles around all the individual elements of information.

Deane:
And then you have to interrogate your contents strategist or your content domain experts or your content managers, and you have to ask them just the classic question, “Where does this come from? This piece of data that we have in this wireframe, where does this come from?” And then the other question is, “Will that always be there? Will it always be in this format? Will you ever have something else on here that’s not reflected on this wireframe?”

Deane:
The other problem you have when you look at wireframes is wireframes can either be suggestive or literal. And you find this a lot with compositional systems, systems that you can kind of drag page elements around. So you get a wireframe, and I always ask somebody, “Is this wireframe literal? Like, this is the way this page is going to look every single time. Or is it suggestive? Meaning, this is just one way this page might look if you combine the elements in this different way.”

Deane:
We’ve run into those problems. When I was back in professional services, we ran into those problems, where someone gave us a wireframe that we took as literal and it turned out it was just suggestive. And they’re like, “Well, that’s what a page could look like.” I’m like, “Okay, well…” And they’re like, “If I drag this around, then it looks completely different.” And that completely disrupted the model.

Deane:
So I think good modeling practice is a process of interrogation. I mean, you really just have to ask a lot of questions and stage a lot of hypotheticals. Will there be a point in time where you don’t use this field? Will there be a point of time where you have to do something else with this value? Could this value ever be something other than a number? And will there be a point in time where someone doesn’t have a value for this field? You have to start interrogating your content managers and ask them hypotheticals, because the exception becomes the rule.

Deane:
If they tell you, “Well, 99.9% of the time, that’s going to be a number. But every once in a while, we’re going to have to put like a little note in there, a little text note.” Okay, well I have to account for that now. The exception really becomes the rule. And so it is a process of asking a lot of questions. And I maintain, until they develop a sentient wireframe, that can answer questions about out itself, you have to sit down in front of a human being with pieces of paper and a pen, and rip these things apart until you have all of your questions answered.

Larry:
And the way you described that, too, just, it’s sort of like, there will always be edge cases and you want to account for just the fact that there are edge cases in your model. Is that kind of the take home of that?

Deane:
Yeah. I mean, here’s the thing, This is the thing that nobody likes to talk about, CMS is about boundaries, at the end of the day. CMS is about putting boundaries around content. If you have editors that don’t want any boundaries and they want to do anything at any time, well they don’t want to CMS. They want a copy of Microsoft FrontPage is really what they want.

Deane:
CMS is fundamentally about boundaries. We apply boundaries and say, “You have to enter an age value for this person. And that age value has to be an integer and it has to be above zero and less than 120.” And we do that for specific reasons. We do that in exchange for the CMS being able to automatically generate intelligent input fields for us. And we do that in exchange for us being able to apply automation rules. We can order this list of people by age, because we know our model is predictable. We know that everything in there is going to be an integer.

Deane:
So CMS is about boundaries, but we’re implying those boundaries and we’re exchanging them for benefits. And at some point, if you have… I don’t know how to say this without selling pejorative, I want to use the word whiny, but that would come across terrible. But if you have editors that are very, very frustrated by the boundaries that you have put in place, you need to sit down and ask them what benefits they’re will to forgo, and whether they really need a CMS at all. I have seen some editors who really struggled with a CMS, because they literally wanted to do whatever they wanted, whenever they wanted to do it. And if that’s what you want to do, then I’m going to offer that a CMS is not for you.

Larry:
And well, that’s an ongoing point of education for all of us, is that, again, back to that separation of content from its presentation, that so many people – like I come out of book publishing, that was my first career, and you always had that sort of book as the model of how it would look. And you could imagine all kinds of things you could do in there. But even back then, this was way back, we were working with SGML and a content management system, and I had the screws put to me and I kind of figured it out. But I don’t think everybody gets that. Like you just said, you asked the editor what they could and couldn’t tolerate, are there other tools you have for like just generally educating people about that?

Deane:
Yeah. I mean a lot of it depends on the value of the system, too. I mean, when we talk about boundaries, I mean, it’s very true that a CMS is implementing boundaries, but some CMSs are better about it than others. Clunky UIs are problematic, because they introduce more boundaries than they of provide benefits. I mean, so the best way to kind of bring your editors into the fold is to have a good CMS that has usable UI, and is pleasant for them to use. And so they don’t mind the boundaries in exchange for the benefits.

Deane:
If you have what I would call a punitive CMS, that is, very, very complicated to use, the boundaries, loom large and benefits haven’t changed. And so it’s much, much harder to get them on board. So quality of tooling matters. I mean quality of editorial experience is a thing and poor editorial experience is the number one way to make editors turn against their CMS. I always maintain, I was in professional services for 15 years, literally, the number one reason we got work, as people would come to us and say, “My editors hate our CMS.” That was the number one reason we got work. I maintained that a dollar put into editorial experience will save you a $100 in not having to redo your CMS in three years. So good tooling matters, good implementation matters. You very much want to gently apply boundaries without being punitive about it.

Larry:
Have you seen that improve over the years? Because it seems like there’s more attention in the UX field to like enterprise users, like backend authors, as there is to the frontend. Are CMSs in general getting better at that?

Deane:
So what we’re seeing in the space right now, what I’m seeing professionally, I work at Optimizely there, and what we’re seeing professionally is there’s becoming kind of a dichotomy in large organizations between what we call authoring and production. I always maintain it’s three levels. I’m not on video, but I’m using my hands. There’s three levels. The bottom level is content, so you have a single piece of content. The next level is what I would call the artifact level. And those are all the different artifacts you make from that content. So those are like, you make a web page age out of your content clearly and you maybe make an email and an SMS on a social media update. So you may make multiple artifacts out of that one piece of content. And then the third level is what we would call qualia, which is the experience of that content, so that’s the individual human being interacting with the artifact.

Deane:
But if you look at those bottom two levels, a system like Optimizely, which traditionally in the past was a web content management system, it handles both of those two levels. You manage the content in our CMS, and, also, you can build a webpage in our CMS, you have these two levels managed. What we’re seeing with a lot of the new vendors is they’re splitting to one side or the other. Either they’re just managing content, devoid of any presentation, and this would be your typical headless CMS, or they’re just managing presentation, and they’re not really managing content, they’re asking to bring their own content back in.

Deane:
And so this would be like your frontend systems, like Frontastic and Builder.io and Stackbit and things like that. And so, most new vendors that are coming to the party now, they’re either no presentation whatsoever, just the content or they’re all presentation, this is a page composition system where you’re going to drag all these things around on the page. And that’s a different of which we’re calling authoring and production.

Deane:
I think there are content authors that don’t need to be concerned with how the content looks. They literal just need to create the structure of the content. And then there are content producers that they go in and take that content and they adapt it to a particular channel. So you might have someone that comes in and takes a piece of content and adapts it for the web channel. And then some systems like ours, can you do both at the same time.
But so different systems are handling that differently, they’re handling that either or from a content authoring standpoint or a content production standpoint. And I think they are getting better on either side of that line. I’m not seeing a whole lot of systems getting better that do it both at once.

Larry:
Well, that’s interesting because like in the Jamstack world and the decoupled world, they would talk about that as a benefit of that, that like you just manage your content in Kentico or Contentful or Sanity, whatever you do. And you just do the presentation layer in like Frontastic or Gatsby, or some React frontend-

Deane:
What I just have to call out there is that, a lot of headless vendors are now building frontend builders. I mean, Kentico had Kentico Kontent, which is their headless CMS. And they built Kentico Web Spotlight, which is kind of like a web management tool, like a page building tool that’s built on their headless CMS, so effectively they came full circle. Now they have a web content management system, just in two pieces. And now you’re seeing Contentful sort of done the same thing they have Contentful, what’s it called, produce. Yeah. Produce, I think. But they basically have a landing page builder based on Contentful.

Deane:
And Amplience is another, no, Prismic, Prismic is another headless CMS that has like a landing page builder, where you can spatially like drag elements around on a page surface. So what I find interesting is that headless vendors for a long time kind of eschewed the page, the artifact. Like, “We just deal with the content that first level, that second level, the artifact, that’s your problem?” Well, I mean, I think they’re running into red ocean markets, where they’re competing against vendors that have always handled that second layer. And so suddenly they’re building all these artifact management tools, and I think it’s vaguely, cynically, very entertaining to see.

Larry:
That’s so interesting that you see it all kind of re-converging . . .

Deane:
Oh, yeah. It’s what I call the race to the middle.

Larry:
Yeah. The race to the middle. I love that.

Deane:
Right. If you look on the two ends of the spectrum, traditional web content management systems on one end of the spectrum that just generate a HTML, then you have headless CMSs on the other end of the spectrum that just generated JSON, and we’re both racing to the middle. Like in 2015, we released our content delivery API, and we just released our content management API. And we have essentially backed in, I would say, an absolutely world-class headless CMS into a traditional web content management system.

Deane:
And then on the other side, you have headless vendors that just manage content are now backing in web content management systems on top of their headless systems. And this is what I call the race to the middle. And in five years, the concept between a traditional CMS and headless CNS will disappear. I mean, any CMS that wants to stay on the market will do both.

Larry:
Interesting. But, well, let me ask you about this, one of the rationales for the whole decoupled and headless movement is the notion that you need your content to be portable, to go into different channels for different uses. Will those folks in the middle still be able to serve those? Or how ubiquitous and common are those needs actually?

Deane:
So I’m going to drift into seemingly promotional territory, I don’t mean this to be promotional to my employer, but I’ll use my employer as an example. Our system has been around since it was Episerver CMS back in 2004, 2005, I mean, it’s been around for almost 20 years, and it was “headless” all of those years. I mean, we literally turned your content into HTML in the last millisecond before we deliver it. The fact that we generate HTML is incidental. It’s like, if you want HTML, we’ll do that. But it is literally pure data until the last millisecond, before it leaves a server. And I was doing headless projects with Episerver CMS before headless even had a name, because we store the content with some level of purity.

Deane:
We don’t store the content in big globs of HTML. We store it with some level of purity and then we template it kind of at the last minute. And so I think if you’ve been working with the CMS all the years that has never done this, if your traditional web content management system was never able to also serve content headlessly and serve content as pure data, then you’ve been working with the wrong CMS for a long time. When this whole headless trend came out, and I like headless CMS, and I know a lot of headless CMS vendors, and they’re wonderful people and they make great products, but it was kind of more of the same for me. We had been working with content in Episerver CMS for years at the pure data level. And if your system couldn’t do that, then you were on the wrong system.

Larry:
Hey, I want to circle back to something you just said, and I’m kind of stitching this together on the fly, but just something you said about the purity of the content in there, and then going way back in the conversation to when you were talking about rich text formatting and sort of burying some of the structure inside of like one field in a CMS, does that make sense? Are we still teasing out like how to get to that purity level?

Deane:
Yeah. You can’t stop people from doing stupid things with rich text, you can’t. I mean, even a system like, like Optimizely Content Cloud, which provides just phenomenal content modeling capabilities, there’s nothing to stop someone from just loading up a rich text editor. So you can’t save people from themselves. All you can do is make it easier and provide options for them not to do that, and some level of training so that they understand that, if you glob all this stuff up, you’re not going to be able to pull it apart later. So I think that users have always been able to screw themselves over with poor rich text practices and they will be able to in the future, the best thing you can do is just make it easier for them to do it the right way.

Larry:
Hey, one other thing I wanted to ask about, kind of related to that purity and then the sort of the really optimizing the structure of your content. That seems important to things like personalization, the ability to have like little micro chunks of content to put together for a particular instance, how does that fit into the modern andscape?

Deane:
So this comes back to a concept called MRU. MRU is minimum reusable unit, and this comes back to kind of the feel and the experience of building a content model. You certainly want to break your model down. I’ll go back to my name example, right? First name and last name, that’s pretty common breakdown. But you don’t want to break it down so far, so its unworkable. You really only want to break it down to like the minimum reasonable unit of content they’re ever going to use.

Deane:
And that really changed when personalization came out, because with personalization, people wanted to swap out kind of tiny chunks of content in their system, and that can get hard to manage. I mean, you really have to componentize your entire page, essentially, make every thing a component that’s swappable.

Deane:
My only piece of advice there would be don’t bite off more than you can chew. It’s very easy to make your content far more granular than you will ever work with it, because everyone has these grand plans around personalization that almost nobody follows through on. And you can make the world’s most granular and flexible content model that is also the most unpleasant to work with. And that you have no demonstrative proof that your editors will ever actually take advantage of it.

Deane:
And if they don’t take advantage of this incredible granularity you built into your model, then all they’re going to do a year from now is complain about and how hard it is to work with. And your only response is going to be, “I built it that way, because you said you were going to do all the stuff you didn’t actually do.” And so this comes back to just experience around human engineering, what you expect your editors to do and how much tolerance they have for the tedium of breaking things apart that much.

Larry:
That circles right back to when you said, where most of your business comes from is editors complaining-

Deane:
Yes.

Larry:
… about their experience in the system.

Deane:
And when we would look at these… When I was in services, people would come to us and say, “Hey, our editors hate our CMS, so here’s $500,000 to redo this.” And we would look at it and we realized the CMS wasn’t that bad. The implementation was awful. And this is something you run into on the vendor side all the time. We make a very, very competent CMS, world-class leading CMS for one of the big-four DXP platforms. It’s still possible to do an awful implementation with our system.

Deane:
And there are sometimes where it kind of breaks my heart, where I see what a customer, usually a customer, we have a partner network that’s generally very, very competent. But sometimes I’ll see a customer they’re upset that like it doesn’t work as well as they thought it would. And you go in and you see some of the things they’ve done. And it’s like, “Well, this is not right.” I mean, they didn’t want to engage with a partner. They didn’t want to engage with expert services. They didn’t want to go through any training, and to work with an enterprise DXP, does require some effort and some understanding and they’re easy to screw up. They’re easy to do them wrong. And so that’s sometimes kind of heartbreaking.

Larry:
I love that you used the word a few minutes ago, human engineering-

Deane:
Ah, thanks.

Larry:
… that’s a huge …

Deane:
Over our job is social engineering, I maintain, 80% of my job as a CMS consultant and integrator, was not technical. It was getting organizations to communicate. Sometimes you would have a meeting and you would get all these people in an organization around a table, and it was clear. That’s literally the first time they’ve sat down and talked about the subject. You were a therapist. You were like a social lubricant broker to just get people to the table and start talking in a structured way about their needs and their problems.

Deane:
And I had dinner in Copenhagen with two friends, we’d had a little too much to drink, and we were talking about like the ultimate CMS conference that we would have. And we would just invite CMS experts and practitioners. And then we thought, “Well, what guest speakers would we have?” So we started talking about all these guest speakers we could have. And we settled on after an hour of talking about this over Danish beer, that the most productive speakers would be organizational therapists and counselors and organizational psychologists. Because the number one skill you can have as a content strategist or a content platform specialist of any kind is understanding how people think and understand what they’re really saying when they’re not saying something.

Larry:
It was funny, I kind of didn’t expect that to come up in this conversation, because we were so deep in the modeling and systems, but, nope, it’s always about people. That comes up always every episode.

Deane:
Always comes back to humans. I maintain, working in professional services would’ve been great, if not for the people, right? If not for the customers, it would be the greatest job in the world. But I mean, our job is to help people get out of their own way and help them prioritize. Our job is to look at something that somebody thinks is important and evaluate, is that really important? Or something they think is not important, and help them put this list of priorities. Like “This thing that you absolutely love, you’re never going to use this. This is not going to be important. This thing that you don’t think is a big deal, is a very, very big deal,” and help them understand that.

Deane:
I always had a saying about sales was, “The key to sales is putting an idea on somebody else’s head, and making them think they thought of it first.” And that’s the same of consulting. I mean, my job as a consultant was to help them understand what their priorities were, and what was a big deal and what wasn’t a big deal, and make them think they figured that out on their own. God, that sounds cynical. It’s terrible.

Larry:
No, just the way you said that, because this… Everybody jokes, like Kristina Halvorson and everybody I’ve talked to jokes about, “Oh, we’re just really therapists.” And it’s like, there’s real truth in that. And-

Deane:
Oh, it’s true. It’s absolutely true.

Larry:
Yeah. It’s just absolutely the truth. Yeah.

Deane:
And we joke about it, in this kind of dark humor, because it’s like the one shining lighthouse in our industry. It’s the one shining truth we can all gather around. This is why this joke keeps coming up, and it’s not really a joke. We are fundamentally therapists. We help organizations work through their human issues. We just happen to do it in the context of their content platforms.

Larry:
Yeah. Hey, did you and your friend in the bar, in Copenhagen, did you ever actually put that conference together?

Deane:
We didn’t. We thought about doing it on, we found a hotel on a glacier in Iceland. We thought Iceland would good, because it’s halfway between North American and Europe, and we actually never did put it together. And then I recruited him to come work at Optimizely and it’s Mark Demeny, who is now the Senior Director of Contest Strategy here at Optimizely. So maybe now, if Justin Anovick, the Chief Product Officer wants to drop a massive budget bomb on us, maybe we’ll take it off and we’ll go do it.

Larry:
Sounds good. Hey, Deane, I can’t believe it, we’re coming up on time already. Before we wrap up though, I want to make sure, is there anything last, anything that’s come up in the conversation or that’s just on your mind that you want to make sure we share with the folks?

Deane:
I’d be derelict if I didn’t mention that I did publish a new book this summer with Corey Vilhauer. I started a company 15 years ago, I co-founded a company called Blend Interactive. I worked there for 13 years. I hired Corey Vilhauer there as our Director of Strategy, our content strategist there. He has spoken at a bunch of Confabs. He’s pretty well known in the content strategy space. Corey and I started writing a book three and a half years ago. And in the process of writing that book together, I did write two other books, before we finished that.

Deane:
We did actually publish it this summer, it’s called The Web Project Guide. It’s 434 pages of an entire implementation process from start to finish. We divide it up into 24 phases, and we talk about each one. So if you’re staring down an implementation project and you have no idea where to even start, we have a guide that goes from beginning to end. It’s at webproject.guide.

Larry:
Yeah. I’ve read the digital version, it’s a fantastic guide. I can’t imagine anything more comprehensive. I’ll link to that and your other three books in the show notes as well. Well, hey, one very last thing, Deane, how can folks get a hold of you if they want to connect online?

Deane:
I have a website deanebarker.net. Deane has an E on it. It’s really weird, D-E-A-N-E-B-A-R-K-E-R.net. If you go there, all my contact information is there, but I mean, Deane_Barker on Twitter is good too.

Larry:
Great. Well, thanks so much, Deane. I really enjoyed the conversation.

Deane:
It was very fun. Thanks for having me, Larry.