2020: Omnichannel presentation

Beyond marcomm: Bringing techcomm insights to editorial communications

The TechComm community has pioneered forward-thinking solutions to some of the publishing world’s tangliest challenges, but it’s taken decades for the community’s insights to reach the broader world of digital publishing.

Recent emphasis on TechComm/MarComm collaboration has brought marketers to the table, but it’s possible to think even bigger. The world of “editorial communications” encompasses news, entertainment, and “content as a product” — and it’s in desperate need of TechComm’s experience.


What you’ll learn

  • Understand the differing requirements and pressures that define the Tech, Marketing, and Editorial communications ecosystems
  • Compare what the Editorial world is doing well, and where they’re hurting
  • Identify TechComm principles and tactics that translate well to Editorial
  • Learn TechComm principles shaped “Web Replatforming” projects for NBC Universal and the State of Georgia

OmniXConf 2020 - Jeff Eaton.m4a - powered by Happy Scribe

News tomorrow. Welcome, folks who've joined us. We're just waiting for people to to get in here and we will get started in just a moment or two. All right. I'm going to go ahead and. Get started here. Since we're a few minutes after start time. Just. All right, so welcome, everyone, to Beyond Marcom, I am Carrie. And I'm moderating today's session with Jeff Eaton. Just a little housekeeping before we get started.

If you have questions during the presentation, please type them into the question box on in your resume control panel and we will read them out and answer as many as we can. At the end of the session. So before we get started today, we have a one minute video from our sponsor. So, Jeff, I'm going to take take control of the screen here and play that video. And see if we can make this work. Speed collaborate.

All right. Sorry, folks. All right. Is your documentation uncertain? An orderly, chaotic, confusing? Is your documentation a mess? Content becomes isolated and disparate between different systems, emails and departments. This affects all your business outcomes. Speed, collaboration, customer satisfaction and the bottom line are all at stake. The typical documentation timeline looks something like this, but in reality, each state has unique challenges and bottlenecks that stem from our content mess.

Reviewing, in particular, is often brought to a standstill by old fashioned workflows and product experts short on time. You can solve these problems by centralizing your documentation review cycles and all activities into one system. Easy did. It is specifically designed as the single source system for your documentation, fully collaborative, cloud based and faster than any other system. Easy do the centralizes your documentation development from start to review to publish. All right. So Patrick Bozek from Easy Data is presenting in the next session.

So be sure to check him out and learn more about that. And Jeff. Yep. Go ahead and share your screen. And so let me tell you a little about Jeff. If you're not familiar with him, as I am, Jeff Eaton helps large and small companies build, deploy and manage their own publishing systems. Are publishing platforms as a digital digital strategist. I love about Jeff has worked with clients including NBC Universal, Fast Company magazine, World Wrestling Entertainment, Harvard University, MSNBC, IBM and many more with acronyms and without.

He is a frequent writer and speaker at Web and open source conferences and the host of Insert Content Here Content strategy podcast. He is also co-author of the first edition of O'Reilly Media is using Drupal. He has a previous life as a freelance writer and copy editor and thinks of those fondly while designing editorial tools for today's content teams. Now, Jeff's work has influenced my own over the last few years, and I think the digital world is better for having him share his ideas.

So I'm looking forward to what Jeff has to tell us about editorial communications today, and I'm sure that we'll all learn a lot. So with that, over to you, Jeff. Well, thank you very much, Carrie.

It's a pleasure to be here. And I have to say, it's mutual. The stuff you've brought to the ecosystem has been really fantastic. So hopefully this will live up to the hype raise. Hi, everybody.

So beyond Marcom, the title of this talk, I realized after I had submitted the talk that it implied a certain sense of leaving something behind, like moving from A to B, and I don't think that's quite the right impression to to be clear what we're going to be talking.

What I'm going to be talking about here is stepping back and sort of looking at things differently because there's some pretty significant divides in the digital publishing world and the digital content management world and understanding how sort of those different subcultures, the different needs that they have, how they interact, and also how they're the same and how we can learn lessons in one and transfer them to the other. That can be really valuable. And that's what this is going to be about.

As Gary said, I'm Jeffie and I work for a company called A Little about it. We have content in particular a lot of my work as it is.

It involves coordinating between design and communication and development teams and making sure that the content architecture work that's being done takes into account the perspectives of all those different teams because they're all necessary for a project to really succeed. And to be clear. This is a highly opinionated talk with subjective takes a lot of stuff.

I think it's I think it represents accurately the way that the way things work. But if not, feel free to yell at me on Twitter or dive in. I'm always happy to jump into a conversation about this stuff. So it's all about items to work as carries a fairly hefty content management projects. You know, originally we started doing education around CMF and development and architecture and then moved into a lot of work with entertainment and media companies and then went from there to a large enterprise stacks.

And now more and more of the clients we work with are doing large marketing Web sites. And I think that transition to me is an interesting one, because we went from clients that generally treat their content as a product to sell in the world of entertainment and media into traditional like knowledge management organizations, knowledge bases, internal systems, stuff like that. And the marketing teams that we're working with are more solidly on the marketing side of things where a lot of energy is focused today.

And wrestling with the challenges about how those different ecosystems worked has brought me in contact with some really different subcultures in the content management and content strategy world. For folks who aren't necessarily familiar with some of those catchphrases like tech. Com Markham. Stuff like that.

I'll do a quick. Possibly unfairly reductive summary, technical communications is a discipline that really has its roots in, like documentation's support, authoring of content that will need to educate or inform users and generally needs to be reused across lots of different channels like the classic tech. Com use cases like. Support support Web site for a product or the actual manuals for a piece of software, something that needs to live on the web. B Luigino live in PDAF, you know, to be captured as an actual print manual, stuff like that.

And one of the things that comes out of that history is a really strong emphasis on structure and meaning over appearance. So things like capturing data in formats like X, Amelle and did and stuff like that, and then transforming them into all of those destinations rather than using something like, you know, you know, WordPress or what not to just, you know, pop out a Web site really quick. Those are big parts of the tech com communities emphasis.

And I like to say that, you know, the sort of defining quote of the tech com world is that all content should be semantically structured. Data and presentation is someone else's concern. It's a separate concern about transforming that meaningful data into something in a particular media.

It's not always quite that reductive, but I'd say that's like the core position statement in the marketing communications world.

There's a very different emphasis. There's a history of what I like to think of as high touch content, things where there's a lot of, you know, significant variation from one media, one one media to another. There might be like a design system that unites how the web and print work, but there's a lot of tailoring for each individual, for each individual output format. And there's a high there's a high focus, unlike campaign oriented communications, that has made long term reuse of content a lot less of an emphasis than tech.

Com world. That said, the growing popularity of like multi-channel and omni channel communications and marketing has meant that a lot of the need for like single sourcing content and creating it once and reusing it in lots of places has become much more important in the marketing world, too.

And if I were to again reductively summarize like the marketing communications, like worlds sort of defining perspective, it's that all content is ultimately marketing content because it can affect a customer's decision to purchase, whether it's support or a sales brochure or copy on the Web site or something like that. All of those things are touch points with a customer and are important to the overall marketing journey.

And the third category, something that in the title I referred to as editorial communications, there is not necessarily like a really catchy, like a one word phrase here that ends with calm the way there are for tech common marcom.

But the idea here is that this is organizations where like producing the content is the actual like mission of the organization itself. And, you know, that could be, you know, news. You know, publishing news stories is the mission of The New York Times, not something they do as a marketing effort, not something they do to support the the printed newspaper product. It's it is the actual material that people care about when they come to The New York Times.

It also covers a lot of organizations like non-profits and stuff like that, where it's part of their mission to publish this stuff. And it's what people come to them for.

A lot of the near a lot of the narrative and technical structure of content in this world is inherited from from news media because, you know, long before digital see masses were out there, newsmedia was really on the front end of the, like, pioneering, you know, edge of using technology to distribute and transmit their news. Some of the earliest to digital sites were actually newspapers, you know, that had been there were newspapers with Bebe yesses out there, stuff like that.

And a lot of them also made an early shift to the dynamic web and even using content API to distribute their stuff. NPR, the National Public Radio in the United States was the pioneer of the co-op methods like create once, publish everywhere, you know, creating a single unified API to store their content and republish it on dozens of different Web sites.

That said, outside of pure news, the editorial communications world just hasn't been as. As. It hasn't engaged as vigorously with a lot of the complicated problems that the technical communications world has has. And as the OmnichannelX, you know, multi-device world has sort of overtaken everything, the world of content as a product and editorial communications has really started to encounter a lot of the tinkly problems. The tech com world chewed on years and years ago when they were trying to figure out stuff like how do we create a single document that can be translated into nine different languages, be printed as a, you know, manual and go to PDAF and go to Web without losing its fidelity.

And that idea that these different these different ecosystems have a shared set of problems and can learn effectively from each other is really the heart of this. That said, as you might guess, every one of these ecosystems sort of has a very distinct perspective that centers their way of approaching this continent. Like the sort of reductive quote here for editorial communications or content as a product is basically that in the future, every company is going to be a content publishing company.

And you can hear that echoed in a lot of discussion about the importance of content publishing. People coming from this perspective are basically saying, you know, everybody's going to have to approach things like a media company if they're going to succeed.

And, you know, I think there's truth in every single one of those statements and sometimes that desire for each one of these communities to argue vigorously for their way of approaching things and their philosophy for things can obscure, can obscure the unique needs that they're bringing to the table.

So I'm going to step back for a little bit and start talking about like what the actual real differences are between them and how how we can understand their similarities.

One of the pairs of questions I found really useful is whose needs are driving the creation of the content and how is the expense of creating that content justified?

Because content is never free to create even when, you know, user generated content, which was such a huge buzzword for a long time, is being used. There's a cost to acquiring and supporting and maintaining and keeping the users who are generating stuff engaged.

So the fun part is this means it's time for a quadrant. I love making quadrants.

The first axis, the. Who is this being created for? Whose needs are driving? It is basically like at the spectrum from the producer of the content to the audience of the content, who, you know, which set of needs is more dominant in driving creation. And this isn't a moral judgment. Different people can also regard the content in different ways.

But the idea is that if my needs as if my needs as an organization are what calls are, what causes the content to grow and be created, vs. an audience that is out there actively looking for something and desiring it and trying to hunt it down and find it and consume it. That's what, you know, controls where on this line it goes content by like a nonprofit dedicated to fighting climate change is producer driven in a lot of cases. So there isn't necessarily like, you know, a moral judgment on producer driven content.

But a lot of entertainment and news media is all very audience driven. If somebody is going out there and looking for like the latest, you know, the latest episode of a TV show or something like that online, that's very much audience driven. And it would be farther from, you know, farther the audience on the spectrum.

The other axis is how is the expense justified? Is it basically considered a cost of doing business? We have to do this in order to, you know, in order to avoid some problem coming up in the future, whether its users don't know how to understand our system or there will be legal issues if we don't, you know, spell out this information effectively or something like that or something like that.

Or is it basically something that we consider part of the revenue generation process?

This doesn't mean how much does it cost to make, but rather like what's the payoff? Once we've made the content, is it going to reduce our costs or is it going to increase our revenue?

And the interesting thing to me is that looking at the content for an organization or even for a different a particular section of an organization's digital publishing efforts can really help under.

Some of the differences in where these different ecosystems lie, like the marketing team. Almost everything that they produce is generally. Is generally producer driven. You know, it's it's the need of an organization to tell the world about what it does. But it's also considered part of the revenue generation process.

You know, if the marketing team does its job, then more people buy product and revenue goes up on the floor. On the other side of the on the other corner, you have classic technical communications. Now, there are always variations to this. But traditionally, technical communications is an audience driven type of content. It's someone needs to understand how something works or they need specifications on a product or they need to talk to someone and get information about something.

You learn how to use a feature. Those are things that they're a felt need by the person who's consuming the content.

And generally, they're considered a cost to produce. You know, creating the manuals for Adobe Photoshop is something that Adobe does because they need to provide that service, you know, in order for people to to, you know, use their product effectively. It's not necessarily something that's going to drive new purchases. Now, again, that interplay we discussed between marketing and technical communications, everything that you do and interacting with a client is part of the marketing effort can blur these distinctions a bit.

But generally speaking, tech? Com is its benefit is a reduction in cost reduction in the overhead necessary to publish in lots of different ways or to, you know, staff, you know, support systems and stuff like that.

The content is a product.

This editorial communications zone that we talked about generally lives at the Revenue Plus Audience Square.

Basically, its content that people are going out there and seeking and content that the the the goal of it is to generate new revenue, either by selling the content itself to the audience or via ad revenues or something like that.

And the interesting thing is that some of the some of the crossover stuff we've discussed, it makes sense why it tends to straddle all of those different lines when viewed in this in this sort of model, marketing like product specification sheets. Those are useful for the technical community, technical communications perspective, but they also live in the marketing zone when they're used as part of, like, you know, customer discovery or, you know, investigation about what product they should buy, things like.

Online education tends to live in the middle zone between content as a product and technical communications, because a lot of the a lot of the challenges that are faced in producing educational content are very familiar to the tech. Com world, even if the educational materials are being sold as a product. So the solutions and the approaches that need to be taken tend to straddle the editorial, digital publishing and tech hub worlds and content marketing.

Everybody's favorite hot trend of forever is basically it lives between marketing and content as a product. The idea is that it's not simply marketing that involves content because all marketing does, but it's marketing that it content marketing is basically the creation of content product that an audience desires and wants to seek out on its own merits, and then using that content product as a way to market your services. It's basically creating something valuable to the audience and essentially giving it away for free in order to affect, you know, in order to make your marketing messages more effective.

And that puts it in the revenue zone, but sort of straddles the audience versus producer perspective. And there's also this square corporate communications that I'm not going to dig into in this presentation. But it's an interesting one as well. It applies to a lot of things like non-profits, NGOs, stuff like that, where their producer driven messages are like missional messages that are the reason an organization exists. But they're trying to get it out there to an audience.

But it's also but it's fundamentally a cost because what they're trying to do is affect a societal change or get adoption of a message. And thus the content that they create is a cost of doing business rather than a revenue driver. But again, we're not going to dig too much into that particular quadrant. We're talking about the marketing and telecom and how that intersects with the. Does a product stop? So that said, with a fund quadrant out of the way, I'm going to dig into a couple examples of our clients that we've worked with that illustrate the differences.

The state of Georgia, it's a project that we recently worked on. They basically had about one hundred plus difference government agencies for the state and with high value contests scattered across those 100 or so sites and they were replant forming to a new CNS. They had some, you know, limited multi-channel delivery. But the web was the web was where they were managing most of their content. But interestingly enough, the Web had evolved into sort of a chokepoint for, you know, the distribution of paper forms in PDAF format that offices then printed and handed out to people who came in.

It also was the single point of like official information for call centers and other online guides. And that meant that prioritizing accuracy and approachability in the content was really critical across those hundred agencies. And making sure that things were consistent was absolutely like a top priority. And just to make things interesting, the people staffing those hundred agencies weren't necessarily Web content producers, you know, by trade. They were subject matter experts or, you know, agency, you know, staffers who they had they often had other jobs than keeping the Web site updated.

So they needed tooling that supported that and content architecture that really facilitated all of those widely varied needs in.

Because this was at its heart, a standard tech come kind of scenario. There is a familiar sort of structure that was formed, the real heart of the content. Basically, they had topics which were any different, any piece of information that really needed to be communicated effectively to the public collections that allowed them to keep topics and sort of contain them with each other, and then explainer articles that were more narrative and function and write touch on how different, you know, and how multi topic processes that people would need to go through.

Like, for example, moving to the state of Georgia touches on multiple different agencies, multiple different legal requirements, licenses, all kinds of stuff. So they needed to be able to write things that spanned, crossed all of those different boundaries in because they needed to track information effectively between different agencies and sometimes even with external Web sites.

They also had a system of citations so that individuals who were creating content could flag a page as if like an individual topic, as depending on other topics. It didn't necessarily track the individual pieces of information that were used from one topic to another, but it allowed editors to sort of watch and see that a given topic had changed. I should go and double check the topics that depend on it or use information from it. And then there was also a system, a very granular sort of factual data like contact phone numbers.

Important dates like when taxes are due. Stuff like that of reuseable page components like charts and graphs that needed to be updated frequently and downloads like public forms and stuff like that. That basic structure, again, has a very strong technical communications bent. It's concerned with accuracy. Reusability, stuff like that. And I think it worked fairly well. And those defining characteristics that it's critical public content that state residents needed. That subject matter experts needed supporting new needed structure that would sort of keep them on the right track.

That citation tracking would help, you know, keep things under control for content managers. I'm in an ad hoc collections to organize them. Those are very tech com ways of doing things. Although there was some control over like visual presentation and, you know, custom messaging that didn't really live inside of, you know, highly structured content system. A lot of these needs were classic tech.

Now, in contrast, IBM, another one of the companies that we work with had what drove their transition in this story.

It was basically dozens and dozens of different Web sites. As you might imagine, IBM is huge and they've actually acquired lots of other companies. And a number of years ago, they tackled the challenge of how to unify their CNS. How do you find the same message they were using?

A lot of it was also taking the legacy of, you know, of disparate systems, even static, H.T., Amelle, stuff like that, and pulling them together into a unified face for the world and for their marketing communications.

They had a design system with a. Model that looked great and they loved, but they needed to build a CMF that supported it. Now, this was a Web only project. But they also had millions upon millions of pages to wrangle.

And the approach that they took was definitely shaped by that. They had you know, they had lots of atomic content for things like articles, case studies, you know, interviews, things like that that supported their marketing messages.

But core pages for product, stuff like that were essentially a container page with a header component and any number of mixin and matchable design components from their pattern oriented design system that can be used to communicate different messages. So someone assembling a page would say, what do we need to say? What are the sort of presentational tools that make sense for that and assemble a page out of those things and conclude with a call to action module. And then they can be linked with related topics.

Now, from classic technical communication standpoint, this is like terrifyingly imprecise because the the structure of the content itself doesn't capture what is one component versus another, but for for what they needed. It actually got them to a unified system much more quickly than they would have been able to, trying to model out every possible permutation of structural messages across all of their different properties. Now now they're in the process of mining a lot of those patterns to develop more symmetric model.

But this is sort of the transitional form.

And so, again, that's reusable assets, a pattern based page builder and a sort of phased cultural migration away from H.T. metal towards more consistency.

And this, while not necessarily, you know, not a lot of marketing organizations are operating at IBM scale, but this kind of pattern, a slow move from campaign oriented, ephemeral content that gets, you know, discarded or goes stale once it's not in use towards a more dynamic living site that's managed on an ongoing basis. That's a very common kind of transition. Technical communications, things the marketing world is learning are really about figuring out how to make more effective and ongoing use of that stuff.

The final example here is on the is on the sort of content as a product side of things. NBC Universal was in the process of designing one OmnichannelX content API to market and deliver all of their content for literally dozens of distinct brands.

For people who aren't familiar with NBC Universal, they have, you know, dozens of different channels and brands that they wanted to unify on a single shared system for greater efficiency and the ability to, you know, pipe their content to everything from Web sites, phones, set top boxes. And, you know, partner API ecosystems, stuff like that.

And it was easy to model like the different atoms of their content assets. Think they think they had a strong, like common business domain aspect like shows have seasons and seasons, have episodes and their movies and their characters. The complexity was in the brand specific ways that things needed to be organized, new curated. For example, the Oxygen Reality TV network had different needs than the sci fi channel.

So a lot of, you know, the core of it was fairly simple. The idea was that their editorial content and entertainment media was sort of, you know, useful atoms of content that people would come for, were organized into collections. And each collection could have an abstract style associated with things like featured or rotators versus grid, stuff like that. The relationship between a given piece of media and the collection it appeared in could have other metadata hung off of it, like should this have some sort of sticker like New or watch now associated with it?

Should it be a high priority or a low priority item in this collection? Should it have a visual emphasis or should it just be treated as the same as everything else in terms of how it's how it's rendered inside of that collection? And then collections could also be nested inside of each other? Some of these same things.

The idea was that this relatively simple organizational structure gave them a lot of flexibility to express the different things that different brands were doing in organizing and remixing and reusing the content. And then it could be up to each brand to design a front. And presentation layer for their Web sites or their apps or what not. They use that information in distinctive ways. It meant that, you know, basically they they had those domain heavy, you know, those data heavy domain entities that captured the captured stuff that was common across every single property, that reams of text, video and images.

But the real magic was in those wrappers that were optimized for rapid remixing and abstracted out the design choices. And this gave them the benefit of being able to repurpose the core content assets fairly easily and handle a lot of their editorial and brand specific variation in those wrappers in the design layer. It's not quite technical communications, but it had a lot of very tech come style approaches to solving these problems. And it was a huge benefit for them. So so stepping back, like, what's the common stuff going on here?

And Jeff, just let you know there's five minutes left. Five minutes. Oh, goodness. OK, I'll I'll zoom through the last bit of this. I think it's one sort of final set of concepts. Thank you, though.

So the core unifying challenges here are quality content. It is expensive. Whether it's marketing materials, core product or, you know, or technical support and tech stuff, the more channels that it's being produced and distributed on, the more money is necessary to invest in it. And the more competition that's out there, the more different places, the more need for that content. There is the more we tend to produce. And that sort of that circle of doom is what can make a lot of these projects so expensive and difficult.

And the traditional answer to that structured content something that we love and the technical communications world and even the marcom world is starting to starting to sort of get religion about is the promise is that structured content and content reuse solve those problems by sort of breaking the circle at the putting it out in more places takes more money. But the why behind that, why structure helps and why reuse helps are often opaque for stakeholders and decision makers and people who are tackling those projects because there isn't anything necessarily inherently structure that structure or reuse solve in and of themselves.

And in some ways it fails to resonate because it's a little like telling somebody who's exhausted you should take up jogging. You know, you're spending all this money on creating content. What you should now do is to redo all of it, to add more structure. And while that may help with your energy levels, it just sounds like more work when offered without context.

So there's one final, like set of ideas that I will take away that I want to wrap up before we close. It's the what things we need from our content rather than just capturing the idea of it should be more structured or we should have more reuse. What are we asking of the content? The first thing that is commonly out there is consistency. Basically, content of a given kind has a common structure, a common pattern, regardless of who created it.

I think of that as sort of like the Big Mac. You know, McDonald's has invested a lot of resources in making sure that one Big Mac always tastes and looks and feels the same regardless of where it was created. Versatility is the idea that if you create your content, it can be used in lots of different contexts, not just a particular kind of page or in particular, you know, a particular marketing campaign. Longevity is also important. It's often one of the considerations with reuse.

The idea is that once it's created, content can retain its value to an organization or to the end user. Without additional investment, sometimes this is called like evergreen content modularity.

Also, a big, big, happy, happy theme in tech come is the idea that content is made of parts that can be teased, apart and separated and assembled in different ways. If anybody is familiar with Taco Bell in the US, the the running joke is that every food you can buy at Taco Bell is basically the same seven ingredients reshuffled in various ways. Possibility is something that highly structured content often has as a benefit. The idea is that the properties of that content and its characteristics can be easily and meaningfully access.

You can go in and say, I want all products to contain nuts or packages that contain more than 10 servings and generate subsets of content or remixes that depend on those properties. But that's only possible if that information is there in a form that can be automat. We teased out and acted upon. Fidelity, it's the idea that if a piece of content is used in multiple places or over multiple times, you know, over its lifespan, it retains its meaning and accuracy regardless of the context.

Copying and pasting content from it into multiple places is sort of the antithesis of this, because the instances fall out of sync with each other. And validity is the final one that I run into. A lot of the idea that content of a given type is guaranteed to always follow consistent rules for people who don't recognize that image. It's the KFC waffle down. It is a waffle between two P. Sorry, it is a waffle sandwiched between two pieces of fried chicken and it is not a sandwich.

According to Q Bruel dot com, the official law, the official philosophy Web site of whether things are sandwiches or not.

And it's the idea is that it may look Sanwa cheap, but it does not actually follow the rules. So building a system that delivers all of those things is punishingly difficult and sometimes impossible. It's easy build structure that seems rigorous but works against the project's goals. Like in Georgia's case, preserving information fidelity without sacrificing versus Hilty was a very different challenge. They needed to make sure that messages were accurate. Even if they had to reuse them in multiple places.

And IBM, the challenges, the challenge was adding validity, making sure that everything adhered to a particular design system. But that didn't necessarily ensure consistency. Every page wasn't necessarily doing messaging the same way just because it was valid according to their design system. And they had to choose which one of those to target first. And NBC in comparison, was actually fairly simple from a conflict between those different, you know, those different needs standpoint. But still, things had to be prioritized.

So the answer is why structure? Why reuse? The answer is that it could be all of those things and that tech.

Com Mark. Com and editorial communications all benefit from each one of those things. Different projects will need them in different combinations and they share a lot of those same kinds of underlying dynamics. And no matter what the label, the boundaries can be fuzzy. And, you know, we can tease out patterns from one type of from one type of content and learn how to apply to others in ways that are really valuable, because communications fundamentally is about content and all of these things are communications.

So in conclusion. When I'm trying to figure out what lessons can be applied from one of these ecosystems to another, I tend to ask, you know, whose needs are driving creation? How do we measure success? That's how I understand where sort of on that quadrant it lives. And why do we want structure? And when do we care about content reuse? What's the context for that? So in conclusion, thanks for coming. If you want to heckle me, I'm on Twitter at Eton.

You can drop me an e-mail at Jeff at Eton if y if you want to talk shop. Read more at my Web site or hire the robot team. Thank you very much. Any questions and conclusion? Thanks, Jeff. Lots of lots of good stuff there for for us to think about.

So I have a question. You gave some examples of big organizations teaming and unifying their content. And I think we all know that all too often bureaucracy gets in the way of doing that. What do you think is the key to getting ready or being ready for this type of transfer to transformation? So kind of like what do your clients have in common that they're ready to tackle these things, that that sort of circle of doom of the, you know, content is expensive to produce.

Putting it out in more places require it requires more time and more expense. And more competition tends to be solved by organizations by putting out more competent or putting out more content. That sort of circle of doom is what a lot of clients I work with are facing. Either they've, you know, gotten swamped by how much they have or they need to figure out how to do more with, you know, with the tools and the team that they have.

So they're often at that point of need, even if they don't necessarily have, like, a clear grasp on, like why they should. Do you know, why they should be tackling content architecture or something like that? They've been told that they ought to. And getting them from we're in a point of pain, too. We've bought in on an approach that will solve this is is often a matter of. And this is sort of where that breakdown of the different things we ask of our content comes from.

I found that that is a lot more effective than simply advocating for structure and reuse and citing generic benefits of those things, because often things like, you know, we need more flexibility in how we move content from one context to another or we have a fidelity problem. Once information gets entered onto the site, it never gets updated and people just copy and paste it from one place to another to another. Those are often much closer to the identified problems that people see on a day to day basis.

Structure can solve those things, but focusing on the why we're adding structure really helps get that by.

Yeah. I just. I know we started a little bit late somewhere. Take one more question if I go nowhere at time. This is from Lesa. If you were to suggest a path forward for a marcom team to adopt content reuse processes, where would you start? And do you have any good examples of teams doing this?

So this is partially the lessons from the IBM team. I would say that you should absolutely start with the most with the most atomic pieces of content that, you know, are going to get reused. If there are things like fact sheets or, you know, product support materials or case studies or a client quotes anything that you feel like there's inherent value in it, being able to be reused in lots of places and a clear understanding of what its structure is consistently focused on those areas.

First, and don't kill yourself trying to, you know, like model what constitutes the structure of a campaign or how do we do a landing page? A lot of those high level constructs in marketing and communications, at least in my experience, are the most fluid and they tend to change the most over time or, you know, as as needs evolve or trends appear in the market. So be making sure that that your first sort of push goes towards the small chunks of content that you're going to be able to reuse in lots of different contexts that will make experimenting and iterating on the ways of assembling them a lot easier rather than trying to like, you know, solve every semantic problem with what constitutes a campaign versus an event.

It's easier to solve those things when you've solved some of the foundational ones.

All right. Thanks so, Crews. I see your question, but we're out of time, so I'm going to post that in the LinkedIn group, so I'll put that there. And and Jeff can answer and others can can chime in with with some discussion over on LinkedIn. So be sure to check that out. And with that, we'll wrap up. Thank you, Jeff, very much. I think you've given us a lot to contemplate. Always.

Never a disappointment. I should say so. Thank you. And thank you all for for joining us. And in enjoy the rest of your day at the conference. And we'll. I'll see you tomorrow at least. So take care of one.