How others see Product Managers

So, first off I (Ethan) have started a new job. And I have to admit it: I am no longer a Product Manager. I have taken a job as a Technical Account Manager at a certain large search engine company located in Mountain View (California). So I’m going to be on the front lines for a change, working with large partners to get our products implemented. SVPMA members feel free to drop a line so I can look out for you at the next SVPMA meeting.

But to my real point: I was eating lunch with some of my new co-workers today who are a mixture of pre-sales (SEs) and post-sales (TAMs). One person was complaining about some of our Product Managers. To almost-quote: “he wanted all the glory without having to do any of the hard work.” Another person commented that the PMs often went ahead of started selling features to partners that were somewhere between difficult and impossible to implement. It was the exact opposite of the stereotypical sales situation: here were the sales people telling the PM to shut up and stop overselling.

I protested vehemently, of course, but for the most part I had to agree with them. Worrying about ease of implementation or supportability is often low on the PM’s list of priorities. People want to import data from SAP - well let’s build it! And who cares that it will take fifty people to implement it? That’s Services’ problem. My bonus depends on putting out new features.

So, if you want to be a Good Product Manager, build great new features that customers will use and love. But if you want to be a Great Product Manager, build great new features that your coworkers in services and support can actually deal with. In the fast-paced markets most of us work in the strategy of “Ready, Fire, Aim” builds buzz and can get a lot of press, but does it build a sustainable business? Rarely.

A no-demo tradeshow…

So, a few weeks back, a number of Product Management bloggers were invited to participate in a “blogfest” (blogapalooza?), responding to Steve Johnson’s post entitled “Why Demo at Tradeshows?“

Both Ethan and I responded to the call.

Having said what I said — give me the opportunity to have a meaningful one-on-one conversation with a valid prospect, and I’ll certainly trade a quick demo for it — I’m a bit surprised that I recently attended a small summit and tradeshow (200 attendees), and in two days, had a number of conversations with a number of individuals at our small “demopod”, and never once did I show running software.

A few key Powerpoint slides and references to the product brochures and data sheets were all that was needed to explain what we did, answer questions and scan their badges.

So, on one level, I admit that Steve (and those who agreed with him) had a point about tradeshow conversations. But on another level, I must also say that the small size of the show was a factor. Many of the people were more interested in the iPod we were giving away versus the software we had to sell.

So, perhaps the attendees read Steve’s article and agreed with him that they didn’t need a demo, or perhaps they were simply preoccupied with the end of the quarter, or maybe they wanted a demo, but because we never offered one, they didn’t muster the courage to ask. Or, maybe there was another reason, but in the end, I noted, somewhat surprisingly that after two days, no demo was presented. A first in my experience.

Saeed

How to be a GREAT Product Manager (part 6)

Own the product from conception to completion and beyond

In my early product management jobs, I focused a lot on the process of product management. A CEO of a startup I worked for told me that my approach to product management was “very academic” in nature. He viewed himself as a “get it done by any means necessary” entrepreneur, while I viewed myself as a”get it done right” product manager.

The startup was a very sales/deal driven company, as many startups tend to be. Putting product management in place in such an organization is not easy. But having a process focus is very important for a product manager. Every other function, from sales to marketing to development to finance to HR implement processes.

But because product managers work across these functional units, people don’t realize or understand that even in small companies there must be a repeatable and scalable process to conceive, research, define, develop, test, launch, promote, sell, support and sustain winning products!

And while product managers have a direct responsibility in some of these 10 areas and indirect responsibility in others, PMs absolutely have a core responsibility to oversee and align the activities of other teams across this entire process. I’m not talking about managing those people directly or telling them what they should do. I’m assuming people know how to do their respective jobs. What I am saying is that if you want to be a great Product Manager, take ownership (not necessarily full control) over the process and lead the teams in alignment through it.

Get alignment from the very beginning
From the start, as you (and/or your PM team) are doing your research, clearly define the context and vocabulary necessary to effectively convey the research results to the intended audiences. This vocabulary, whether related to personae/roles, business functions, consumer needs, product architecture or functionality or something else, will become key to bringing everyone into the same frame of reference. This is important because it helps to minimize misinterpretations and miscommunication during the product development and launch process. If people aren’t aligned early on in the process, you are likely to see confusion or conflict later on as requirements are implemented incorrectly or with unacceptable constraints.

As an example, before becoming a product manager, I worked at a company that was developing a fairly sophisticated reporting and visualization framework for business and financial data. One of the engineers was tasked with the requirement to create a flexible means to allow users to format and display numeric and character text (including time, date and multiple international currency values) dynamically for display in pop-up boxes when on-screen entities were moused-over. Are you with me?

He went off, did some research and without a lot of internal discussion, implemented functionality to address the requirement. I was responsible for documenting the functionality. When I saw what he had developed, I was stunned. He had created a flexible — but incredibly complicated — formatting subsystem. Yes, it could do everything and more relative to the requirement, but I’m certain only the engineer and a few other technical people could actually use it. The documentation for this functionality took 60 pages (out of a 600 page reference manual). When people in the company saw how complex it was, the functionality was removed from the product.

What went wrong? A number of things including lack of internal communication, lack of oversight, and lack of involvement from the product manager. Where was he during all this? I don’t recall exactly, but I think he was out, working with sales and trying to close some deals. Helping sales is good. Don’t get me wrong. But not when it comes at the expense of the product being built.

Get your hands good and dirty
During the development cycle, work to keep other teams such as marketing, product marketing, sales, sales consulting, support, channels, alliances and professional services informed and educated on the development status and product functionality. For smaller consumer products or websites, this may not be a difficult task, but for larger enterprise or data center software, this can be a daunting task.

For a major release of a large product, a development cycle will last 12 months or more. There are many decisions that are made during this cycle that need to be conveyed to downstream teams to ensure they can plan ahead for the impact of the new release.

Don’t stop until adoption is clear
Once the product is released, you need to stay focused on the product. You can’t let up and simply go start gathering requirements for the next release. Stay engaged with early customers, partners and the customer facing teams such as sales and professional services. If early customers are upgrading to the new release from a previous version, track those upgrades and follow up with the customers to see how the upgrade went and what comments they have about the new release.

Join members of the sales team on customer and prospect calls and listen to how they are describing and selling the new release, and what the reaction is from the audiences.

• Are the salespeople on message?
• Are the sales consultants adequately trained?
• Do the demos hit on target?
• Is the market need that you researched and identified oh so long ago, still as relevant and critical as it was back then?

These questions (as well as others) should be the focus of product managers (and product marketers) after product launch.

All too often, I’ve seen people work on a release, have it launch, and then essentially forget about it as they start focusing on the next release. Big mistake. If sales is struggling to sell the product, as the Product Manager, you need to take the challenge on and work to identify and remove the barriers.

Don’t look at it as someone else’s job because it isn’t. Would a CEO let a struggling VP of Sales flounder for a quarter or two? Absolutely not. As a PM, take your cues from the CEO and within reason, do what a CEO would do. Don’t wait for others to tell you what needs to be done. Take charge of your product, make sure it is built right and then ensure it trounces the competition.

Saeed

Part 5 - Be an integrator, translator and communicator

How to be a GREAT Product Manager (part 5)

Be an integrator, translator and communicator. Don’t be a terminator.

I’m sure you’ve heard the phrase that Product Managers are “the hub of the wheel”. I really don’t like that line. Who wants to be the hub of any wheel? That’s like saying someone is the hinge of the door or the latch of the hood. Boooring! And not true.

Product Managers are collectors, analyzers and dispensers of information. They are routers of information flow. And being a great product manager means understanding how to optimize the information flow so that other teams in your company who are directly or indirectly dependent on you for information get it in a timely manner and in a form they can understand and use.

The following image is a coarse example of the major communication paths that exists in a software company. The blue are internal teams and the red are external.

[click to enlarge]

I say a coarse example, because it really only represents a high-level view of how information flows. Not all links in the diagram contain the same amount of information flow; not all nodes contribute as much information as they receive; and to keep the diagram from becoming cluttered, a number of links that rightfully should be shown are not.

I call these communication pathways the Information Supply Chain. And as a Product Manager, you are directly or indirectly responsible for a lot of the product and technical information that flows throughout your organization. How many times have you been asked if certain functionality is in an upcoming release? Or when a particular release is coming out? Or the details of a beta program? Or whether any pricing or packaging changes are being made to address market needs?

People are asking these questions because they are making decisions and need information to decide wisely. You can have a significant positive impact on those teams if you understand what information people need, when they need it, and in what form they need it? If you can do that for them, they’ll be able to make educated decisions sooner, streamline their work and be more effective. Deliver meager, late or difficult to understand information, and the opposite occurs. There is a real top-line impact to poor information flow in a company.

If you really want be analytic about mapping out the flow, you can do that. You need to look at all the stages of the product development cycle, from conception to completion to launch and beyond, and map out what information different groups need and when they need it. One way to represent it is via a heatmap that may end up looking something like this.

[click to enlarge]

The coloured cells represent areas where communication happens during the development cycle. The deeper the colour, or higher the number (from 1-3 in this case), then the more activity and information flow that happens. As you can see, Product Management is deeply involved in the information flow through all phases of the development cycle, but most heavily early on and in the middle, whereas Marketing and Sales, for example, really start toward the middle and have heavy information flow from the launch stages onward.

By understanding this, you can determine what information you need to produce and deliver to those groups to optimize their activities and decisions. Keep in mind that this is not solely a task for Product Management. Ideally all groups in the company use this analysis to optimize their communications. But, if you want to apply an 80/20 rule (80% impact for 20% effort), then teams like Product Management and Product Marketing must be the first ones to optimize their information flow to other downstream groups.

As technology workers, we exist in an information economy. And just like the manufacturing world, where materials, parts and inventory requirements are optimized for efficiency and minimizing costs, information needs can be understood and delivery processes optimized for greater efficiencies. And because of our role in defining product direction and driving strategy, Product Managers can play a key role in optimizing the Information Supply Chain. The question is, are you up to the task?

Saeed

Part 4 - The 4 Cs of leadership

Part 6 - Own the product from conception to completion and beyond 

And another thing. Software demos need serious help

Most product demos are really terrible. SEs - at least a lot of the ones that I’ve seen - love to focus on the product features, but forget that they have an audience with specific goals and problems, and the audience doesn’t really care about the software; they care about achieving their own goals or solving a problem.

Why I hate PowerPoint

I hate PowerPoint. I hate what it has done to modern meetings, and I hate the fact that it is expected that one will produce slides for each meeting. Am I being a little strong here? Maybe the verb should be lament. Yes, I lament the dominance of PowerPoint in today’s meetings.

Can we chat about sales introductions?

Call me strange. I will often listen to a sales introduction or a marketing pitches even when I’m not interested in the product. It intrigues me to explore what works and what does not. Today I got one that made me chuckle. On the surface, this sales rep is telling me that his company might be able to help me improve my profitability goals: