Can an existing org get real?

I just finished reading @37Signals product design/development manifesto, “Getting Real.” I came out on the other side of this read so full of energy — motivated to go back to work in the morning, fire everyone except my favorite developer and product person (I’d do the design, natch) and set out to change the world with a kick-ass product. The no specs, get-it-out-in-the-wild and iterate, evolve and grow into something huge approach was the breath of fresh air I didn’t know I was missing. But then I stopped and paused to reflect on my current (and frankly, the bulk of my career) situation and reconsidered.

Can an organization that is carrying a full complement of employees, roadmaps, operating plans and budgets adopt this lean philosophy wholesale? I don’t think so. There are elements of the approach that can be watered down and used to augment some current behaviors but the kind of cultural shift required by this approach means retro-fitting an existing organization (of a certain size) is not possible.

Here are just three of the areas where I think the “Getting Real” philosophy breaks down with an existing organization:

1. You are NOT your customer — the book states you should build products for yourself — that YOU are your customer. This is simply not true with an existing org. The quantity and variety of folks working with you cannot all be your customers. You MUST interact with your customers to learn the true nature of their problems.

2. Epicenter design — frameworks are very popular in existing companies. The need to define the infrastructure for a system, interface or experience is a priority. These frameworks determine how many other people need to get involved, at what capacity and which systems need to talk to each other. In addition, the feature being developed in all likelihood is going into an existing product. That product has it’s infrastructure components already defined and these constraints are bequeathed to the feature you’re plugging in.

3. Technical and UX debt — in my experience, existing companies never go back and fix “little stuff.” If a feature failed or has a major bug then fixing that becomes a priority. Otherwise, it’s a steady march forward to release more product faster. Going back to tweak a mediocre implementation that still works is not a priority for any product owner. The compromises made during the lean product development lifecycle would simply  be treated as an admission of that compromise in index card form stuck to a debt board no one looks at.

I think the bulk of the advice in “Getting Real” is fantastic — IF you’re the 3-person startup described in it. In that situation you should definitely be producing working product at a very fast pace. In an existing org, however, there are elements of the day-to-day administrivia that you can hope to remove but effecting a wholesale transition to this approach would fail.

[Jeff]