/Messengers: Balancing The Ideas Of Many With The Decisions Of Few

I am a lazy, lazy man. One of the characteristics of a productive laziness is that I try to do things the same way all the time, so I don’t have to expend energy dreaming up new ways to do the same old things. On one hand, I am aware that clients sometimes think that their brainchild, and the issues surrounding getting it to market, is totally unique, but when they think about it they usually are not offended that to me it is just another unruly beast trying to get out of its cage.

I have a relatively fixed notion of starting an engagement with clients: specifically, I like to have a full day with the full management team to dig into the companies plans and status. I have relaxed that rule a few times in the past year, with disastrous results. In a recent post, Rules of Engagement, Revisited, I recount the downside of relaxing the requirements for a full initial day and a full management team.

By ‘full management team’ I mean including anyone who could be in a spoiler position for anything new coming out of the consulting. Don’t be swayed when they say that Jane doesn’t need to be there, she’s only the CFO. But later on, it will turn out that she controls allocation of money, so she can veto everything. It’s easier with a small start-up, in general, but in two recent cases small start-ups largely involving very young entrepreneurs both involved much more senior heads of marketing who were both working part time on a more or less consulting basis, and in both cases, these marketing heads were far too busy to attend a full day of meetings on the future of their product. And in both cases this led to downstream turmoil when the marketing hired guns reinserted themselves back into the project weeks later, derailing progress.

This is how I try to structure the day. It seems loose, but if you actually dig into the particulars, its fairly tight.

1. Introductions — quickly go around the room, and do the short version in a few minutes.
2. Tell me about your company (history, status, tech, plans) - 1/2 day

   I want to hear the story: the whole story. How was the company conceived? Who was involved at the start? What were the original aspirations, and how have they changed? What are the backgrounds of all of the people? Who is in charge of what, and if everybody is in charge of everything — which seems fairly common in small start-ups — what is the process of decision making? What is the product, and what is its status? What is the product plan, and if the product has not been released yet, the current go-to-market plan? Who is the chief architect or product visionary? Let’s go through the powerpoint. If there are wireframes, let’s see them all, in detail. If there is a working application, let’s see it, and fool with it. If there is beta feedback, what is it? If there is customer data, what is it? Who are the competitors? What are they up to?
   
   

3. Let me tell you about your company - 1/2 day

   I want to tell the ending of the story: a new, better story. Working from the ideas, perceptions, and realities uncovered in the first half day, we dig into reinforcing what’s strong and rethinking what’s weak. A lot of this involves the team’s distribution of skills, and filling gaps. My emphasis is on social applications — I hardly deal with anything else — so a large number of common themes appear time and time again. I encounter a lot of applications that are dominated by domain-specific functionality where the social dimension is an afterthought. These can require a significant rethinking of the user experience, which is why every member of the management team needs to be there, so everything can be put on the table, and considered. The final output is some sort of a recommended action plan, so I want to walk through that plan with the team, and work to get buy-in and some agreement as to who should do what.

I sometimes say my role is software psychiatrist, where I ask the application to tell me about its childhood. This is really close to reality, since the relationships between the various ‘parents’ — the management team — has enormous impact on the product’s design and implementation.

One of the truths about product design is that larger teams generate more ideas that small ones, but small teams do the best job of weeding through ideas to get to the best ones. The hardest balancing act is walking the line between the first stage involvement of a larger group in brainstorming — like the entire management team, possibly including investors who have to remain confident in the company’s plans, and the occasional part-time greybeard marketing guy — and the whittling down to a small core product team to winnow out the wheat from the chaff. All too often, everyone wants to be one of the small core team.

I believe the best design comes from incredibly small teams: one, two, or at most three people. Even three can get into a nest of group dynamics.

So one of the things I try to work through is to coax the team as a whole into figuring out who is on that team. Obviously, this is also a place where I can write myself out of the script if I come to believe that I will have problems working with the clients, or the product is no good, or the group lacks a center.

In general, my strongest role is chief architect or as an advisor to the chief architect. But I can’t just meet with Betty, the product visionary, or Bao, the CEO. I have to get in the mix with the whole team, and feel their interactions flowing, to see what’s going on, to see how their baby is shaping up.

It takes at least a day, and I discount the day heavily so that the money isn’t the barrier. Even so, I get pushback from some people about allocating a full day and getting the full team together. It seems strange to me to hear that, when in principle getting the product right is the single most important thing for product companies. That’s just another warning sign, though. Just like hearing that everyone (or no one) is in charge of the design, or learning that there is no coherent design description, just a list of features and a programmer.

I have come to anticipate any of the most common ‘software company in distress’ configurations, and I try to apply the appropriate response for each:

1. One Man Band — A strong CEO, perhaps successful in previous projects or lines of work, gets an unfinished idea in his head and starts a new company. He hires others to be on the team, but they do not exactly share his vague product notions, and he never relinquishes final authority about product decisions while remaining only partly involved. The hired hands feel unappreciated and powerless. The only solution is to convince the CEO to either act as chief architect — a role they are seldom suited for — or to hire a chief architect strong enough to demand and get product control.
2. The Band Of Brothers — A pair (or trio, or combo) of friends start a company, in a fairly (or overly) egalitarian fashion. They ‘design’ a product without necessarily agreeing on design principles, a process, or any explicit decision making process. When the partners don’t have obviously complementary skills — like one is technical and the other is the marketer — you find the ‘everything is everything’ result: all features find their way into the product because no one wants to tell Joe that his pet feature is dumb. On a setting where everyone has a veto, products are badly designed and bloated, and change is sl-o-o-o-w. The solution here is to put someone in control of the product design, and to carefully unthread the gathering of ideas (brainstorming) from the narrowing of ideas (design).
3. The Band-Aid — A weak CEO with a random team of principals, generally people with little social capital between them, recently hired into the start-up. The CEO has decided to focus the company on a promising corner of the market, but doesn’t have a real product vision, just a collection of platitudes masquerading as principles, like “so easy even my grandmother could use it”, or “the MySpace of X” where X is some noun, like grandmothers or Idaho. The collection of principals — I won’t call it a team — can’t cohere without a catalyst, and suffers violent mood swings: from a marketspeak buzz campaign, to a rework of the design based on a new competitor, to a rethinking of the target customer based on new market research. The group hopes the next superficial notion will save the day, but it’s just a series of band-aids. The real solution is to fire as many of the ronin VPs as possible, and keep the one (or two) obsessed with building the product rather than endless meetings and powerpoint exchanges.

In a sense I seem to be countering Tolstoy, since he wrote in Anna Karenina that “All happy families resemble one another, each unhappy family is unhappy in its own way.” I think that successful products emerge from happy families, that are alike in critical ways: they balance the ideas of many and rely on a few to make the key design decisions. But I have come to see that the unhappy families in these software design tales are alike, in some ways, as well.

There are patterns in the mess, and those can act as paths that can lead the unhappy toward something better. But in every case, getting the right balance — and separation — between the ideas of many and the decisions of few turns out to be the critical factor.