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.
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:
Realistically, comments will have an impact on the final document if you post them by the end of the week. After that, I'll be writing the actual document.
Also worth mention: in drafting the outline, I realized that some of our earlier work on B2B evaluation, selection, and adoption is applicable here. Expect to see a cameo appearance from some of that interesting research in this document.
In the last couple of years, an increasing number of technology companies have discovered, or rediscovered, or redefined their own portfolio. Here are a few examples of where you can see this new appreciation of portfolios:
Using the portfolio to define alignment. Recently, I wrote a profile of Sterling Commerce's efforts to deal with the inevitable misalignments that occur in any company with lots of products, particularly after making acquisitions. Their decision to use the portfolio as the instrument of realignment is by no means unique, but it wasn't as common several years ago as it is now. (And it's still not as common as it should be.) Vendors like Sterling have to take two steps for realignment to succeed: (1) define the portfolio clearly, in a way that suggests measures of misalignment; (2) enforce this standard on people who would otherwise continue moving in the same direction unless acted upon by an outside force. Not everyone has succeeded at both, or even understood that both were necessary.
When it comes to home improvement, I'm barely competent. My biggest hurdle is ignorance: when I was growing up, no one in our family was a do-it-yourselfer. Unless I had the opportunity to watch the handyman, electrician, or plumber fixing a problem, and that person was patient enough to let me observe, I had zero experience with these tasks.
Fast forward to a couple of years ago, when I signed up for installing hardwood floors in our home. Friends had said that it wasn't as hard as it looked, and the staggering quotes from contractors provided the incentive for forging ahead, despite my ignorance.
After buying the tools and digesting the instructions, I started on the first room. My first attempt was a hilarious escapade, which resembled a horizontal variant of Jenga more than anything that you could describe as "home improvement." After taking a break for a few days, I figured out where the project had gone wrong, made adjustments, and finished the room.
You might be surprised to find out how worked up I can get about an issue like switching costs (a.k.a. lock-in). It's a question worthy of at least a little emotion, since it affects the fortunes of technology companies: Under what conditions would a customer switch to a different vendor for the same product or service?
The question has returned with a vengeance with the increased adoption of SaaS and PaaS technologies. Tech vendors are happy to use the cloud as an easy way to attract customers, as long as it doesn't turn into an equally easy way to lose customers.
What gets my dander up is the simplistic, puerile way in which people sometimes discuss this issue, particularly in regard to SaaS implementations. Here are a couple of examples.
Cost Of Switching
How do the switching costs of an on-demand solution compare to an on-premise alternative? Clearly, the cost of switching from an on-demand solution is not zero, and yet you still find in some discussions of SaaS the assumption that customers will leave willy-nilly. Nor is the cost of switching the same as an on-premise solution, but you'll find people speaking about the two as if they presented the same migration and implementation challenges.
We're now in Phase II of our first venture into Agile Research Development, an investigation of thought leadership in the technology industry. Phase II is when we start the actual primary research, and again, we're looking to the community for their help and guidance. The story so far:
Published the development document, which explains how we'll proceed. Supporting documents, such as this overview of Agile Research Development, are also part of the project dossier.
Incorporated feedback from the community into the development document. Many thanks to everyone who provided suggestions and criticisms of the original research plan, as described in the development document. In fact, if you haven't read the comments on the development document, I strongly recommend that you do. There are some real nuggets in there about a thought leadership, a topic of vital importance to tech vendors, their partners, and their customers.
How You Can Help
First, we need another round of review. This time, we're looking for your feedback on the interview guide. Are these the questions you want answered? Have we missed anything? I've annotated the interview guide to explain some of the reasoning behind the current draft, which is my way of getting the discussion going.