Since there's no systematized, look-it-up-in-your-economics-textbook definition of thought leadership, people generally lapse into metaphor when they try to describe the concept. The language usually gets very Joseph Campbell-ish. Thought leaders might be visionaries, Delphic conduits into some shared future. Or, they might be heroic trailblazers, clearing a path into places that no one knew existed, or they were afraid to venture.
Our recent research into thought leadership points to a different metaphor. Thought leaders are not seers, like Cassandra or the Sibyl. They're closer to trailblazers or founders, like Romulus or (less mythologically) Alexander the Great. But even that's not exactly right, since thought leadership depends critically on communication. Alexander got a lot of good press; Cyrus the Great, the founder of the Achaemenid Persian Empire, got much less (at least in the West). As a result, people are still sifting through Alexander's career for nuggets about successful leadership. Cyrus the Great? Not so much.
Thought leaders are, to a big extent, more like Homer than the people whom Homer chronicled. They're good story-tellers, which demands far more than relating a collection of incidents.
Just ask anyone reading a success story on a tech vendor's web site.
Earlier this month, the Silicon Valley Product Management Association kindly invited me to participate in a panel discussion about the state of PM as a profession. Since the role has wide responsibilities, the conversation ranged widely, but we did dwell a great deal on requirements. One participant asked, "If you could pick only one source of information for requirements, what would it be?" My response was a little tart: I hate that question, because there's no way to answer it.
First, no single type of information will be sufficient to answer a substantive question. Requirements are an exercise in triangulation. Is it worth pursuing a project? You could count the number of people who have asked for it, but that's hardly a reliable basis for making a potentially expensive investment. The next logical questions -- Why do they want it? How important is it? Do we really understand the request? -- require a conversation with at least a couple of potential consumers of this technology.
Second, the question determines the type of information needed to answer it. One type of market development question, such as, is there opportunity for us? requires market-level data. A different market development question, do people in this market need a different mix of functionality in our product? leads to an investigation of potential use cases.
The people responsible for requirements -- product managers, in the tech industry -- have no training in selecting the questions to ask, or the right way to ask them. Which is odd, because you might define the PM role as the questions person, delving into markets, users, competitors, stakeholders, business problems, and a towering pile of other topics.
One of the face palm moments I had while researching PM's role in SaaS was the timeline for platform and app development. The traditional path for on-premise products was platform first, then application. The cloud products flip this sequence, putting the applications first, then the platform. We're so used to seeing this pattern that it's easy to take it for granted, or mistake the reasons why it exists (hence the face palm).
There were two reasons for this evolution in the natural history of a tech vendor's portfolio. The first is distance from the customer. In an on-premise world, where there's a lot of geographic and organizational distance between the producers and consumers of technology, the collection mechanisms about customer adoption (infrequent "How ya doin'?" conference calls, cryptic bug reports, etc.) are labor-intensive. For however much effort you put into this research, the information returned is often incomplete, distorted, or just plain wrong. For example, the game of Telephone played among product teams, customers, and the salespeople in between often leaves PMs with more questions than answers about what a customer really wants.
Therefore, the product strategy for on-premise products have to accommodate a lot of uncertainty about how customers use the technology. While it's not the only reason for customization and custom application development, it's certainly an important one. Rather than guess wrong about customer adoption, on-premise vendors tend to say, "Here's a toolkit. Go build what you want."
[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
Scott is talking about the role of documentation in Agile development, but his points are relevant to any team, Agile or not. Agile creates greater sensitivity to the issue, since too much documentation can cripple the team's velocity. Of course, the lack of documentation can damage the team's success:
Some collaboration is transient – communication happens right now, and is only important right now. Other communications are persistent – the collaboration happens right now, but we need to remember later what we agreed upon and why.
Scott's post is a great illustration of what I was discussing yesterday about treating requirements as conversations, not dictionaries. Requirements are part of the conversation, but a lot of the same content that defines what to build, and why, gets recycled later when you need to describe what you built, and why. For example, personas get passed around quite a bit among groups. Perhaps the originate in the development team, but people in sales, marketing, support, and other downstream groups have a keen interest in that information.
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.