This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: What's In The Box?
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
Reading Dave Winer on Longhorn, his phrase "A product with a purpose has a two-sentence description that gets everyone so excited they can't wait" resonated in my head, the way a bell does in a cathedral, drowning out other considerations until the reverberations die away. Not that I'm a huge admirer of Mr Winer - in this case I followed a link from Miguel de Icaza's blog, but I think he hit a nail with that one.
On my business card it says "Technical Director", which, when you come down to it, is a pretty ambiguous term. In the case of the Mobile Phone Project (and I promise the two people who emailed me that I'll post links the day it goes live and start using the real name, okay?) the job is pretty much this: tell the product design guys what's possible, and guide the technical guys towards making the right product. In other words, keep the two sides, whose respective worldviews, languages and focus have very little in common, in touch.
Miguel sums up one of Joel Spolsky's pieces by saying engineering organizations are too much in contact with the technical details of how to make things happen, without looking at where and how the software is going to be consumed, which is a neat way of describing half of the problem I'm employed to solve.
Let's look at this from the marketing side first; techies are notorious for arguing over details and fine points that the product concept people think are irrelevant. "All we want is a flying carpet; how it flies is your problem, don't bother me with detail". The extremes of this are, of course, Pointy-Haired-Bossdom in its purest form; the end result of the through process that begins "anything I don't understand is irrelevant". But what a disturbingly large number of geeks don't seem to get is that the product people often aren't stupid, or ignorant; they just see the world differently. And often they are very good at knowing what will appeal, what will have value and what will sell. I find, myself, that sales are quite important (for boring accountancy reasons with which the Pure Techies need not concern themselves).
So for that side of the business, my job is to interpret technology. Not to dazzle with science and act the part of the High Priest and Keeper Of Arcane Knowledge but to:
explain where it's necessary to explain
summarise where the details aren't necessary
use analogy where it's appropriate
speak the language of those that are listening
The best mental model I've found is to see it as translation.
From the techie side; product concept people are notorious for ignoring detail and making outrageous requests for ridiculous requirements. For that side of my job, I have to translate what the product needs to do into the details of how it can accomplish that. Often this is iterative:
Concept Guy has a requirement: "It must do full-screen video on a mobile phone handset." Technical Girl throws up her hands: "Do these people understand nothing? You can't handle that much bandwidth on the phone."
Actually, what Concept Guy means is that he wants video better than the postage-stamp stuff he's seen so far. He's using the term "full-screen" because to him, it means "decent quality". What Technical Girl means is that the phone won't handle her definition of full-screen, by which she means 30fps. My job is to find the balancing point, to explain the tradeoffs between bandwidth, CPU power and quality to Concept Guy, so that he can say what will and won't work, and to give Technical Girl an good, consistent idea of what an end-user wants from a videoplayer, so that she can come up with a way to meet the product needs. Maybe her ideas will be better than the original concept.
It goes further; as the development continues, inevitably there are technical compromises that must be made as things turn out not to be quite as simple to do as first thought. And from the product side, once a product begins to be real and people play with prototypes, the idea of what it is that can be sold changes, subtly. This in turn affects what's being built. The trick is to find the cost-effective, commercially-driven way to solve the technical problems. Feature isn't working? Banging your head against a brick wall of code? Well, let's take a look at what the feature is for. Maybe it's not required in the first version. Maybe there's another way altogether to deliver the same value to the user.
Of course, this is self-evident stuff, hardly needing to be written down. But if that's true, why is it that so many organizations seem to have these same familiar cultural gaps between the worlds of product and technology? Is it, perhaps, because the job of translating between them isn't seen as valuable? I've been making a pretty good living doing it for more than ten years now, and I wouldn't want to do anything else.
I'm off to get some new business cards printed. They say "Cultural Ambassador From The World Of The Geeks". Or just "Translator".
Previous Topic
