What Do You Mean By “Marketing”?
A friend ambushes me with a paper that causes me to adjust my mental dictionary with respect to what certain business-critical words mean.
Peter Drucker (in)famously wrote that all salient business activity reduces to two categories: marketing and innovation. Innovation, referring to solving the concrete problems that furnish the business with something worth paying for, and marketing being all activity related to getting said innovations—as you might expect—out onto the market. I like this reduction, but I've gotten in trouble for using it, because “in the real world”, Marketing (as in the archetypal department) is distinct from Sales, and Sales and Marketing compete with each other for the company's resources. But this is really just a problem of semantics: Drucker is defining marketing as conceptually subsuming sales, and I don't really have a problem with people using words idiomatically, as long as they say what they mean. But then, my instinct is to map his marketing-innovation dichotomy onto a different one by Herbert Simon, which is about the analysis and design of systems, and what he calls outer and inner environments:
- Marketing for outer (the boundary/interface of a system),
- Innovation for inner (all its parts and pieces and the ways they are connected together).
In my experience, engineering is what I would call “net inward-looking”, at least with respect to its social and/or economic milieu. That is, engineering certainly looks outward more than zero, but typically does so only in matters like cost (including time to develop), performance, and risk and/or safety. The overwhelming majority of the engineering effort, by contrast, is focused on purely asocial realities, like the laws of physics.
I also want to underscore that I loathe talking about “innovation” as a first-order activity; innovation is an epiphenomenon of a concerted effort to deliberately solve a problem (distinct from invention which can happen by accident). But that is a separate rant.
That all said, I think my ontology in this area is due for another update. The other evening, Venkat Rao forwarded me a (presumably classic) whitepaper by a guy named Ralph Grabowski called Who Is Going To Buy The Darn Thing? It argues that engineering-centric firms should spend at least the same amount of money on marketing as they do engineering, and ideally many times more. I found this paper compelling enough to write about because of what he means by “marketing”.
At the centre of the paper is an indicator called the M/E Ratio™—Grabowski never misses the opportunity to flash the trademark—which is what you probably guessed: how many dollars allocated to marketing versus engineering. The argument is that successful companies (the examples are several decades old, hence “classic”) all have very high ratios (he seems to be a fan of around 4x) while the commercial failures are all very low (0.1 and less). The absolute bare minimum, he argues, is 1:1.
Per Grabowski, marketing is a distinct activity from promoting (which I infer to be a superordinate of advertising, PR, etc.) and selling, which is self-explanatory. He defines marketing as the work of identifying the customer (both real and archetypal), understanding their needs, the kinds of things they would pay for, and how much—ultimately to focus what commercial offerings get developed and thus what engineering gets done. In other words, he snaps the concept off both Drucker's and the colloquial understanding of what “marketing” means, giving us something that looks a heck of a lot like what we nowadays call product management, or the more succinct, Repo-Man-esque “product”.
I imagine a business entity as a kind of nucleus that floats in a medium called “The Market™”. Its outer membrane is made up of Sales and Promotion, crenellated so that they maintain the same area but both are maximally exposed to the outside. Beneath that is a thick layer of Marketing, then Design (adding this was my idea), then finally Engineering at the innermost core. The idea behind drawing it this way was to try to conceive of how information from the outside market may pass through the different layers.
I chose the proportions somewhat arbitrarily, beginning with a 1:3 ratio of Sales and Promotion to everything else. I then divided Marketing and Engineering evenly, and then subtracted Design from Engineering's share. Later on, I added a second representation that more explicitly denoted the proportions, and then added callouts that mapped the categories to the different typologies in play.
I regret not being able to include operations in this diagram, but I imagine ops as existing along a dimension that is perpendicular to the page. I also would have liked to represent marketing, design, and engineering interacting directly with the outside somehow, but I think I'd need to do something in 3D to achieve that.
Here are some specific activities from the paper that qualify under this definition of “marketing”:
- Primary market research and segmentation,
- Identifying target entry points, i.e., initial customers,
- Identifying and pursuing strategic alliances, i.e., specific entities and why
- Engineering guidance, i.e., what concrete problems to solve.
Here are some specific marketing questions, also from the text:
- What benefits does the customer wish to spend money to receive? Quantify them.
- Considering only those, where might we already have—or develop in engineering—a decisive, defensible competitive advantage?
- In which market segment(s) can we deliver the most value to the customer?
Grabowski concludes by prescribing that businesses should reorganize around marketing (his definition) and, like engineering, to treat it as an investment in new products rather than a cost centre (like advertising and PR). And of course, to treat it seriously by funding it many times more than engineering. He also suggests blowing up what is conventionally understood as “the marketing department”. This is a radical rethinking of an organization's prototypical structure, and I am totally here for it.
Okay, I'm Convinced…
…but how does somebody like me implement this plan? I don't have any capital to speak of, and it's just me. What I do have is my labour—or more accurately, my attention—and there's still a lot of work to be done. So one thing I can do for now is denominate the budget in hours. Of course, since the number of hours over a given interval are fixed, and (Druckerian) marketing and innovation aren't actually the only activities—actual client work aside, there's also stuff like admin, support, and everything else under the ops umbrella—this will mean even less time available to write code.
I don't actually mind? What it really means is I'm going to have to be a lot more deliberate about what code I'm writing when I go to write it. I don't think that would have been very easy to pull off prior to getting a prototype up and running, but now it's absolutely appropriate to code in the exclusive service of marketing targets.
I was originally going to write about mobilizing a plan to implement a time-denominated budget, but I suspect I need to think about that more. I've never responded well to overprescriptive schedules. Ideally I'd like to allocate a time budget for a given interval—say, three months—to different activities (or categories thereof) and use that to compute a concrete schedule, much of which could be just-in-time. Real-world task scheduling that works closer to how computers do it internally. Ha, maybe I'll make that into a product.
Another issue is that my product—to the extent that you can call Intertwingler a product—is a piece of infrastructure, so its “market” is people looking to make media artifacts (read: websites) and applications on top of it. It's also open-source, so nobody's paying money for it. The only way people “pay” for Intertwingler directly is by using it, talking to other people about it, and sending patches.
There was one last point in the paper (quoting a second paper in fact) that was particularly salient: “Products grow out of the desire to tinker, or because an engineer sees a purely technical challenge.” This was not the case for Intertwingler. Rather, I made it to solve concrete, real-world problems whose objective, material value is glaringly obvious—at least to me. It's easy, however, to be pigeonholed into the tinkering narrative if you don't have a better one available—one that has value for other people in mind.
To monetize Intertwingler, then, I have to be its first customer. This was always expected. The question is, what do I make on top of it? Here is where investing in marketing (qua Grabowski) can help.
Venkat insists I'm a “product guy”, which might ultimately be accurate, but I'm going to have to continue to cosplay as a “services guy” until I have enough product income to uh, “retire” from it. This was also roughly part of the plan—or at least an aspiration—but I am feeling increasingly these days like my hand is getting forced to make it a reality.
About twelve or thirteen years ago, I did some work for somebody who owned an established business, and had had an idea for a new product that was tangentially related to it. The idea was…it was fine. I'm not going to tell you what it was, because I don't remember what the status of my NDA is, but it was the kind of thing that was just innovative enough to get people's attention, and give him something to patent. What's more, he had built a prototype that was maybe 1% of the work he needed to do to get to a viable product, tops, and the other 99% was not work he or anyone in his firm knew how to do. The kicker, though? He already had a bunch of people lined up to buy it. When I asked him how he managed to do that, he told me that he never risks a dime on a new venture that he hasn't already sold. In other words, he had customers before he even had the (more of a design fiction prop than a) prototype.
Eventually he lost interest in the project, and sold off the business unit and its IP for a tidy profit.
By contrast, the challenge that I've always had with Intertwingler is that due to what it does and the way that it works, I've needed the whole thing to be functional before I can do anything sexy or interesting with it. That is, you have to see it in action to get why it's valuable. This is because it takes much more effort to fake up what it does than to just create the genuine article and have it do it for real. I wasted a literal decade trying to get people excited about the idea in lieu of just getting to work making the damn thing.
Hold on…
…I have not one, but two products that already have customers:
- The Nature of Software,
- the still-unnamed IBIS-derived planning tool.
Both of these, incidentally, use Intertwingler as infrastructure (well, the IBIS one doesn't yet but it will by the end of next week). I also use Intertwingler heavily in my consulting services—which was kinda the original idea—to deliver the master copies of my work product.
The Nature of Software is a serialized treatise attempting to reconcile the magnum opus of the late architect Christopher Alexander (called The Nature of Order), with the craft of software development. While I could definitely stand to promote it more often, it is decidedly niche—but hey, don't let that stop you from subscribing. The planning tool, on the other hand, is something you can use to improve outcomes in your work.
Here is a picture of the planning tool as it currently stands. It links to a video of me using it to lay out the design concerns of Intertwingler. Note that this is still the 11-year-old technical prototype, although I did give it a facelift last December.
As I said last time, my professional motto has been, for nearly two decades, to Make Things. Make Sense. That is, create artifacts that transform the complex into the readily understood. I have found that two things have to happen to do this kind of work effectively:
- First you have to accommodate the complexity, in all its, uhh, complexity.
- Then you have to transform the complex snarl of information in a way that adds order, without destroying the structure that's already there.
So many information systems, whether computer-based or otherwise, require you to make destructive simplifications to whatever content you put into them, and/or conform to an ill-fitting structure to make it fit. What is desirable here is an information substrate that is loose enough to be sufficiently flexible, but crisp enough to still be manipulable by machine.
I have a whole rant about why spreadsheets are inadequate. TL;DR: too flat, too ambiguous, too [a few other things]. Relational (SQL) databases afford a richer and more precise structure, but aren't very portable, and require a heck of a lot of manual labour to set up and operate. The new crop of PKM products is moving in the right direction, but they have their shortcomings too.
When trying to understand a thing, it is particularly valuable to be able to examine different representations of the same information, to be able to see it from different points of view. Then there's the practical matter of all the schlepwork that goes into making a serviceable artifact—the less of which that has to be done by hand, the better. This is the essential function of Intertwingler: it takes an arbitrary data structure and turns it into a navigable—and editable—website. It furnishes you, the author/editor/curator, with a semi-finished intermediate material, to sculpt into representations that help people best understand it. It also provides tools and infrastructure to abridge the overhead of all the ancillary business of making websites in general. The planning tool is just one possible application that runs on top of it.
To this end, I'm planning a cozy private alpha: I'm going to invest the next couple weeks into getting the planning tool to a minimum-viable (expedient-desirable) state more amenable to an incrementally wider audience, then I'm going to invite companies to participate. If you run one, or run a team in one, and are interested in what this kind of system can do for you, please reply to this message, or email projects@methodandstructure.com.