[As promised, here's the first in the series about the tech industry's drive to reduce complexity.]

Remember the magic number? It's the one thing from Psych 101 that you should recall, since it pertains to memory. The brain has an upper limit on the number of chunks of new data it can stuff into working memory at one time. The number is around seven, plus or minus one or two depending on the person and the task. It's the limitation that makes the old game Simon challenging, and that bedevils us when we try to remember a phone number that someone just told us.

The magic number is one way in which the human brain tries to trim down complexity. Another more recent discovery is the brain's fuzzy boundary between literal and metaphorical statements. Attach a candidate's resume to a heavy clipboard instead of a light one, and the interviewer is more likely to treat the candidate seriously, because the resume seems somehow weightier.

Countless other examples exist where the brain takes shortcuts, filters information, and otherwise simplifies the constant, complex stream of perceptions, thoughts, feelings, and actions that would otherwise turn into a "blooming, buzzing confusion." We're not stupid creatures, but the machine that grants us powerful mental capabilities also puts limits on them.

The Death Star Would Be Great If I Could Figure Out What All These Buttons Do

During a briefing earlier this week, Jama Software's CEO Eric Winquist showed us a slide separating the repository of a requirements management system from the collaboration that happens around requirements. I really liked the slide because it nailed an important point about both the requirements process and the tools that try to support it.

Ever had one of those "So what?" conversations about requirements? The one in which someone looks at your carefully crafted bit of product requirement genius and says, "So what am I supposed to do with it?" If not, you probably haven't been a PM, so you should stop reading now. If so, you've experienced first-hand that requirements are not just a big Lego box full of information, from which people will easily construct something meaningful. Or, to use a different metaphor, the requirements repository serves the function of a dictionary, describing the things that matter in the universe of technology that we can build. No matter how big, precise, current, or clear the individual bits of information may be, they don't automatically add up to something that someone could use.

The first generation requirements tools were, in essence, dictionaries. Like the Oxford English Dictionary, an important measure of its success was completeness. Since the human brain couldn't retain and organize this information effectively, and Microsoft Office proved to be incapable of handling information complexity, then teams embraced tools like Borland (now Micro Focus) Caliber and MKS Integrity.

Ever since I got an iPad, I've been eager for the update to the upgrade to the iOS4 operating system that premiered on the iPhone months ago. The ease of use of the iPad erodes, grain by grain, with each app that you add to it, as long as you're forced to keep sweeping across page after page of apps. Organizing apps into functional groups across pages is a tedious process. After a while, you really feel the need for folders to organize your apps more effectively.

Imagine my disappointment, therefore, when iTunes froze as soon as I launched it. It was the start of yet another chapter in the story of my hate-hate relationship with iTunes, because of its unstoppable bloat and accompanying seizures. With every major update, iTunes grows another layer of fat, causing more frequent electronic coronaries when it needs to run (or waddle) through its paces. I can't say I was surprised that iTunes froze, forcing me to reinstall it (the software equivalent of sending someone to fat camp?) before I could get it working again.

Here, from a single company, on a single desktop, is the history of the tech industry's problems with complexity. A device that is consummately simple to use, the iPad, is handcuffed, like a slender Sidney Poitier to a morbidly obese Tony Curtis, to iTunes. As Apple keeps jamming more of its business plan, in the form of new features (Genius, Ping, etc.) and new content (anything that could be described as "released" or "published"), iTunes swells to ever-increasing levels of complexity. 

A recent conversation with executives from Clarizen, a software company in the work/project/task management realm, shows how profoundly SaaS can change the innovation process in technology companies. However, you won't get the most beneficial changes unless you're willing to make an investment.

During our briefing, I asked the CEO of Clarizen, Avinoam Nowogrodski, and the VP of Marketing, Sharon Vardi, whether being a SaaS vendor made it any easier to resolve the sort of questions that vex technology vendors. Their response: "Of course it does."

Here's one of those vexing questions: Why don't more customers move from a pilot to full adoption? The usual first answers blame someone else's department for the disappointing conversion rate: Your product stinks. Your leads stink. Your salespeople stink. 

Round-robin finger-pointing like this thrives in an informational vacuum. If the only hard fact available is the conversion rate, marketing can accuse sales of presumed incompetence; sales can claim that the current bug count might have an effect on customer satisfaction; development can claim that it's bogged down in too many special requests from strategic customers; and so on.

Undoubtedly, when you read the title of this blog post, you thought, "But politicians are users." No, I'm not talking about that kind of user. Instead, I'm thinking of the user we normally discuss around these parts, the kind of person whom product managers and product marketers try to understand, but often don't. 

The 10Questions Project posed questions from salt-of-the-earth, ordinary folk to California senatorial candidates Carly Fiorina and Barbara Boxer. It's a noble failure, a change of medium that had no discernible effect on the quality of message. The candidates' answers are exactly the sort of vague, high-level statements that are more about sentiment (what candidates hint they might do) than policy (what they'd actually do).

These frustrating YouTube snippets resemble the kind of bad answers that users often give when PMs ask them questions like, "So, what would you like to see in the next release?" The reasons for the uselessness of the answers are the same, too:

• The questions.
• The channel through which they're answered.
• The lack of follow-up.