competition

Smart Geeks Think Like Cheerleaders

Technorati code: FMUS579NQBM8

Saturday I went to a high school half an hour north of our home, to watch my 16-year-old daughter compete in a cheerleading competition. And I learned something about software.

Photo credit: neys (Flickr)

I’m not sure how many teams were there–maybe a hundred. The competition started at 9 am and was scheduled to run through 5. Every team consisted of dozens of girls, all dressed in spangles and glitter, with identical ribbons in their hair. They’d march out onto the floor, drop their heads and arms to their sides, and wait for the first blast of music to initiate the routine. Then they’d tumble and dance their hearts out, finishing out of breath with a flourish.

Every hour or so, the performances suspended so judges could announce winners in a particular division that had just fielded its last competitor.

I noticed a pattern. Even though I have no knowledge of competitive cheer scoring, I could tell who had won. Continue reading →

Why Mental Models Matter

As they leave school and embark on professional adventures, naive engineers believe their purpose is more or less summed up by this equation:

product = software = code

As they get deeper into their careers, good engineers gradually realize that the raw code baked into a product is not everything. They come to appreciate the role that support folks and tech writers, marketers and professional services play in delivering value to the customer. Eventually many arrive at :

product = (software = code) + augment

I’d put this equation into words as follows: the purpose of dev teams is to create products, which consist of software (a synonym for code) plus auxiliary offerings like support, documentation, and services.

Equations capture mental models… Image credit: xkcd

This is the level of sophistication at which much of the software industry operates. It is taught by academia (at least, if you listen to business professors), and it’s the philosophy that underpins lots of outsourcing decisions, as well as strategic mergers and acquisitions.

I think the second equation is better than the first, but it’s still woefully inadequate.

Easy Critiques

For one thing, it ignores the interrelationships among software, hardware, enabling ecosystems, and customer communities. Products don’t exist in isolation; they are part of an embedded system made possible (and relevant) by societal conventions and other technologies. “Microsoft Word” and “Adobe Photoshop” are not “products” for Kalahari bushmen.

For another, software is more than code. Notice the subtitle of my blog… Software includes people as a fundamental ingredient. In the shadows of every architecture diagram is an assumed human being (or an army of them), providing input or accepting output. How else do we think our systems will be installed, configured, optimized? How will our databases get populated, our backups get mounted, our e-books get typeset, or our web searches get chosen? (See my posts about people in architecture and role-playing in design.)

Both of those critiques are important, I think. But today I have a different bone to pick.

The Deeper Issue

Whenever we put “product” at the front of equations that describe our industry’s output, we make the implicit assumption that product is the major–or even the entire–output of tech companies. This assumption is ubiquitous and almost never articulated, let alone challenged. Ask a tech buddy about what his company does; he’ll say something like “We build products that ___.”

Of course, tech companies do build products–or solve customer problems by delivering products and services, if you want to make economists happy. But they also create another output, and I think this neglected stepchild deserves far more attention.

Besides products, tech companies produce and propagate mental models. Or in other words, they enable and shape our view of the world.

Photo credit: daveelf (Flickr)

These mental models of the world matter. They–not products–are the nuggets of gold for which we prospect. Ask Galileo.

How much of popular culture is built on scaffolding provided by an idea that used to exist only in the mind of an engineer? Engineers didn’t just dream up plasma TVs or radios; they enabled the very idea of broadcasting. They didn’t just figure out how to download files from the internet; they convinced us to think of data blobs in terms of files and folders in the first place. They didn’t just populate the App Store; they thought the concept of “app” into existence. I could go on and on with examples, but I’ll leave that as an exercise for the reader.

As I said in my post the other day about comments, the mental models created by engineers are the most valuable output of the tech industry.

MVP

Products are directly sellable, and we have to have them. But products without mental models are pretty darn useless. If you doubt me, try using a sophisticated piece of software without any idea how to think about its problem domain. If you know nothing about accounting, try to use Great Plains to be a bookkeeper. If you know nothing about graphics, try airbrushing an image in Photoshop. If you know nothing about HPC, try keeping Cray’s latest supercomputer busy doing protein folding.

Code is important, but without a mental model of how that code works, it’s not much of a foundation for a product. (This is why outsourcing that doesn’t involve bi-directional knowledge transfer is usually foolish, and why acquiring a company and RIFing all its employees nets the acquirer a lot less than they bargained for.)

Patents look nice in a war chest, but it’s sophisticated mental models, not patents, that are the prerequisite of innovation.

Implications

If you understand that tech companies produce mental models, then certain issues take on new significance.

Tech debt isn’t just insidious because it makes code ugly. A kludge lets us get by with a flawed, ill-developed mental model of a problem domain–and if we build on that model, eventually we create a house of cards. Bad mental models bite us, sooner or later.

Competition in a turbulent market is often decided by who has the better mental model. “Better” might mean the one closer to the predilections of the customer, or the one that has better long-term applicability.

Usability is all about conveying a mental model with minimum effort on the part of the receiver–and then using that model consistently and easily.

A product that doesn’t improve the mental model of the customer (e.g., by pruning unnecessary clutter, by visualizing connections that were previously impossible to see, by accounting for a neglected issue that’s been a thorn in the side) is not innovative, no matter which features it touts. It is providing little of value, and will end up on the dust heap of history.

Action Item

Take a minute to ponder how much of your passion and talent is actually centered on the “other” output from product development. What contribution have you made to a helpful mental model for a customer? Where have you invented a term that resonated, or formalized a process that used to be chaos? 

Related articles

Don Kleinschnitz: Put a stake in the ground.

(A post in my “Role Models” series…)

My huddle was not going well. I’d called a meeting to debate a tricky architectural problem with other senior engineers, and consensus was scarcer than working markers for our whiteboard. We were going round and round in circles.

Don Kleinschnitz walked in. It was our first interaction–he’d only been introduced to the company as our new CTO a few days before–and I wondered whether he’d help us get off the dime.

Five minutes later, the meeting was over, and the controversy was settled. Don had “put a stake in the ground,” as he called it — picked a spot and made a tangible, semi-permanent choice to anchor our behavior.

A stake in the ground. :-) Photo credit: Wikimedia Commons.

Answer the hard questions

I don’t remember the question or the answer, but I do remember some of Don’s solution. He immediately pushed us from generalities into specifics–what use case, exactly, would be affected by the decision? How much, exactly, would tradeoffs pay or cost in either direction?

Of course we couldn’t answer Don’s questions very well; nothing is more certain than ambiguity in software. But Don refused to let us off the hook, because he understood that imperfect but specific answers are better than vague generalizations. Even if you have to guess. (More rationale for this principle is elaborated in the RPCD manifesto.)

By putting a stake in the ground, Don wasn’t being arrogant or unwilling to listen. He was simply recognizing that we had incomplete input, that the right answer was maybe guessable but not clear-cut, and that we’d be better off making a tangible experiment instead of debating intuitions. Maybe our answer would be wrong; if so, we’d adjust later. The cost of altering our trajectory would not be so high that it would invalidate the benefit of immediate progress.

Understand your assumptions

I saw Don model this pattern again when he was general manager of a newly created business unit inside Symantec. We were planning the first release of a suite melded from independently acquired products; the sales force’s compensation and training were in flux; our outbound marketing strategy was unknown.

I think product management gulped when Don asked them for a credible sales forecast, a granular competitive analysis, a rationalized pricing strategy, and a business case justifying the feature sets they proposed to map to line items in budgets. Who wouldn’t gulp? It was a tall order.

But Don wouldn’t settle for finger-in-the-air answers. He dug out a set of spreadsheets from his MBA days and tweaked it. Hundreds of cells held our best-guess scores for the usefulness of features in our products and those of our competitors. Sheets captured assumptions. More sheets ran linear regressions to see if our price/performance fell in line with the industry.

He got pushback. “You’ve got so many assumptions that the model can’t possibly be correct.”

“Yes,” Don would admit. “But insight, not perfect correctness, is what we’re after. You get insight out of specifics. Should we give our installation’s ease-of-use a 5 out of 10, or a 6? Not sure. But notice that the overall price/performance of our product doesn’t change at all when we vary that number. We wouldn’t know that unless we’d plugged in something. Forcing ourselves to give an answer has taught us something about our assumptions.”

Don’s model enabled smart action in the face of tremendous uncertainty.

Show, don’t tell

Don is always tinkering with tools and processes that instill this habit in his troops. On another memorable occasion, we were wrestling with long, dry requirements documents. They were auto-generated from a requirements database, and they ran into the scores–maybe hundreds–of pages. Because they were so long, nobody liked to read them carefully. And because nobody liked to read them, they weren’t producing the interlock we needed to keep five development sites aligned in a healthy way.

Don asked us to build a UI that manifested the existence of all features that would be exposed in our next release. It didn’t have to do anything–just display what sorts of things would be possible.

At first I thought he was crazy. I told him it would take a long time.

“Not as long as requirements docs,” he said.

“It will be ugly–completely lacking in any usability.”

“So? We’re not trying to model the customer experience. We can throw it away. The value is in forcing ourselves to be specific about what features we have.”

I built the UI. And I learned a ton. A picture–even a sloppy one–is easily worth a thousand words. Especially if it’s interactive.

Product managers saw the UI. After a suitable re-education so they knew not to worry about ugliness or awkward workflow, they started saying really insightful things, like: “If we expose features A and C but not B, a user who wants to do A→B→C will be frustrated.” The concreteness of the UI was almost like magic.

I could go on and on about how Don lives this principle, but you get the idea: pose hard questions, get the best answers you can… then force yourself to put a stake in the ground, experiment with specifics, and learn from it.

Thanks for the lesson, Don.

Action Item

Consider a current (or past) design decision that’s been difficult to make. How could you make the decision easier by guessing about the likelihood of a use case, the preference of a user, or other aspects of context? If you got the answer wrong, how soon would you be likely to discover your mistake, and how expensive would it be to adjust your trajectory?