Product Management Without Portfolio Management Has Limited Value

Blog post info and actions

Blog post body

Tom Grant

Practically everyone who visits the Vatican stops to take a picture of the Swiss Guards. Ditto for the Queen's Guard at Windsor Castle, the Royal Life Guards at Rosenborg Castle in Copenhagen, and the Evzones at Greece's Tomb of the Unknown Soldier. Those multicolored uniforms may not have a place on the modern battlefield, where camouflage is far more important than panache, but they do attract the tourists.

If, by this measure, these ceremonial units have some value (albeit none militarily), why not have more of them? You could post the newly created Sartorial Guard at tourist locations that haven't been attracting enough foot traffic lately. And who knows, they might even attract more recruits into the real military. (Though I'm not sure what the career path is once you've held the rank of Feldweibel in the Swiss Guards.)

Obviously, I'm not being serious. Once you start manufacturing new ceremonial units, you cheapen the brand. You don't need more than one as a "loss leader" in the military, and there's no need to get the people who actually fight up in arms. Figuratively, that is.

Here's why managing a portfolio is critical for managing products. It wouldn't be hard to find some enterprising "champion" for a new Swiss Guards-ish unit who was willing to sew the uniforms and stand around looking fierce. (We call them re-enactors, and we don't put them on the public payroll.) No matter how much attention they attract, they'll still be a failure from a national perspective.

Read more

Would You Know A Product If You Saw One?

Blog post info and actions

Blog post body

Tom Grant

Over the weekend, I attended the Silicon Valley Product Camp, one of the yearly un-conferences for product managers in the US, Canada, and beyond. During one of my sessions, a look into the role of product management in the innovation process, I posed some basic questions to the audience. What is innovation? As a group, we had lots of potential definitions. What is a product? This question elicited almost no answers.

That result wasn't a surprise. For years, we've been hearing about how difficult it is to define product management. Perhaps that has something to do with the difficulty of defining the thing that product managers manage. We think we know products when we see them, in much the same fashion as Justice Potter Stewart famously defined obscenity, but we're a bit challenged to put into words exactly what they are. We can easily define them in the negative, such as consulting offerings that aren't products or IT projects that aren't products. We've all heard that products have life cycles, which isn't nearly as Darwinian as one might expect. (Many ideas that don't deserve to become products, do. Many that deserve to die, don't.) But, if pressed, we're at a loss to define what products are.

Read more

In SaaS, Product Management Is Essential, Not Optional

Blog post info and actions

Blog post body

Tom Grant

A while back, I had a spirited exchange with someone who took a rather extreme position about the role of product management in software as a service companies. The less polite version: He staked out a silly position – just poll your customers about what to build, and eliminate the PM role altogether – so I felt obliged to refute it. With two additional years of research into SaaS and PM, it's worth returning to that contretemps for a moment.

Then, I argued that PM was necessary in SaaS ventures.

Now, it's clear that PM is not merely necessary but essential.

Product Managers Are Really Innovation Managers
If the sole responsibility of PM were requirements, as my foil assumed, a poll might replace a person, but only if you had no interest in the long-term success of your company. Polls are extremely useful tools, and it's far better to use them than not to. However, polls have their limitations: most obviously, as a tool for taking the temperature of the customers you have, they tell you absolutely nothing about the customers you don't have yet.

This week, I've already written a little about the need to go beyond polls to use other tools, such as serious games. In an upcoming post, I'll have more to say on the topic. For now, I'll just say that, in both business and politics, voting alone is not the ticket to ultimate success.

Read more

Innovation Requires Authority, Not Power

Blog post info and actions

Blog post body

Tom Grant

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."

Who's responsible for adoption?

Read more

Product Management: You Get What You Pay For

Blog post info and actions

Blog post body

Tom Grant

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.

Read more

Why Your Sales Battle Cards Don't Work!

Blog post info and actions

Blog post body

Dean Davison

 

 

 

 

 

 

 

 

 

 

We recently interviewed dozens of sales enablement professionals within the tech vendor community. These interviews painted a less-than-ideal picture of how sales teams value and use competitive battle cards – that competitive battle cards are a relic from out-dated selling models.

 

Battle cards still focus on products – just as they did in the days when customers purchased one product over another based on a side-by-side comparison of their features. In those days, competitive intelligence teams created battle cards about competitors – their company financials, products, sales tactics, and weaknesses – literally for sales reps to keep in their pocket.

A sampling of battle cards that we collected from across the tech industry confirms that battle cards are fashioned from a product point of view and often created because they are among the checklist of items for product managers when creating sales content. Today, portfolio managers also use the term “battle card’ for almost anything prepared for sales teams. In addition to competitive battle cards, we uncovered materials labeled as battle cards that talked about:

  • Industry overviews. How a vendor’s products can combine into a new solution to meet the needs of customers in an industry that the vendor does not currently service.
  • Technology profiles. How the capabilities of a new or emerging technology will allow it to displace the products or solutions that customers currently use.
Read more

The Rise And Fall Of Complexity: Experience Versus Features

Blog post info and actions

Blog post body

Tom Grant

[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:

Read more

Product Management Is Political. Deal With It.

Blog post info and actions

Blog post body

Tom Grant

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.

Read more

Thought Leaders Are Good Story-Tellers

Blog post info and actions

Blog post body

Tom Grant

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.

Read more

Why Requirements Are Like Journalism

Blog post info and actions

Blog post body

Tom Grant

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.

Read more