I am partway through reading one of the best marketing tomes I have ever read, skimmed, read the blurb of, or seen summarized: Agile Marketing, by Michelle Accardi-Petersen (CA Press, 2011) – and it ranks pretty high among books in general. As someone who follows agile theory and practice carefully, and who has been a fellow-traveler with Michelle in the computer industry for lo these many years, as a programmer, B-school graduate, manager, analyst, and consultant to marketers, I found the first paragraph to be one of the most pitch-perfect I have ever seen, and the rest of it I have read so far has gone directly to the meat, presented it clearly and attractively, and grasped the overall implications of agile methods and marketing for each other well and with a strong, accurate sense of the importance of the topic.
And so, of course, as is my custom in these cases, I am now going to criticize this book viciously for two key ideas that I view as dangerous and in a profound way headed in the wrong un-agile direction (actually, there’s a third, but clearly Michelle is discussing that one just to humor a fad, even if she doesn’t realize it, so it doesn’t really taint her message. I’ll touch on that one at the end, briefly).
Briefly stated, those ideas are:
1. For the customer (but, of course, he said sarcastically, not for the marketer), perception, not product, is what's important; in a sense, perception is reality.
2. Agile marketing, like other agile methodologies, is about adapting rapidly and effectively to change.
Before I begin eviscerating these fascinating ideas, I should pause and invite those readers with “confirmation bias” to stop reading. By that I mean, if you feel that I am an arrogant, ignorant upstart in criticizing ideas that have been seen as important parts of marketing for many years, and have the sense that the rest of this piece will turn out to be wrong, I am sure you’re right. Please stop reading right now.
Still here? Boy, that reverse psychology worked. Because, of course, I’m just asking you to perceive the world differently, not accept that the world is different; and I’m only asking you to adapt to a customer’s suggested change in your own ideas, not develop additional new ideas before being prompted. Right?
All right, then, let’s dive in. Sharpen your knives for Idea 1.
Marketing Into the Delicate Dance of Perception and Reality
I have encountered this one many times over the years, in unexpressed assumptions, and expressed as “products never fail because of product characteristics, but because of flawed differentiation/positioning/advertising/understanding of the market we’re in.” Let me start with two stories that I believe directly contradict this.
The first one is the story of a software product back in the 1980s called LAN Manager. It was sold by Microsoft and IBM, who were dominant at the time in the PC market. It was sold to the correct market – businesses – and sold with conviction, imho, by both Microsoft and IBM. I can vouch for the fact that not only among businesses, but also among techies, the general view was that LAN Manager was the future. I have heard many rationalizations for the failure of LAN Manager over the years, and they all strike me as bad descriptions of what I saw at the time.
At that time, I was tasked with comparing LAN Manager and Novell NetWare technically, and as I examined LAN Manager I noted an odd fact: it required twice as much main memory on the client PC as any PC afforded that would be on the market for the next 1 ½-2 years. In other words, in the real world, LAN Manager would be effectively unusable except if an organization waited to buy a new round of PCs that wouldn’t exist for a couple of years, and even then might not make sense as replacements for existing PCs. And I should also add that the key, and very effective, selling proposition of the new network operating systems was that you could use a spare PC as the server.
At this point, I can hear the objections: probe a little deeper, and you will find that marketing failed to coordinate new product development effectively. Sorry, but you’re still missing the point: This was the typical act of organizations for whom the customer’s perception of reality was everything, and all you had to do was to manipulate that perception. Microsoft and IBM never saw the problem because they assumed that giving programmers general directions was enough and they could handle the rest by marketing. Because they were so focused on the customer’s perception, they were blind to the customer’s reaction to reality.
Hey, that’s one case, right? All right, here’s another. When I was at Yankee Group in the early 1990s, it was a game among publications to get projections from analysts at different firms as to network operating system share of market in the coming year. Three times I did this. Three times, unlike every other analyst, I picked Novell NetWare to increase market share – it was already at a hefty 70% as I recall, but the heavyweights of the overall computing industry, from DEC to IBM, now had viable, well-marketed NOSs of their own, and every business surveyed indicated that they were going to increase the share of these competitors in the coming year. Year after year, this was occurring, and year after year, Novell NetWare’s share increased, just as I predicted. Monopoly power? Don’t make me laugh. So why was I right, and everyone else wrong?
Well, here’s a gem of a case I collected from DEC itself. I was talking to one of their engineers, and he told me that in order to get their work done, he and others had set up a NetWare network. But because they weren’t supposed to be doing so, they “tunneled” as a small part of the overall DEC network, invisible to both their managers and the administrators keeping watch over expenditures and usage of competitors’ products. Until the volume on the NetWare network grew so large that it began crowding out all the other traffic on the DEC network. And that, typically, was how NetWare won out – because no matter what the corporate strategy was, individual employees acting on behalf of their own needs crowded out corporate plans. Marketing, meet reality.
I hear another bleat from the marketers – not proven. Again, you’re missing the point. In this case, DEC marketing was so focused on manipulating the perceptions of its traditional customers, the CIOs and CEOs who held the purse strings – which, obviously, it did quite well – it failed to realize how the reality of greater NetWare usefulness right now to reality-based programmers and techies trumped corporate plans. And, again, that was because marketing was so focused on manipulating the perceptions of customers, as had been highly successful in the past, that it overlooked the degree to which users’ clear view of the real comparative usefulness of the products at that point in time would create a situation in which, eventually, CIOs bowed to reality and started making NetWare a corporate standard; and then the game was well and truly over, and the mini makers had lost control of their low-end customers. Everyone else bet on perception, as a reflex; I bet on reality (I had used NetWare in the past), because I felt strongly that in this particular case it would trump well-manipulated perception.
I am not just saying that “perception is reality” is wrong in minor ways. I am saying that another idea is a much better model for what is going on, and that, in the long run, and sometimes in the short run, using my idea as a basis for agile marketing is likely to do much better than Michelle’s Idea 1. But before I go on to that idea, let me summarize the ways I believe Idea 1 is wrong-headed:
• If you analyze particular failures and successes carefully, the design of the product, independent of how marketing thinks it should be portrayed (i.e., its “reality”), often plays a key role in long-term success, and in a few cases in short-term success. I emphasize long-run success, because initial success that emphasizes perception too much takes the organization’s eye off the technology-development ball, and causes a greater and greater gap between a pleasant perception and a not-so-pleasant reality. That may have worked in the stable markets of fifty years ago, but not today.
• The idea that perception is reality reinforces in corporate marketing and strategic planning a fundamentally flawed – because biased – view of the customer. It focuses the marketer on manipulating a malleable and necessarily partially unreal perception, rather than engaging in a delicate dance with the customer to get him/her to play with your offered perception rather than another’s, always keeping in mind that a key segment of your market will be spending the majority of their time doing something else and dealing with the necessary realities of real life, and therefore there is only so far you can go in bending and misdirecting around reality. Bluntly: just because you’re a successful marketer, you think the customer is what you want him/her to be in order to sell your product. As an antidote, try to imagine (preferably, checking against reality) a day in the life of several customers and several who are not customers, and then see how much your “buy, buy, buy” caricatures his/her overall behavior.
• Above all, the idea that perception is reality leads to un-agile marketing behavior. It does so because it causes you to misperceive changes in the customer – misperceive them as greater and greater acceptance of the perception you are selling them, rather than the tendency of a sub-segment of the market to become addicts. Except when something is forbidden, addicts are not a good long-term market. If McDonald’s was only delivering more fat and sugar, it would not be growing; instead, its customers would be busy dealing with their excesses via ill-health and reduced buying. What else is it delivering? Not just convenience; it’s also delivering enough food to live on when cost is very important. If, in that delicate dance, you misperceive the customer, your rapid changes do not fundamentally get at what is croaking your markets; they are not, in the long term, effective responses. Therefore, they are fundamentally un-agile – they just give the perception of agility. But hey, perception is reality for the marketer too, right?
• So you can guess my final bullet point. If the marketer thinks perception is reality for the customer, perception will become reality for the marketer, and the rest of the organization: manipulate perception of the marketer by the rest of the organization, manipulate perception of the goals of the organization by employees, manipulate perception of the financials by the stock market – if we do it right, perception will become reality, because perception is all that really matters. And that’s why we see, in the latest surveys of CMOs, a new appreciation for the importance of company culture in sales, and appreciation of the difficulty of changing it to what the marketer would desire in order to sell perception better. Because there’s the marketer’s perception of what the company is; and then there’s the reality of employees’ daily lives and all the other messages their organization keeps sending them.
My Modest Alternative
Having gotten thus far in my musing, I found that Michelle’s wonderful discussion of marketing agility put me in an agile frame of mind, suggesting to me a new way of thinking about things.
So let me present it in its most provocative form: What companies are selling is not product so much as a partial worldview, and what customers do is not so much buy – that is the final or intermediate act – as take part in that worldview, fitting it with the rest of their worldview, for a brief time, hopefully repeatedly. Moreover, just as much as companies compete with other companies’ products for a share of the customers’ money, they compete with other customer worldviews for a slice of the customer’s time. That time, the company should accept, will and should always be a relatively small fraction of the customer’s overall time. If your employees are always buying your products, when do they work for you?
That customer worldview, or parts of it, are always evolving, not just as the customer moves through life but also as the customer always seeks better worldviews. Better means new, not the reverse. Better is, in some sense, reality, and if you are a lucky marketer, your new product will be part of that customer’s better reality. Yes, you can get away with perception that is well away from product reality in the customer’s life for a while, and the customer will not reject it, but, because it is not delivering any benefits but fantasy, after a while, the customer will increasingly prefer another worldview more based in reality. You can sell a Dungeons & Dragons game, but if you don’t think up ways to apply such fantasy usefully to some of the rest of the user’s life, the market of non-addicts will slowly drift away to fantasies that are more useful, like fantasy vacations. And then, the final refuge of the trapped marketer – monopolies that cling desperately to high prices in one area, until they fail to cross the chasm they no longer can recognize.
So marketing strategy no longer becomes, perception is reality, I must create the right perception. Rather, it becomes, how far can I go in creating perception before reality bites me in the donkey? How do I manage both perception and reality so that both are in tune with the customer? And how do I reality-check with customers that my worldview is a viable, differentiated customer worldview, worth spending time in the long run on?
Good time to discuss Idea 2.
Michelle is only the latest in a long string of commentators to imbibe received, unexamined wisdom about what agile software development is, and assume it always means reacting to the customer’s change, or the organization’s environment, or at best doing one’s utmost to predict future customer behavior based on the past, and then prepare for a few alternatives. No, no, no. Agile is equally about being proactive. Agile is about both sides of the conversation, the developer and the customer, contributing equally, each held in check by – and also using as a source of new ideas – the other. Agile is about product development that is as informed by the developer’s sense of the possible in the future as it is by the customer’s sense of what is needed right now.
Let me give you an example of a fundamental marketing failure because, almost universally, organizations have failed to grasp this idea. Back in the late 1970s, I worked on one of the first word processors. The problem then was how to make accessible to a consumer – a secretary, an administrative assistant, even, heaven forbid, a fast-track youngster doing spreadsheets – how they could store and view “files” of information on a word processor or computer. And there were two obvious answers: A desktop, on which you store individual “files”, and a file cabinet, in which you can store lots of folders containing files. A desktop was everyone’s experience; a file cabinet, in those days, was managed mostly by the secretary.
You are probably beginning to guess where this is going. The first word processors tried to implement file cabinets. Then they went for desktops with folders scattered around the tops. Meanwhile, the programmers were screaming at the marketers that this was crippling the full power of the word processor and PC to store information, and the marketers were screaming back that people would never understand folders within folders, until finally someone tried it, and, lo and behold, people just used the first level until they got the idea and then were perfectly happy to use several levels of folders; and the product that got there first was among the winners until the next chasm came along. Except that, sadly, the story doesn’t end there.
You see, there was another thing that some programmers were screaming about. With a simple extension of existing computer file storage organization, with the same look and feel as “folders within folders”, you could store the same file in multiple folders. In essence, you could cross-reference with incredible ease. But, gee, said the marketers, people will never understand this. And clearly, they don’t care; no one’s demanding it, are they? And so it has been, from that day to this, with one extremely minor exception:
Yes, I’m being very rude, here. Has no marketer yet realized that one major value of search engines to the average user is that they give a temporary cross-reference of multiple files on the same keyword, different from the static “it’s on this Web site” address? And if you do realize it, how could you possibly, possibly not think that users would really, really find that kind of cross-reference useful on their basic PC or browser desktop, in addition to today’s way of storing information? But hey, developers couldn’t possibly have anything to with what users would find useful, would they? Technology-push. Dirty, dirty word. Oh, and by the way, funny how Steve Jobs dared to try drag-and-swipe, fifteen years after programmers first started talking about it. Yeah, he was very good at fitting it to customer uses; but customers weren’t asking for it, were they?
And the most ironic part of this is that Michelle, with her right brain, is saying, agile is reactive, while with her left brain she is talking about keeping marketing simple. Because that’s typically when programmers or designers can anticipate user needs well – something that mathematicians (and, believe it or not, good programmers are good mathematicians) call orthogonality. Basically, orthogonality is a user interface in which (at the top level) a minimum number of approximately equally powerful actions cover most or all of what the user wants to do. You want an example? Take a look at the original Microsoft Word GUI. File. Edit. A couple more. Help. Did you realize that was one of the key reasons people started preferring Word to WordPerfect? Yeah, there were some verbs and some nouns, but basically people could look at it and say, yeah, now I do something involving the overall file, like Print it. Now I do something that involves editing. Now I … That was a developer’s idea – orthogonality. WordPerfect was more a marketer’s idea. When it’s orthogonal it’s simple – see, Michelle? Only the developer can do orthogonal, because the customer doesn’t spend the time thinking about things from the developer’s point of view, just thinks about the next change for the next immediate need.
And that’s the funny thing about agile software development. It encourages orthogonal software development, because it turns out it’s quicker to develop. It encourages the developer to suggest ideas to the customer, not just the other way around. You know, in looking at implementing this human resources app, it occurred to me that it would be straightforward to link your profile to your Facebook page. You can do that??? Oh, yeah. In fact, to make it orthogonal, I can just leave open what you want to link to – like Google Groups. Wow. Let’s see, what could I do with that …
I don’t think we need to belabor what my fix is: it ought to be obvious. Marketers should start thinking like Saki’s master politician, who knows just how far to go (what the customer is demanding) and then goes just a little bit farther (extends it to simplify the design, or gets a programmer to do that during product development, or preferably both). Crowdsourcing? Crowdsourcing is still reactive. You need a single voice that simplifies and goes a little bit farther. And you do it in a rapid, spiral fashion. Customer leads a little bit; you lead a little bit; customer leads; you lead. Reactive agility goes to where the customer has been. Proactive agility goes where the customer doesn’t know he/she would like to go – and then reality-checks.
Just one last sneaky point, and then my sermon is over. Why do marketers ignore the very real and valuable orthogonality contributions of developers? Could it be because the reality of the product doesn’t matter, only its perception by customers?
Oh, Yeah, Third Criticism, But Even I Don’t Care in This Case
Somewhere in the first Chapter, Michelle drops a casual remark about “lean, agile” as if this were a good thing. Yeah, there are plenty of folks in product development who believe sincerely in that one. I have a simple test: When you are creating the product time-line, what’s more important? The agility of the participants, or just-in-time provision of resources to the project? If you rush one programmer towards the next task or delay him/her, are you doing it so no resource goes un-utilized and none are unnecessarily utilized, or because the programmer needs that to be done in order to spend extra time to improve the agility of his/her process? Who is the master, agile or lean?
I have written on this extensively elsewhere. I understand that Thoughtworks, these days, is generally doing “lean in the service of agile” right. Here’s the bottom line: If lean wins, you inevitably become less and less agile. And that, in turn, will mean that despite a lean veneer, you will have greater costs, less profit, and less customer satisfaction. Do you want the perception of cost savings in that project? Or do you want the reality of better company financials, short-term and long-term, rain or shine? Don’t tell me “lean, agile” is necessarily a good thing.
Keep On Changing, Michelle! Pay Attention, Everybody!
So, after many pages of attempted disemboweling, I anticipate that most readers who have hung in this far (ah, so my reverse psychology didn’t work after all, did it?) will have the nagging thought in the back of their heads: if the writer is this critical of Michelle, how can he possibly mean those nice things he said about her and the book at the top?
Again the answer is simple, and, I hope, orthogonal. There’s a story that Mrs. Justice Oliver Wendell Holmes once met President Theodore Roosevelt at a party, and, as was his habit, he asked her what she thought of his Presidency. “Oh, Mr. President,” she replied, batting her eyes at him, “I believe that everyone should be forgiven the vices of his virtues, and you, Mr. President, have so many virtues!” He beamed happily at that one – until he suddenly got the point.
I am, I hope, less catty than Mrs. Holmes in saying the same thing. There would be no point in pointing out the points I disagree with if I did not feel that this book was so close to getting it right (there’s that arrogance again) that it is vitally important that Michelle be read, and her readers consider these points. And consider them agilely. Pay attention to Michelle, all you marketers! Keep on changing, as she says! And, please, keep on changing, Michelle! Changing my agile marketing blues away …