Welcome to the bloggy home of Noah Brier. I'm the co-founder of Percolate and general internet tinkerer. This site is about media, culture, technology, and randomness. It's been around since 2004 (I'm pretty sure). Feel free to get in touch. Get in touch.

You can subscribe to this site via RSS (the humanity!) or .

Conway’s Law [Framework of the Day]

Thanks again for reading and for all the positive feedback. Please keep it coming. If you haven’t read any of these yet, the gist is that I’m writing a book about mental models and writing these notes up as I go. You can find links at the bottom to the other frameworks I’ve written. If you haven’t already, please subscribe to the email and share these posts with anyone you think might enjoy them. I really appreciate it.

Credit: Organizational Charts by Manu CornetI first ran into Conway’s Law while helping a brand redesign their website. The client, a large consumer electronics company, was insistent that the navigation must offer three options: Shop, Learn, and Support. I valiantly tried to convince them that nobody shopping on the web, or anywhere else, thought about the distinction between shopping and learning, but they remained steadfast in their insistence. What I eventually came to understand is that their stance wasn’t born out of customer need or insight, but rather their own organizational chart, which shockingly included a sales department, a marketing department, and a support department.

“Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.” That’s the way computer scientist and software engineer Melvin Conway put it in a 1968 paper titled “How Do Committees Invent?” His point was that the choices we make before start designing any system most often fundamentally shapes the final output.1 Or, as he put it, “the very act of organizing a design team means that certain design decisions have already been made.”

Why does this happen, where does it happen, and what can we do about it? That’s the goal of this essay, but before I get there we’ve got to take a short sojourn into the history of the concept. As I mentioned, the idea in its current form came from Melvin Conway in May of 1968. In the article he cited a few key sources as inspiration including economist John Kenneth Galbraith and historian C. Northcote Parkinson, who’s 1957 book Parkinson’s Law and Other Studies in Administration was particularly influential in spelling out the ever-increasing complexity that any bureaucratic organization will create.2 Finally, judging by the focus on modularity in Conway’s writing, it seems clear he was also inspired by Herbert Simon’s work, in particular his “Architecture of Complexity” paper and the Parable of Two Watchmakers (which I wrote about earlier).

Parkinson aside (who did so mostly in jest), very few have the chutzpah to actually name a law after themselves and Conway wasn’t responsible for the law’s coining. That came a few months after the “Committees” article was published from a fan and fellow computer scientist George Mealy. In his paper for the July 1968 National Symposium on Modular Programming (which I seem to be one of the very few people to have actually tracked down), Mealy examined four bits of “conventional wisdom” that surrounded the development of software systems at the time. Number four came directly from Conway: “Systems resemble the organizations that produced them.” The naming comes 3 pages in:

Our third aphorism-“if one programmer can do it in one year, two programmers can do it in two years”-is merely a reflection of the great difficulty of communication in a large organization. The crux of the problem of giganticism [sic] and system fiasco really lies in the fourth dogma. This — “systems resemble the organizations that produced them” — has been noticed by some of us previously, but it appears not to have received public expression prior to the appearance of Dr. Melvin E. Conway’s penetrating article in the April 1968 issue of Datamation. The article was entitled “How Do Committees Invent?”. I propose to call my preceding paraphrase of the gist of Conway’s paper “Conway’s Law”.

While most, including Conway on his own website, credit Fred Brooks’ 1975 Mythical Man Month with naming the law, it seems that Mealy deserves the credit (though Brooks’ book is surely the reason so many know about Conway’s important concept).3Back to the questions at hand: Why does this happen, where does it happen, and what can we do about it?

Let’s start with the why. This seems like it should be easy to answer, but it’s actually not. The answer starts with some basics of hierarchy and modularity that Herbert Simon offered up in his Parable of Two Watchmakers: Mainly, breaking a system down into sets of modular subsystems seems to be the most efficient design approach in both nature and organizations. For that reason we tend to see companies made up of teams which are then made up of more teams and so-on. But that still doesn’t answer the question of why they tend to design systems in their image. To answer that we turn to some of the more recent research around the “mirroring hypothesis,” which (in simplified terms) is an attempt to prove out Conway’s Law. Carliss Baldwin, a professor at Harvard Business School, seems to be spearheading much of this work and has been an author on two of the key papers on the subject. Most recently, “The mirroring hypothesis: theory, evidence, and exceptions” is a treasure trove of information and citations. Her theory as to why mirroring occurs is essentially that it makes life easier for everyone who works at the company:

The mirroring of technical dependencies and organizational ties can be explained as an approach to organizational problem-solving that conserves scarce cognitive resources. People charged with implementing complex projects or processes are inevitably faced with interdependencies that create technical problems and conflicts in real time. They must arrive at solutions that take account of the technical constraints; hence, they must communicate with one another and cooperate to solve their problems. Communication channels, collocation, and employment relations are organizational ties that support communication and cooperation between individuals, and thus, we should expect to see a very close relationship—technically a homomorphism—between a network graph of technical dependencies within a complex system and network graphs of organizational ties showing communication channels, collocation, and employment relations.

It’s all still a bit circular, but the argument that in most cases a mirrored product is both reasonably optimal from a design perspective (since organizations are structured with hierarchy and modularity) and also cuts down the cognitive load by making it easy for everyone to understand (because it works like an org they already understand) seems like a reasonable one.4 The paper then goes on to survey the research to understand what kind of industries mirroring is most likely to occur and the answer seems to be everywhere. They found evidence from across expected places like software and semiconductors, but also automotive, defense, sports, and even banking and construction. For what it’s worth, I’ve also seen it across industries in marketing projects throughout my own career.

That’s the why and the where, which only leaves us with the question of what an organization can do about it. Here there seem to be a few different approaches. The first one is to do nothing. After all, it may well be the best way to design a system for that organization/problem. The second is to find an appropriate balance. If you buy the idea that some part of mirroring/Conway’s Law is simply about making it easier to understand and maintain systems, than its probably good to keep some mirroring. But it doesn’t need to be all or nothing. In the aforementioned paper, Baldwin and her co-authors have a nice little framework for thinking about different approaches to mirroring depending on the kind of business:

As you see at the bottom of the framework you have option three: “Strategic mirror-breaking.” This is also sometimes called an “inverse Conway maneuver” in software engineering circles: An approach where you actually adjust your organizational model in order to change the way your systems are architected.5 Basically you attempt to outline the type of system design you want (most of the time it’s about more modularity) and you back into an org structure that looks like that.

In case it seems like all this might be academic, the architecture of organizations has been shown to have a fundamental on the company’s ability to innovate. Tim Harford recently wrote a piece for the Financial Times that heavily quotes a 1990 paper by an economist named Rebecca Henderson titled “Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms.” The paper outlines how the organizational structure of companies can prevent them from innovating in specific ways. Most specifically the paper describes the kind of innovation that keeps the shape of the previous generation’s product, but completely rewires it: Think film cameras to digital or the Walkman to MP3 players. Here’s Harford describing the idea:

Dominant organisations are prone to stumble when the new technology requires a new organisational structure. An innovation might be radical but, if it fits the structure that already existed, an incumbent firm has a good chance of carrying its lead from the old world to the new.

A case study co-authored by Henderson describes the PC division as “smothered by support from the parent company”. Eventually, the IBM PC business was sold off to a Chinese company, Lenovo. What had flummoxed IBM was not the pace of technological change — it had long coped with that — but the fact that its old organisational structures had ceased to be an advantage. Rather than talk of radical or disruptive innovations, Henderson and Clark used the term “architectural innovation”.

Like I said before, it’s all quite circular. It’s a bit like the famous quote “We shape our tools and thereafter our tools shape us.” Companies organize themselves and in turn design systems that mirror those organizations which in turn further solidify the organizational structure that was first put in place. Conway’s Law is more guiding principle than physical property, but it’s a good model to keep in your head as you’re designing organizations or systems (or trying to disentangle them).

Footnotes:

  1. He was writing mostly about software systems, but as you’ll see it’s much more broadly applicable.
  2. Here’s how Conway explains Parkinson’s complexity concept: “As each new brand is created it justifies itself by challenging the established order. Thus, after a while, the organization is fully occupied in internal political warfare.”
  3. As an aside, it’s hard not to think that Mealy’s third point about what one programmer can do versus two sounds a lot like Fred Brooks’ “mythical man month” concept. Mealy worked with Brooks on OS/360 and in the book Computer Pioneers by J.A.N. Lee it’s mentioned that Mealy’s Law was also named at the 1968 symposium: “There is an incremental programmer who, when added to a project, consumes more resources than are made available.” Sounds pretty similar to me.
  4. There’s a very interesting point about the role of “information hiding” in pushing companies into Conway’s Law. Essentially the idea is that companies naturally hide information within teams or departments for the sake of simplicity across the rest of the company. It would only make things more complicated, for instance, if the finance team exposed the detailed rules of GAAP accounting instead of just distributing a monthly GAAP accounting report. “Information hiding as a means of controlling complexity is a fundamental principle underlying the mirroring hypothesis. With information hiding, each module in a technical system is informationally isolated from other modules within a framework of system design rules. This means that independent individuals, teams, or firms can work separately on different modules, yet the modules will work together as a whole (Baldwin and Clark, 2000).”
  5. If you’re interested in the idea you should check out the episode of Software Engineering Radio with engineering leader Kevin Goldsmith.

Bibliography:

  • Arrow, K. J. (1985). Informational structure of the firm. The American Economic Review, 75(2), 303-307.
  • Brunton-spall, Michael (2 Nov. 2015.). The Inverse Conway Manoeuvre and Security – Michael Brunton-Spall – Medium. Medium. Retrieved from https://medium.com/@bruntonspall/the-inverse-conway-manoeuvre-and-security-55ee11e8c3a9
  • Colfer, L. J., & Baldwin, C. Y. (2016). The mirroring hypothesis: theory, evidence, and exceptions. Industrial and Corporate Change, 25(5), 709-738.
  • Conway, Melvin E. “How do committees invent.” Datamation 14.4 (1968): 28-31.
  • Conway, Melvin E. “The Tower of Babel and the Fighter Plane.” Retrieved from http://melconway.com/keynote/Presentation.pdf
  • Evans, Benedict (31 Aug. 2018.). Tesla, software and disruption. Benedict Evans. Retrieved from https://www.ben-evans.com/benedictevans/2018/8/29/tesla-software-and-disruption
  • Galbraith, J. K. (2001). The essential galbraith. HMH.
  • Harford, Tim. (6 Sept. 2018.). Why big companies squander good ideas. Financial Times. Retrieved from https://www.ft.com/content/3c1ab748-b09b-11e8-8d14-6f049d06439c
  • Henderson, R. M., & Clark, K. B. (1990). Architectural innovation: The reconfiguration of existing product technologies and the failure of established firms. Administrative science quarterly, 9-30.
  • Hvatum, L. B., & Kelly, A. (2005). What do I think about Conway’s Law now?. In EuroPLoP (pp. 735-750).
  • Lee, J. A. (1995). International biographical dictionary of computer pioneers. Taylor & Francis.
  • MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis. Research Policy, 41(8), 1309-1324.
  • MacDuffie, J. P. (2013). Modularity‐as‐property, modularization‐as‐process, and ‘modularity’‐as‐frame: Lessons from product architecture initiatives in the global automotive industry. Global Strategy Journal, 3(1), 8-40.
  • Mealy, George, “How to Design Modular (Software) Systems,” Proc. Nat’l. Symp. Modular Programming, Information & Systems Institute, July 1968.
  • Newman, Sam. (30 Jun. 2014.). Demystifying Conway’s Law. ThoughtWorks. Retrieved from https://www.thoughtworks.com/insights/blog/demystifying-conways-law
  • Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM15(12), 1053-1058.
  • Software Engineering Radio. Kevin Goldsmith on Architecture and Organizational Design : Software Engineering Radio. Se-radio.net. Retrieved from http://www.se-radio.net/2018/07/se-radio-episode-331-kevin-goldsmith-on-architecture-and-organizational-design/
  • Van Dusen, Matthew (19 May 2016.). A principle called “Conway’s Law” reveals a glaring, biased flaw in our technology. Quartz. Retrieved from https://qz.com/687457/a-principle-called-conways-law-reveals-a-glaring-biased-flaw-in-our-technology/

Framework of the Day posts:

October 9, 2018 // This post is about: , , , , , , , , , , , , , , ,

Parable of Two Watchmakers [Framework of the Day]

Another framework of the day. If you haven’t read the others, the links are all at the bottom. I’m working on a book of mental models and sharing some of the research and writing as I go. This post actually started in writing about Conway’s Law, which is coming soon. I felt like I had to get this out first, as I would need to rely on some of the research in giving the Law its due. Thanks for reading and please let me know what you think, pass this link on, and subscribe to the email if you haven’t done it already. Thanks for reading.

This framework is a little different than the ones before as it doesn’t come with a nice diagram or four box. Rather, the Parable of Two Watchmakers is just that: A story about two people putting together complicated mechanical objects. The parable comes from a paper called “The Architecture of Complexity” written by Nobel-prize winning economist Herbert Simon (you might remember Simon from the theory of satisficing). Beyond being a brilliant economist, Simon was also a major thinker in the worlds of political science, psychology, systems, complexity, and artificial intelligence (in doing this research he climbed up the ranks of my intellectual heroes).

In his 1962 he laid out an argument for how complexity emerges, which is largely focused on the central role of hierarchy in complex systems. To start, let’s define hierarchy so we’re all on the same page. Here’s Simon:

Etymologically, the word “hierarchy” has had a narrower meaning than I am giving it here. The term has generally been used to refer to a complex system in which each of the subsystems is subordinated by an authority relation to the system it belongs to. More exactly, in a hierarchic formal organization, each system consists of a “boss” and a set of subordinate subsystems. Each of the subsystems has a “boss” who is the immediate subordinate of the boss of the system. We shall want to consider systems in which the relations among subsystems are more complex than in the formal organizational hierarchy just described. We shall want to include systems in which there is no relation of subordination among subsystems. (In fact, even in human organizations, the formal hierarchy exists only on paper; the real flesh-and-blood organization has many inter-part relations other than the lines of formal authority.) For lack of a better term, I shall use hierarchy in the broader sense introduced in the previous paragraphs, to refer to all complex systems analyzable into successive sets of subsystems, and speak of “formal hierarchy” when I want to refer to the more specialized concept.

So it’s more or less the way we think of it, except he is drawing a distinction to the formal hierarchy we see in an org chart where each subordinate has just one boss and the informal hierarchy that actually exists inside organizations, where subordinates interact in a variety of ways. And he points out the many complex systems we find hierarchy, including biological systems, “The hierarchical structure of biological systems is a familiar fact. Taking the cell as the building block, we find cells organized into tissues, tissues into organs, organs into systems. Moving downward from the cell, well-defined subsystems — for example, nucleus, cell membrane, microsomes, mitochondria, and so on — have been identified in animal cells.”

The question is why did all these systems come to be arranged this way and what can we learn from them? Here Simon turns to story:

Let me introduce the topic of evolution with a parable. There once were two watchmakers, named Hora and Tempus, who manufactured very fine watches. Both of them were highly regarded, and the phones in their workshops rang frequently — new customers were constantly calling them. However, Hora prospered, while Tempus became poorer and poorer and finally lost his shop. What was the reason?

The watches the men made consisted of about 1,000 parts each. Tempus had so constructed his that if he had one partly assembled and had to put it down — to answer the phone say— it immediately fell to pieces and had to be reassembled from the elements. The better the customers liked his watches, the more they phoned him, the more difficult it became for him to find enough uninterrupted time to finish a watch.

The watches that Hora made were no less complex than those of Tempus. But he had designed them so that he could put together subassemblies of about ten elements each. Ten of these subassemblies, again, could be put together into a larger subassembly; and a system of ten of the latter subassemblies constituted the whole watch. Hence, when Hora had to put down a partly assembled watch in order to answer the phone, he lost only a small part of his work, and he assembled his watches in only a fraction of the man-hours it took Tempus.

Whether the complexity emerges from the hierarchy or the hierarchy from the complexity, he illustrates clearly why we see this pattern all around us and articulates the value of the approach. It’s not just hierarchy, he goes on to explain, but also modularity (which he refers to as near-decomposability) that appears to be a fundamental property of complex systems. That is, each of the subsystems operates both independently and as part of the whole. As Simon puts it, “Intra-component linkages are generally stronger than intercomponent linkages” or, even more simply, “In a formal organization there will generally be more interaction, on the average, between two employees who are members of the same department than between two employees from different departments.”

Why is that? Well, for one, it’s an efficiency thing. Just as we see inside organizations, we want to use specialized resources in a specialized way. But beyond that, as Simon outlines in the parable, it’s also about resiliency: By relying on subsystems you have a defense against catastrophic failure when one piece of the whole breaks down. Just as Hora was able to quickly start building again when he put something down, any system made up of subsystems should be much more capable of dealing with changes in environment. It works in organisms, companies, and even empires, as Simon pointed out in The Sciences of the Artificial:

We have not exhausted the categories of complex systems to which the watchmaker argument can reasonably be applied. Philip assembled his Macedonian empire and gave it to his son, to be later combined with the Persian subassembly and others into Alexander’s greater system. On Alexander’s death his empire did not crumble to dust but fragmented into some of the major subsystems that had composed it.

Hopefully the application of this framework is pretty clear (and also instructive) in every day business life. Interestingly, Simon’s theories were the ultimate inspiration for a management fad we saw burn bright (and flame out) just a few years ago: Holacracy, the fluid organizational structure made up of self-organizing teams. Invented by Brian Robertson and made famous by Tony Hsieh and Zappos, the method (it’s a registered trademark) is based on ideas about “holons” from Hungarian author and journalist Arthur Koestler. In his 1967 book The Ghost in the Machine, Koestler repeats Simon’s story of Tempus and Hora and then goes on to theorize that holons (a name he coined “from the Greek holos—whole, with the suffix on (cf. neutron, proton) suggesting a particle or part”) are “meant to supply the missing link between atomism and holism, and to supplant the dualistic way of thinking in terms of ‘parts’ and ‘wholes,’ which is so deeply engrained in our mental habits, by a multi-levelled, stratified approach. A hierarchically-organized whole cannot be “reduced” to its elementary parts; but it can be ‘dissected’ into its constituent branches of holons, represented by the nodes of the tree-diagram, while the lines connecting the holons stand for channels of communication, control or transportation, as the case may be.”

Holacracy aside, there’s a ton of goodness in the parable and the architecture of modularity that it posits as critical. It’s not an accident that every company is built this way and as we think about those companies designing systems, it’s also not surprising many of those should also follow suit (a good lead-in for Conway’s Law, which is up next). Although I’m pretty out of words at this point, Simon also applies the same hierarchy/modularity concept to problem solving and there’s a pretty good argument to be made that the “latticework of models” Charlier Munger described in his 1994 USC Business School Commencement Address would fit the framework.

Bibliography:

  • Egidi, Massimo, and Luigi Marengo. “Cognition, institutions, near decomposability: rethinking Herbert Simon’s contribution.” (2002).
  • Egidi, Massimo. “Organizational learning, problem solving and the division of labour.” Economics, bounded rationality and the cognitive revolution. Aldershot: Edward Elgar (1992): 148-73.
  • Koestler, Arthur, and John R. Smythies. Beyond Reductionism, New Perspectives in the Life Sciences [Proceedings of] the Alpbach Symposium [1968]. (1972).
  • Koestler, Arthur. “The ghost in the machine.” (1967).
  • Radner, Roy. “Hierarchy: The economics of managing.” Journal of economic literature 30.3 (1992): 1382-1415.
  • Simon, Herbert A. “Near decomposability and the speed of evolution.” Industrial and corporate change 11.3 (2002): 587-599.
  • Simon, Herbert A. “The Architecture of Complexity.” Proceedings of the American Philosophical Society 106.6 (1962): 467-482.
  • Simon, Herbert A. “The science of design: Creating the artificial.” Design Issues (1988): 67-82.
  • Simon, Herbert A. The sciences of the artificial. MIT press, 1996.

Framework of the Day posts:

September 18, 2018 // This post is about: , , , , , , , , ,

The Two True Marketing Strategies

This is post number nine. Looks like I’m going to make my ten post goal for April. As always, you can subscribe to the blog by email. Thanks for reading.

I’ve had this thought rattling around in my head for awhile and after listening to the latest episode of Slate Money about brands I wanted to take a shot at writing it down.

One of my very favorite mental models in marketing is “satisficing.” The idea comes from Nobel Prize-winning economist Herbert Simon and is a portmanteau of “satisfy” and “suffice.” The basic idea is that a much more reasonable model of human behavior than utility maximization is that when we make decisions we ensure that we clear some arbitrary satisfaction threshold (satisfy) and then we give up excess utility for ease (suffice).

Here’s Simon from his 1956 paper “Rational choice and the structure of the environment”:

The central problem of this paper has been to construct a simple mechanism of choice that would suffice for the behavior of an organism confronted with multiple goals. Since the organism, like those of the real world, has neither the senses nor the wits to discover an “optimal” path — even assuming the concept of optimal to be clearly defined — we are concerned only with finding a choice mechanism that will lead it to pursue, a “satisficing” path, a path that will permit satisfaction at some specified level of all of its needs.

What does this mean for brands? Well, first and foremost it means that people are spending way less time thinking about your brand than you hope they are. In most situations brands are a means to an end: A way to ease the burden of choice we all face in our everyday lives. This doesn’t mean that marketing doesn’t matter in the decision-making process, just that we should generally assume people are spending way less time thinking about our brands than we like to think they are.

But I think there’s something much more interesting for marketing strategy at play here. (Please bear with me as I work through some thoughts out loud.) Satisficing says two important things about how people make purchase decisions: First, they ensure that whatever they’re buying clears the threshold and second that they sacrifice excess utility for ease of purchase. (As an aside, I always wondered why it was “suffice” instead of “sacrifice”.)

If that’s true (which I think it is), than you could argue there are only two true strategies for marketing a product: You either have to move the bar or you have to make your brand the easiest to buy. Let’s take those one at a time.

How do you move the bar?

Well, there’s not one bar, so let’s start there. But to be a mass product the bar represents the minimum set of requirements for a category of products. For toothpaste that’s pretty much price (around ~$3), taste (minty for most), and distribution (do they have it at Walgreens/CVS/Walmart/Costco or wherever it is you buy your toothpaste). For cars, where there are multiple categories, the first thing you have to do is narrow down your choices based on use case (compact, SUV, truck) and then price (cheap, regular, luxury). After you choose a category (say luxury SUV), there are a specific set of requirements that make up the threshold. (Four wheel drive? Leather seats? Sorry … not in the market for a luxury SUV, but hopefully you get my drift.)

If your product can’t hit that threshold for whatever reason you’re in trouble. Either you’ve got to change your product to break the bar, switch categories, or you’ve got to attempt to move the threshold.

Take airlines: You could argue Southwest (and Ryanair before it) moved the threshold down by pulling hard on the price lever. They said you don’t have to pay a lot for air travel, but to move the price down we’ve got to remove a bunch of the requirements that the category typically has like reserved seats, free baggage, and even flying into major airports (for Ryanair at least). On the other side, when JetBlue launched 20 years ago, they moved the bar up by saying every plane should have cable TV and tasty snacks.

While it seems like both of these moved the bar different directions (and, to be fair, that’s how I presented them), they actually both had the same effect: They raised the bar and made their competition unbuyable for some portion of the population. While Southwest did away with some of the luxuries of air travel, they raised the bar by saying a flight must be less than this amount. JetBlue, on the other hand, decided to play an experience game instead of a price game, but the outcome was the same in that they made their competition unbuyable to a specific target. The competition is left with the same set of choices: Rejigger their product or move the threshold, thereby making themselves buyable again.

One of my favorite current illustrations of this problem is Airbnb. They did such a great job differentiating themselves and their product that they made themselves unbuyable for business travelers. The threshold for most folks traveling for business is basically the opposite of what Airbnb markets: I want the same room in every city, with coffee in the same place, and most of all I don’t want to have to talk to anyone about my life when I arrive bleary-eyed at 1:30 in the morning with a meeting the next day at 7am. If you look at what Airbnb is trying to do with their Work product it’s basically to change their product by highlighting listings that meet these basic threshold requirements (automatic entry, fast wifi, working space if I remember correctly). The next step, of course, is to convince the world that those things actually constitute the bar.

So that’s the first marketing strategy: Find a way to move the threshold and make your competition less/un-buyable. In essence this is category definition/re-definition work.

Onto the second strategy …

How do you make yourself easiest to buy?

What about for situations where you can’t /don’t want to move the bar? This is where you have to make yourself the easiest to buy. The most obvious way to do this is to ensure you’ve got distribution in places people are and/or spend a ton of money on advertising and put yourself in the front of a shopper’s mind when they’re walking down the toothpaste aisle. This is basically the definition of physical and mental availability from Byron Sharp’s How Brands Grow.

But are there other ways to make yourself the most buyable that aren’t about mass reach and also don’t constitute moving the bar? (Again, competing on price, I would argue, is about moving the bar, not making yourself easier to buy.) I think the answer is pretty much no. Obviously there’s stuff like naming and packaging, but changing those can also have the opposite effect (see: Tropicana, 2009). There’s an interesting argument that some of these new ecommerce plays across every industry is about making things more buyable, but I’d actually argue getting a mattress delivered in a box or new razors at your door every month are the definition of moving the bar in an attempt to make your category competition unbuyable.

So what’s the conclusion?

Well, as usual, I’m thinking out loud and not totally sure. One of the interesting questions this raises is whether I’m thinking of things too zero-sum, but while we know consumers try lots of brands in a category, it’s safe to assume any single purchase is almost always zero-sum.

The other question is whether you can/should be doing both of these things at once? Should you be using your reach to try and move the bar. I think the answer to this is almost definitely yes. You should either be using your reach to move the bar or make yourself the easiest to buy and you should be very clear about which outcome you’re trying to drive. Of course, that raises the obvious question of whether you could use marketing to try and raise the bar while at the same time making yourself easier to buy and I think the answer is probably yes, but I’m not sure yet.

One thing it does clearly suggest is that it’s critical that everyone has a sober eye on the threshold requirements and an understanding of whether your product currently meets them or not. Another is that you shouldn’t try to persuade someone rationally if it isn’t towards the end of raising the bar of the category.

Anyway, fun to write some of this out and would appreciate any feedback. Comments are open and I’m @heyitsnoah on Twitter or you can find me via my contact form.

April 23, 2018 // This post is about: , , , , , ,