Tom Grant serves Application Development & Delivery Professionals. See the full Analyst bio. Visit Forrester.com to learn how we make Application Development & Delivery Professionals successful every day.
[For earlier posts in this series, click here, here, and here.]
Imagine yourself back in childhood, sitting in the back seat of the family station wagon, en route to one of those long, high-stress family vacations that Americans have honed to perfection. Mom and Dad are arguing over what went wrong so far on the trip, and of course, how they could have avoided these mishaps. Why didn't we ask for directions at the last gas station, instead of letting Dad navigate by dead reckoning? Should someone have called ahead to ensure that there wasn't a problem with the hotel reservations? Who was supposed to remember to pack the camera? Was it reasonable to expect a travel rate of 500 miles a day? Quickly, your vision of vacation as a straight line into the heart of fun evaporates. Replacing it is a circuitous flowchart, each serpentine twist representing a different set of decision points, estimates, and possible outcomes. Who knows what might happen next? The wheels will fall off on a desert highway, and someone will have forgotten to renew the AAA membership?
Internal pilots (a.k.a. "eating your own dog food," or "drinking your own champagne") are important tools. But how? What kind of feedback do you get from these exercises, and what sort don't you get?
That's the topic of a new research project that we just launched. While Forrester starts hundreds of new research efforts this year, I'm highlighting this one for two reasons: (1) I'm doing the research, and I think that everything I do is interesting; (2) this is the second time I've done a research project in a very transparent way. From start to finish, we're going to work in the open, to give you, Dear Reader, an opportunity to comment on the research as we do it.
The first project done in this fashion, which investigated "thought leadership" (whatever that means) in the technology industry, resulted in this RoleView document. Along the way, we solicited comments on the basic research plan, the questions we asked our interview subjects, and the content of the document. We threw out questions to Forrester community members along the way, and at the end, we did a brief retrospection on how well we succeeded.
We're Interested In Your Feedback Again. No, Really.
We're following the same game plan this time. Three documents just went live in The Forrester Community For Application Development & Delivery Professionals:
The document plan, which outlines the topic and the research approach.
There are blog posts that you can write without doing any prior work (he says, looking meaningfully at himself in the mirror), and then there are blog posts that require real work. This very interesting post about how the Facebook development organization operates is in the latter category. Instead of pointlessly summarizing the author's findings, compiled from sources who know Facebook from the inside, I'll add a few reactions:
If, as reported, the development team comprises about a quarter of the company's employees (and operations another quarter), that's an unusually high ratio for any tech vendor, whether or not it's in the software-as-a-service (SaaS) business. At salesforce.com, R&D comprises 15% of the company, which is high for the tech industry. Facebook's 25% R&D is staggeringly high.
Even though Facebook regularly confuses the heck out of the people with changes to security features, the company does pilot features before shipping them.
Facebook developers bear a lot of responsibility for their own code, across many dimensions of quality (design, testing, justification, etc.).
The ops team has a more gradual approach to deploying new code than it might appear.
During one of my gigs as a product manager, an executive in our company was overjoyed to have a US Defense Department client. He was eager to land a reference customer, but he fundamentally misunderstood how easy it would be to get a military organization to join the ranks of success stories. He wrongly assumed, in this very hierarchical organization, successful adoption of our collaboration tool was the simple process of (1) the general in charge ordering people to use it, followed by (2) people under his command dutifully using it. The military doesn't work that way, in large part because, when faced with a bad order that might kill them, military professionals learn how to wriggle out of these diktats. (Which is why there's a fine line between initiative and insubordination.)
Even if our executive's assumptions about how the military operated were correct, that formula might spell doom for the project. What happens when the general in charge moves on to another post? No assignment is forever, and the next officer in charge might have a far lower opinion of our product. The crisis might happen earlier, if the current general got impatient with the progress of the project. Fearful of these potential outcomes, this executive bet the entire project on maintaining good relations with the general and his immediate subordinates, including the irascible project lead, whose view of technology adoption was summarized in his comment during a meeting with us: "Users are stupid, so they don't know what they want."
Another excellent post from Scott Sehlhorst, this time pointing out that, even without product managers, product management still happens. Scott’s post is a response to Jason Calcanis, the founder of Mahalo, who wrote the following:
In under 30 days, we completely overhauled our product-development process, removing everything between the developer and iterating on the product. We eliminated positions and process. We made it clear the developers were to make the decisions even if those decisions resulted in a developer being 50 percent slower because they were busy *thinking* about the product (as opposed to just transcribing features from the product manager wireframes).
If Calcanis is arguing that his company doesn’t need product managers, because they just are in the way, Scott makes the obvious counterargument:
When I was still writing software and leading teams that were writing software, I would occasionally point out that all software is designed – even if someone sits down and just starts typing code. There is, at the minimum, implicit design happening in the mind of the programmer. It might not be “good” design, but there is always design. There is always a method to the madness, just not always a considered method. The same is true of product management...Eliminating product managers does not eliminate product management.
[For earlier posts in this series, click here and here.]
Imagine that you're dining at a new Italian restaurant that just opened in your neighborhood. You've heard that the chef is well known and widely respected, so you're expecting a great first experience.
You sit down, and the waiter hands you a menu. Actually, it's not a menu, but a listing of all the top-quality ingredients in the restaurant's refrigerator. Some ingredients suggest the kind of recipes that the chef might prepare: For example, the veal shank might be destined to become Osso Bucco. Since you're not an expert in Italian cuisine, it's hard to guess what kind of recipe might require some of the other ingredients (rabbit, goat, boar, etc.).
The waiter is no help. He'll dutifully return to the kitchen with the ingredients you tell him the chef should prepare, but he won't tell you if that combination will transform into a delicious meal or an indigestible lump.
In this scenario, chances are slim that you'll get the sort of dining experience you expected. If you were hoping for an experience you've never had before, the kind that a world-class chef could provide, the odds are even worse.
Sadly, this is exactly the way in which technology companies have pitched their products. Rather than explaining the experience you should have, they leave it up to you to figure out what experience might be possible, given the ingredients (features and functions) available in the product. This approach has two pernicious consequences:
Politics is a word that we use so loosely that it risks losing meaning altogether. When we talk about office politics, as some recent posts by product management bloggers, we're usually expressing scorn for odious behaviors that stand in the way of some rational course of action. Every organization is susceptible to politics, in this negative sense, including every development team. Better to assume it, or even take advantage of it when possible, than to pretend that some magic tool or methodology will do away with politics.
Can't Live With Politics. Can't Live Without Politics
In their blogs, both Jim Holland and Jennifer Doctor recounted a session about politics at a recent Product Camp in Seattle. The topic struck a nerve, as evidenced by the outpouring of complaints from the audience. We've all heard them, whether we're product managers or not: Empire builders put themselves ahead of the interests of the group; real decisions happen in a back channel, instead of in the open; teams decide in haste, and repent at leisure . . . It sounds as if this session was as therapeutic for the audience as it was informative.
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."
[For earlier posts in this series, click 
Internal pilots (a.k.a. "eating your own dog food," or "drinking your own champagne") are important tools. But how? What kind of feedback do you get from these exercises, and what sort don't you get?
There are blog posts that you can write without doing any prior work (he says, looking meaningfully at himself in the mirror), and then there are blog posts that require real work. 
During one of my gigs as a product manager, an executive in our company was overjoyed to have a US Defense Department client. He was eager to land a reference customer, but he fundamentally misunderstood how easy it would be to get a military organization to join the ranks of success stories. He wrongly assumed, in this very hierarchical organization, successful adoption of our collaboration tool was the simple process of (1) the general in charge ordering people to use it, followed by (2) people under his command dutifully using it. The military doesn't work that way, in large part because, when faced with a bad order that might kill them, military professionals learn how to wriggle out of these diktats. (Which is why there's a fine line between initiative and insubordination.)
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.
Earlier this month, 
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).