Value Mapping: Building Understanding, Communicating the Benefits of What You Do

>> SPEAKER:  Hey everyone.  So, it's great to be here.  I was really hoping to be in Chicago this week and, um, yeah, but, um, boy, things are crazy.  I don't know where everyone is, but I guess we might as well start with, um, we might as well start with this.  So, let me share my screen, and I'm going to share the whole thing and, um, go into presenting mode.  There we go.  Okay, so, um, I'm going to assume that, um, this is all working, unless Dwayne or somebody jumps in and tells me that it's not.

>> SPEAKER:  Looks good.

>> SPEAKER:  Great.  So, we're talking about a concept, um, called value mapping and how we use it to build understanding internally, um, at, um, and how you can use it internally, um, and then how you can use it to communicate what you do.  As I was saying, I was really hoping to be, um, in Chicago this week, but as the new official logo of the Corona camp shows us, um, boy, things have gotten crazy and strange in the world.  I live in Germany, I'm sitting in my office in Cologne right now, and, um, looks like we're heading into some version of a lockdown within the next couple of days.  The virus wave hit, I think Germany's 5th or 6th now on the list in terms of cases, and the Germany really hit about a week ago, the same that spring hit, so there have been groups of people getting together, playing in the park, grilling, and the authorities are very worried about this, so, um, yeah, it, you know, it's really strange, that the world is getting so small all of a sudden.  I hope everyone out there is okay and healthy and safe and, um, good luck to us all.  

This title slide is branded with sort of my company, so forgive me, MidCamp, for updating that.  Open Strategy Partners, um, I co‑founded it with Tracy Evans.  She, um, would have been my co‑presenter under normal circumstances today, um, and Tracy and I put this company together more than three years ago now, and, basically, I came from a communication background, developer relations and so on, I was the 18th employee at Aquia, and I left in 2017, and, um, after having given, um, something like 150 conference presentations and a couple hundred podcasts and a lot of writing about Drupal and technology and so on, I came out of those experiences with pretty strong ideas about communication and how to communicate with developers and how to do developer relations and how to, um, produce content consistently that was useful to people, and Tracy is an MBA and a businessperson with experience, everything from start‑ups to managing international teams and, um, so she has an actual strategic education and real experience, whereas, at the time, I had, you know, a thousand conversations that I'd had with people, um, like you all around the world and a really good idea of how a bunch of, you know, how open source works and how agencies work and how technology works, but, um, so the, um, we put this together and called ourselves Open Strategy Partners.  

So, the Open Strategy Partners is, in part, we do strategy communications, and we have a special focus on open source.  I guess I have about seven people on my team at this point, and, um, we really want to help you communicate the value of what you do, connect you with the people who need to hear your story, and grow, whatever grow means for you.  So, we help people grow partner programs, get their open source projects adopted, grow sales and revenue in a very caustic sort of marketing function, and whatever it is, and, um, so we feel that our special sauce is that we really understand the open source space and the developer mind in a way that other communication agencies don't, and we have a very strong strategic practice.  So, that's who we are, and I want to share with you one of our key and essential tools, something that we've developed ourselves.  It's really essential for how we work and, um, and I'd really like to get you started on the concept, and that's this thing called value maps.  So, one of the key things that we do is translate between very technical, complex solutions that, um, brilliant people have developed, it's a pretty classic idea that a developer of some kind has created something that's very, very useful, but has a lot of time communicating the value of that to people who are other developers, and we translate between, you know, this complexity and business value.  

Now, if you put yourselves, um, we use Tracy as a persona often for a, um, technology purchasing decision‑maker, a businessperson, um, they get pretty frustrated by, um, companies talking about their stuff, their products, their services, with a lot of buzz words, right, and benefits that have no substance to them, using a lot of technical jargon with no context, with no reference to why I should care, um, different vendors talking about what should be the same things in very different ways, using very different language, which makes it really hard to compare apples to apples, and really inconsistent language, really inconsistent communication around technical features and benefits, and that's really, really frustrating for someone who's trying to choose a technology, and a lot of us in Drupal, in open source, in agency space, are trying to help these people choose the technology that we work, so that, choose the technology that we work with, to use Drupal, today essentially, for this audience, um, so that we can then sell them services or get a job ourselves.  Um, so, this experience is really frustrating, the inconsistent communications, and, um, you know, really, really, we shouldn't trust things that we don't understand, so, you know, if I'm going to engage with your agency, if I'm going to choose the solution that you're presenting, I need to trust, I need to trust that you're going to help me solve my challenges or problems.  

Now, it might be that you, specific decision‑maker, are not going to understand the nuances of some specific PSR standard or something, but you might have someone on your team, you might have a CTO, you might have a senior technical person who can help you, and you have a trust relationship with that person, so if we can inform that technical person in a way that they understand, right, that'll help build trust, and sales of most things are built around trust, and the only way that I can really have that trust is if I clearly understand what your product or service is and what it does and the value that it delivers.  So, I need clarity.  What your thing is, what it does, and the value that it delivers, and I'm going to say that, I don't know, a hundred times today.  Hey Dwayne, I have a question.  Um, do people see me waving my hands into the camera, or can I just stop that? 

>> SPEAKER:  They can see you, if they have the ‑‑

>> SPEAKER:  If they choose it?

>> SPEAKER:  It's possible they could have seen you.

>> SPEAKER:  Okay.  All right, then I'll just keep, um, I'll keep up my hand waving.  It's a habit.

>> SPEAKER:  You won't appear on the recording.

>> SPEAKER:  Okay.  So, for the recording, everyone, I am doing incredibly exciting hand gestures, and you're getting, like, 23 percent of the presentation without seeing it.  I'm totally kidding, but it's my habit.  So, to achieve this clarity, we have a thought framework that we use at OSP that we call authentic communication, and we think that authentic communication should be compelling, and it should be accurate.  Now, looking at this Venn diagram, if you say that authentic communication is at the intersection of empathy, clarity, and trust, that is, um, for a given value of truth, that is what we think about it.  I believe it's actually a, I think it's actually kind of a cycle, and, so, I think that, um, having empathy for your audience, understanding, um, understanding the needs of the person you're trying to reach, the thing that, you know, understanding their needs and challenges and their problems, um, at a fundamental level should help you communicate better with them, and then when you're clear, um, with them about a lot of things, that helps build trust in a very virtuous circle.  

So, when we talk about clarity at Open Strategy Partners, and I want you to think about clarity when you're building your communication, there are a lot of different aspects.  It means writing well, it means not putting in extraneous information, it means not selling fake ware, not using jargon, not committing any of the errors that I talked about upfront that build frustration, um, and when you're thinking about how to communicate, the essential clarity that our value map delivers is what your service or product is and what it does and the value it delivers.  So, the value map is a collection of statements, in the end, starting with statements about the specific features of your product, um, and it gives you a set of accurate and clear and consistent language to talk about, um, your product, that then all stakeholders can use, and I can't advance my slide.  There we go.  So, when we start thinking about building communications, we start with this value map, and I'm going to show you that in some more detail, um, and this feeds into our, um, base strategic framework, and anyone who's at all familiar with marketing, um, will recognize that the target audience persona's buyer journey and strategic narratives, as well as editorial plans and channel planning are very classic marketing, very much what online marketing, digital marketing is made‑up of today.  

Target audience is the kind of organizations and job roles that you think that your product can help, the personas are then examples of specific individuals within those audiences and they're sort of straw men to help create communication at a sort of fictitious person.  The buyer's journey is how I get from seeing a tweet or a blog or a Google ad or a conference presentation or something to whatever your conversion is, downloading your open source, um, project, trying something out, submitting a patch, if we're talking about contribution, or selling a thing, buying a thing.  Strategic narratives are areas where we can find stories to tell over the long‑term, editorial planning and channel and asset planning turn into building actual communications, right?  And the one thing that, the other tool that we've come up with here is a trust and vibrancy signal concept and, um, those of you who build Drupal websites, you'll know that, um, it's always a challenge to say, hey, which module should I use to solve this problem.  You know, traditionally, in the old days, I don't even remember how many image gallery modules there were, but it was a hard choice to make, and, um, over time, you would learn to look at the module repository, see which solution had more downloads than the others, see which had more issues, see how fast the maintainers were able to deal with those issues, and you would build up a sense of trust, um, around which module you thought might do better for your Drupal project in the long run, and we've looked at, um, open source projects and also companies and products in a similar way, um, with these trust and vibrancy signals.  Do I trust that it is going to do what I need?  Um, does it look like it's sustainable and going to survive in the long‑term?  And it's a really, really interesting exercise, and it seems to be a, um, uniquely kind of open source perspective on marketing.  

So, we put all these things together, and after this, we have an entire communication framework, um, modular, also modular that helps us then build communications that support all this strategic work.  So, the value map, and, of course, we have to describe it itself, what it is, what it does, what it delivers, otherwise, you know, it's all smoke and mirrors from my side, the value map itself is a set of living documentation containing an inventory of all features and benefits of a product expressed as value statements.  I promise, I'm not going to read all my slides.  Um, so, that is what it is, and then, um, I know that this sounds very, um, what's the word?  It's like a set of Russian dolls, where I'm just repeating the same sentences over and over again.  Because we build it, um, and because you can build it together with various stakeholders and teams and parts of your organization getting together, the technical people, the design people, the product management, whoever you have, we work together to find all the features and then describe them with the specific language, and our experience, it's really interesting, there's an incredible side benefit to building consensus of understanding, um, because, you know, you have this documentation where everyone has a list of exactly what your product is made‑up of and how to talk about it, which lets you build sales materials or conference presentations or figure out topics to write a blog to, help clarify your audiences, um, the process of building this has helped, um, organizations' unity about, you know, it's really, really hard sometimes, even though we're all working on and building the same thing, it's really, really hard to keep the technical teams and the sales teams and the marketing teams sort of all pulling in the same direction, talking about what we're doing in this same way, and this tool really, really helps, um, building consensus.  

So, you saw on the last statement, and maybe once before already, the last slide rather, this term value statement.  So, a value statement is a very specific term in our case, and every atomic unit of functionality or attribute of your product, we find those, and we write them down, and that's the what it is, what it does, and every single one of those contributes to one or more benefits, right, and they're delivered, singularly or through groups, through work flows or processes or something, and we happen to call those activities usually, so if you take a feature and you put it through an activity, it delivers a benefit, and describing that makes a, um, a value statement for us.  So, this also helps bridge the gap between, um, the technical worlds and the business worlds.  A feature is very much something like, hey, it does wizzy wig, or it does left to right and right to left languages, or it's got drag and drop image positioning, or it supports multiple languages, if we're talking about a CM S, and the benefit of this might be, um, hey, in fact, I'll use, um, I'll tell you a tiny piece of the origin story here.  Exactly what I just said would have been how a project like ours, like Drupal, like, we would have said all these things, and as site builders, as developers, we would understand that we can create altering experiences with those tools, and that means that we have an experience where people can put in content, and they can see roughly what it's going to look like on the site, and they can, you know, format it to what, you know, if you have a wizzy wig editor, so we would understand that, and there's all these pieces, but the business buying persona doesn't think about products generally at this atomic level, they're looking for benefits, and, so, a benefit that Adobe web experience manager was selling a few years ago was, um, business‑friendly authoring, and it's really, really brilliant, because that, if I'm a businessperson, I'm not a technical person, I've got to deal with this web thing, and I'm thinking, oh, it's business‑friendly, well, that's going to be great for me, you know, so the benefits that we talk about are often a little more business flavored, and the features are then the technical area where a lot of us work on a daily basis.  

We work with a really interesting project called Sulu CMS.  It is a full‑stack CMS, and, um, it's really fun, and it's a completely different take on what a CMS can and should be, and I encourage people to go and have a look at it.  They are Open Source friends.  So, if we talk about, um, great developer experience as a business benefit, now a great developer experience is a business benefit, because it means I can hire devs more easily, I can retain devs more easily, if they have a technology experience on a day‑to‑day basis that they enjoy, right?  So, if I'm writing super clean code and I love to work in symphony, um, well, the fact that it's full‑stack symphony, that's a feature, and then it uses the same, it uses a variation of symphonies, system architecture, and it means that if I know symphony, I can step up and be productive in pseudo basically the day I get my developer environment setup, right?  So, the value statement that we would talk about is, hey, it's got a great developer experience, because it is built on symphony completely.  Um, then another really interesting thing about Sulu and its completely different perspective on what a CMS is, there is no clicking anything together, it is really made by developers, for developers, all configuration happens in code, um, so the user experience for the content authors and editors in the back‑end is really, really secure, which is really interesting, because you cannot configure something wrong and break the site, but it turns out that this, that Sulu was created by a very design‑focused agency, and the UX is literally beautiful, and, um, part of the developer experience and part of the user experience is that if I write Sulu code following their coding standards, the UX gets automatically generated, so using the pre‑defined interface elements is the feature, um, and writing the code automatically then delivers this great user experience, the blue line there, so that really, really helps developers deliver better things for the users, which is really satisfying.  Here's some examples.  

Now, it doesn't look nearly as fun when we're working, it looks like very long spreadsheets, and here's actually, here's this business‑friendly authoring term, and, so, we work in a lot of spreadsheets, and we'll compile things and, um, generate sort of pseudo language to find what makes sense and what doesn't, but this is kind of what value mapping on a day‑to‑day basis looks like for us, and we collect these sets of value statements and, um, eventually put them together, and you might have a group of these, um, things that are in a sub area of a product, or it might be your entire product or service, that they get put together, um, into your product positioning statement, and the positioning statement is something, um, it says, if you're an agency, it says who you are and what you do and why and how you deliver value, you know, it's really the essence, as it says on the slide, of the value of what you're delivering and how you deliver it.  So, then, if you have an organization with, perhaps, three products, like this diagram shows, each of the products delivers value at a feature level, at a positioning level, and that goes into the brand level, up at the top.  Also, over to the right, the gray part, um, are features and benefits of the fact that this is a platform, right?  So, um, we discovered working with D dev, I think people are probably familiar with D dev and D dev local, um, D dev is now, um, apart from D dev local, which is the local development environment, which is super fun to use and simplifies and speeds up, um, setting up local development environments, it transformed how we do Drupal contribution sprints and so on.  

Um, they have D dev live hosting now, so D dev local kind of makes docker super easy to use locally.  D dev live, the idea is it makes super needs hosting easy to use as well, and in between those two things, there's a product which they're thinking about launching, which would add some service level, some things you could pay for to get more out of it all.  So, the fact that they have this looking left to right, a dev to deploy platform then creates some value of its own, and then we, all along the way, we're trying to capture this, and we've got agreed upon language, we've got consensus between the teams about what it is, what it does, what it delivers and so on, and this becomes really, really useful when you have to communicate about what you're doing.  So, here's an example of the brand level positioning exercise, um, for the D dev platform, right, for the whole thing that we saw before.  So, the brand level positioning statement, in the shortest version, it only says, hey, D dev to deploy platform helps you deliver your web projects faster, better, simpler, anywhere you need them.  

Now, the trick here, and there are longer versions and test versions here, and it's sort of a matrix of different things that they can work on, um, the thing about this, I'm going to show you how we put this into, um, how we built it and a little about how we put it into practice in a moment, the difference between this set of positioning possibilities and other positioning exercises, and I don't know how many of you have ever gone through the glory that is a positioning exercise, positioning exercises are often top‑down and often very aspirational and, you know, leaders of an organization will be looking around, and they decide who they want their competitors to be and how their level of operations, what they want it to be, and they start designing who they think they should be and, like, pushing down into the organization to try and see if it really fits and if it really works, and it's a lot of, like, seeing if this will work, seeing if that makes sense, and, um, if you've been playing along, you'll notice we started talking about the atomic‑level features of specifically your CMS, you know, is it based on full‑stack symphony or has wizzy wig, the smallest atomic‑level features, they're grouped into functional areas, we write really specific descriptions of the value that they deliver and how they value it, so we have these smaller positioning and benefits along the way, and we collect those, we go up and up and up, and we boil it into these statements, so even if this 19 words might seem placative, might seem simplistic, we could actually break it down through multiple levels, down to specific features, specific functionalities, specific it is open source, following these coding standards, to prove, right, that this is true, and this lets us do two things, and I hope you're listening, um, talking about consensus building was important, um, as developers, it's hard for us, when we're down in the weeds and down in the details, it's hard for us to remember or know sometimes, it's hard to connect ourselves to the value that we're delivering, and if I have a value map available to me, I can see that the feature or functional area that I'm working on, I can look up and see what activities or work flows it's part of and see the business benefits that it's delivering, and if I'm a developer and I want my agency to adopt Drupal, and I've done this sort of thinking, then I can say, hey, this thing that I love to work on, standard compliant PHP code, it'll deliver you these values, and you can have, um, conversations and build communications very much related to the value that your clients or your organization can get out of something, and by the same token, um, you can have sales materials and sales conversations that are based on facts, so there's a lot less, um, frankly, you know, BS in the sales and marketing materials that are created on positioning, that is based on facts and where we can break it down into all these specific areas.  

So, when we do a value map, um, this is how we go about it, and this is how you can go about it, um, when we're looking into a given product or service.  We need to look at who else is doing similar things, and we really need to look at the words that they're using, the language they're using to describe themselves, the concepts that they talk about in general, so we get a feeling for what that industry is.  So, um, I don't need to be a subject‑matter expert to be able to collect and create expert‑level information, if I really, if I do my homework right, so I need to look at the industry that we're in, whatever that is, and then I need to look at the competition, um, if there is any, other people doing similar things, these market‑level cues, what are the features and the benefits that other people talk about delivering when offering similar technology solutions to mine.  Um, at that point, you need to, we find the most effective format are workshops, but between, like, three to six to ten people, and we do online workshops, um, and we're using an online sort of collaboration white boarding tool called Mero that we're very happy with so far, and we setup a space with mixed stakeholder groups, so, like, technical people, businesspeople, design people, clients, even, if we can get them, advocates, um, to collect features and activities and benefits, and because we have done our homework ahead of time, we can precede some of the features and benefits that our competitors say that they're offering and see if we offer them too and see, like, oh, if you offer benefit A, like, what are the activities that deliver that benefit, and therefore what features do we have that feed into this, that give us this benefit, and, so, with the homework in place and with these mixed groups of stakeholders inspiring each other, um, we find that gets the best, the most comprehensive, um, results.  

So, um, we collect this data in these workshops in sort of a mind mappy format, I'll show you that in a second, so step four here, the value map modeling is we need to convert these mind maps into structured data, which means a lot of spreadsheets often.  We at OSP are working on some data‑based ways to express this, and I'm hoping to be able to offer that in the future, but right now, it's, um, it's a lot of spreadsheets that we concatenate, that we filter and so on to come up with these, like, proto‑automated results.  Um, so, the automated results, the drafting, we look at those and we throw out things that are obviously crazy or impossible, and we end up with, um, almost human, you know, usable sentences, and then this feedback stage, we get back with the teams and the experts and the sources for our information, and we show them our work, you know, to check the truth and the accuracy, um, and just have a real reality check, are we on target, are we on the money, and those conversations are also great in a group, because you really get into the weeds and into the essence of what people's jobs are about in relation to the technologies that they're using and, you know, their experiences can differ, and it's really, really fascinating, and that really helps people get on the same page about what this is all about.  

So, the reality check is really helpful, and then you get to work, right?  You have this thing that you've revised, and it's a value map, and it's always a work in progress.  When you add a new feature, when the market shifts, when things change, it needs to be updated, and it needs to stay fresh with you.  So, these value maps, these workshop canvases that we use, um, look something like this, um, basically, it's probably hard to read, the greens are still activities, the pinks are still features, and the blues are benefits.  So, the value map, we're trying to build a collection, we're trying to build a full inventory of value statements, as you know, so, um, we do our research, we put in benefits that we can think of, and, um, benefits are a really, really good, um, place to start this work.  You might have marketing materials for what you do already, and if you do, can you backup everything that you say you can deliver?  That's a really good place to, like, work backwards, if you say you deliver benefit X, scalability or improved ROI, well, what processes deliver that and then what features go into delivering that value.  So, you can already use, um, that sort of mental model to check if the benefits that you're claiming that your product, service, company offers are backed up by, you know, actual features, and, um, really, really typical benefits are really, really typical, business‑y stuff.  So, for almost everything, before you get into your specialist area, before you get into the wacky world of containerized hosting or, you know, agency work for non‑profits or something, um, ROI is a really, you know, how do you deliver improved return on investment, does your thing scale, is it efficient, is it easy to use, does it increase productivity, does it help deliver more consistency, does it help, you know, reliability.  For example, um, in the hosted world, if you talk about reliability, are there automated backdrops?  Hmm, yes.  

All right, what architecture do you use?  What's the frequency?  What's the whatever?  And that gets down to the feature level right away.  So, then, each of these benefits is there, and then, you know, for a medium complex product, there might be this or ten times this many benefits, and then you start filling in the blanks, and any feature can be part of many activities and delivering many benefits and vice versa and so on, and, so, basically, for every activity, you need to say, um, and every benefit, what gives me this benefit, what goes into the activity, does it contribute to the benefit, and then you'll know, um, that you're on target with this stuff.  So, um, this slide, I haven't decided if it makes things much, much clearer or if I'm just muddying the water, but we'll try here.  Every feature delivers one or more benefits through one or more activities.  Okay, so, a technical feature gives us benefit value by being part of the process, and every benefit we get is made‑up of technical or business features that are delivered by activities, right, and therefore every activity delivers benefits through collections of features.  I hope that helps.  It seems really clever to me when I put the slide together, but, um, I can't decide.  So, that's the process of constructing this thing, and I want to talk about the value of using this and the thing where I spend a lot of my time.  I am generally not in the section that builds these things, but I am very much apart of building communications using these, and, so, if you think about communication going from features to benefits, you can think about being a developer and trying to explain to your boss or your boss' boss, um, why standard‑compliant code is important or why automated backdrops are important or why something, and if we go back to my example from a minute ago, I'm just looking at my notes here, right, um, you know, choosing a system that delivers, um, oh, reliability, right?  

So, if we say that the benefit is reliability and I know that the up‑time, um, is important for my revenue and so on, then the business stakeholder understands it needs to be online and needs to make money, and then the reliability is really important and one of the activities that goes into reliability, what that means, but you could also talk about, um, I said automated backups before, and then you can talk about, um, what goes into creating the automated backup work flow and where it's stored and so on, and, so, you, as a highly technical person, can talk about the things that you're comfortable talking about and that you know, but you can link them to a business case, and that's really, really important, and at the same time, if we're creating sales materials that are targeted at the business personas, we're starting at the top and we're working down, I know that I can create sales materials that are backed up by facts, and whoever is telling the sales story is telling a story that is, in the end, possible and real, and that feels really, really important to me, and I think that this is something that distinguishes this way of thinking about marketing from others in that we find out the facts first and then we create communication about them and not in any other order.  So, this is a lot of how my day works, and I think this is really important in terms of connecting each other and bridging this gap between the business world and the technical world.  So, that's the sort of, the essence of the value map, and I want to run you through a few use cases quickly, and I'll read these sort of, I'll read these through sort of as user stories style statements, and then I've got some concrete real world examples to show you as well.  

So, in communication and marketing strategy, um, as a marketer, in order to create my positioning strategy, I need to understand the entire value of my product and all the features it contains, which points, differentiates us, and, so, I can use this to build my communication strategy, the priority of my features, if I look at, if I'm comparing Drupal and, um, Adobe web experience manager, um, you know, one of the features that Adobe is going to talk about all day is the integration with the Adobe creatives, right, and Drupal's integration with Adobe creative suite is terrible, and you'd be a fool to build it, so that's going to be the last priority to communicate on my marketing list about Drupal, right?  So, um, to create a positioning, I need to understand the value that everything about my product or service delivers.  To build my communication strategy, I need to find themes that are relevant and then prioritize them, and to build my communication strategy, I need to have a single source of truth about the features and benefits of my product, so the value map gives us all of those planning campaigns, lets me then tie personas to features and benefits and so on and then communicate with them using the other bits of that strategic framework that I was talking about.  When creating content and communications, if I want to write that compelling and accurate content that I was talking about before, I need a trusted and up‑to‑date source of features and benefits relevant to any given topic within what we do, and, so, I need to note about all the features and benefits of my product to communicate clearly about it, and having these and knowing their priorities can also help me, um, building my website, choosing menu structures, figuring out, um, you know, how we present ourselves online, for example, and then, um, over in the technical and the business world, um, I just told you about the priority of communicating about specific Adobe features for Drupal would be very, very low, um, having this information lets me also build this information about another competing product and then compare them, um, you know, on a real fair level, apples to apples, um, and, so, that helps me understand what I've got as a businessperson, where I can compete and where I shouldn't, but as a technical lead, I need to know about the competition as well and decide what features are important and, you know, what I'm going to plan for and what we're going to build next, and this intelligence, um, helps all of our technical roles, and it helps business roles think about competition and, you know, um, same if you're going for investment money, the same, um, if you're the CEO or leader and you have to talk to the board about where you are in relation to the competition and so on, um, this information is incredibly reusable, and there's a lot of work that goes into putting it together.  

Now, this is a page off of the platform SH website.  Platform SH is not a client of ours, and it never has been, um, but their chief, um, chief developer, evangelism officer, I forget his title, is an old Drupal guy called Robert Douglas, and he happens to be my best friend, and he and I have talked about this stuff a lot, and you'll see a really nice interesting thing.  So, the features row is videos and articles talking about specific features of platform SH at a feature level, um, work flows are collections of features and how they deliver value, and benefits are business‑y stuff broken back down into technical components, and it's really gratifying, to see this out in the wild, and, um, I didn't have to put in any of the work, except I did the screen‑shot myself, so it's nice to see this going on, and Rob and I have talked about this concept on and off a lot, so he's also contributed to the whole space quite a bit.  Um, this is a screen‑shot of part of a website of an agency called B13 in Germany.  They are a client of mine, and their entire website is the product of value mapping and a bunch of, um, other of our processes, but I wanted to show you that, um, so, this is the agency, they specialize in typo three CMS, really, really other interesting way to look at how CMS comes together, and this is the agency of the typo three.  So, on their website, you'll see under the solutions, um, menu item, and those from agencies, you might have been asking yourselves along the way, hey, this is cool, if I've got a product, but how does that relate to me, we only do services, so with B13, we sat down and we figured out what they were good at and what are typical patterns and typical kind of projects that they do, and we came up with, um, highly perfomant sites, media solutions, um, big multilingual projects, and highly complex, um, so, centralized information that is, like, um, building the web presence of an entire hospital system with every doctor, every clinic, every disease and all that, you know, cross‑reference.  So, we did value maps for each of these products, we called them pseudo projects to begin with, I think we call them solution areas now, but we have a value map for each of these, and then we built communication using the, um, using those value maps.  

So, here's a solutions page, where you see a quick description of each of those solution areas, and then we're going to go into the one here called performance‑driven websites for a second, and it's called performance‑driven websites, it's called, um, something else in a second, because we're doing some SEO work in there.  So, think for a second, um, here, we have an agency, and we're, like, kind of, in a way, we're at the top of the value map, and we're drilling down, so we have this agency that delivers these solutions, and then, here, we have a quick description, which is, like, the boiled up essence is the value statements about those solutions, and then what goes into them, um, making a performant website, for example, um, you know, the CMS itself is fast, using quick loading image formats, um, using CDNs, knowing how to do cashing, right, and so on.  These are all, um, very clearly, um, feature areas, and then if you look in, I've got one here, so they, um, use the Google thing for, you know, fast loading and, um, not only on mobile nowadays, and you can see that each of these sub, sub, sub pieces of the language is a value statement that we've clearly taken from our value map and polished up to be used in this public‑facing communication, and then this thing up here, this statement, um, under the header is basically a positioning statement for using amp, and, so, um, and then, basically, you have a, um, you have a benefit in there, you have a challenge in there, and you have a solution in there, and that's how we're formulating these statements.  

So, this is an expression of turning this value map information into public‑facing communication, so the web page itself is called make typo three faster, because that scores better on SEO, and then you have, at the top of that landing page that has all of these things in it that I was showing you before, at the top of that page, you have a statement, here's the benefit of having a performant website, the first paragraph, the second paragraph is talking about the challenge behind performance, why you'd want it, and then the third paragraph is how the agency delivers it.  So, all of this, um, information, all of this positioning is all extracted from, um, the value map work that we carried out with this agency on this solution area.  So, I really, really, really hope that, um, that's clear and that sort of hierarchical information architecture is, um, you know, that I was able to show that it works out in the real world, and, so, basically, coming back to how I opened the presentation, the only way that I can have trust in you and your solution, your product, your service, is if I clearly understand what your product or service is and what it does and the value that it delivers.  So, thank you super, super, super much for listening to me.  Here we are, back with my official MidCamp slides.  Very happy to take questions.  Now, please give me kind, caring feedback at mid.camp/6403.  If you have time, 10:00 a.m. to 4:00 p.m. in the Chicago time zone, which is called, um, Central, I guess, tomorrow, March 21st, 2020, please contribute to a wonderful open source project, and, um, yeah, I got 5 or 6 minutes for questions, and, um, yep, thank you very much.

>> SPEAKER:  All right, everybody, I'm going to un‑mute everybody at once, and let's all give Jam a round of applause.

(Applause.) 

>> SPEAKER:  I'm going to mute everybody again so we don't have some chaos there.  So, if you have a question for Jam here in the last few minutes, got about 8, 9 minutes, feel free to type it out here in the chat.  You got a few comments throughout there, um, and feel free to use the raise hand function, and I will un‑mute you.

>> SPEAKER:  So, Roger, thanks for the feedback on the consistent color codes.  That's great.  It's, um, this whole thing is the brain child of a lot of thinking and, um, getting to the point where we can, um, made it a system and made it repeatable, right, and then explainable, that took a lot of work, so it's gratifying that, um, it's gratifying that you appreciate that.  If anyone has a brain wave later and wants to get in touch with me, um, Twitter direct messages are open, e‑mail is open, I am technically in Drupal Slack and Drupal Rocket Chat, but very, very hard to get ahold of me there, so don't even really bother, you know, and I'm very, very happy to give you my phone number for, you know, What's App chats and what have you at any point.  So, yeah, really happy to talk about all this later.

>> SPEAKER:  I have a question.

>> SPEAKER:  Yes?

>> SPEAKER:  So, Will asked a question in chat right before Luke raised his hand.  So, Will, do you have your example spreadsheet posted publicly anywhere?  That was very helpful.

>> SPEAKER:  Um, I would be very happy to, so, in fact, the slides from today, with all of it except the Corona Drupal logo, are available on the session note already, and if you want more information than that, then just get in touch.  I can also share with you that we, um, do our content creation and editorial processes in a very, very modular way that's, um, quite highly structured with templates and so on and, um, as soon as I can get our website re‑launched, which is any day now, um, the timing's been thrown off because our partners are so busy with all the crisis communications right now, um, we are going to start talking about all of this stuff in public and making the tooling available.  We're really intent on open sourcing it under, probably, creative comment attributions, something like that, but we're really keen on more people doing this.  We think, um, we think that it's a smart way to talk, and we think that it really suits, um, our sorts of businesses and our sorts of thinking in and around open source.

>> SPEAKER:  All right, and Luke, I actually un‑muted you.

>> SPEAKER:  I was just going to ask what part of the value mapping process most often you find tends to trip people up, or where do you find that, um, maybe, there's the least clarity when you're taking people through the process.

>> SPEAKER:  Oh, um, the hardest part to make systematic for us, I'm not going to say there were false starts, but, um, it wasn't always this clear to us, either what we were doing, we knew where we were going, um, splitting things into features and work flows and benefits, um, turned out to be really key, and that led us, um, that let us take a couple of steps further.  There was a real challenge, um, around the idea that people don't know what they don't know, and we've found that these formats and the cross‑functional teams have helped us do a lot more comprehensive discovery.  I personally find the workshop format quite challenging, and I never, I don't personally have a really good sense of when we're done and when we have enough, but I'm really, really lucky that, um, I have a couple of team members who have done a bunch of these and who really, really know how to pull that out of the room.  I want to say with some real pride, apart from Tracy, the other partner of the Open Strategy Partners, um, we have Heather McNamy, who used to be Heather James, is quite well‑known in the Drupal community, she's on our team and really glorious at doing these workshops, and, um, we have a guy called John Heaven who's also worked in Drupal, and we have, um, we have highly technical, really interesting communicator from the typo three world that works with us, so I'm really lucky that I've got a team with a lot of different strengths.  I think the short answer, thinking about your question again, the toughest part is, um, not knowing what you don't know.

>> SPEAKER:  Thank you.