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.

Partnering for Strategic Breakthroughs

I thought I’d give this one a dry title - it’s really about the iPhone again. But I thought people would be pretty tired of iPhone posts by now.

So, for those of you who don’t follow the iPhone (both of you perhaps), Apple released the iPhone SDK. But they did something else that will end up driving many more iPhone sales than allowing you to download games - they added ENTERPRISE support. Yes, ENTERPRISE. It’s just that important. (I’m sure you know by now that your products are nothing if they’re not ready for the ENTERPRISE.)

You can now connect your iPhone directly to Exchange and get all your corporate email in one sleek, beautiful Apple-branded package. All the cool of Apple and all the IT-approvability of the Blackberry. And how did Apple do it? Did they hire dozens of developers to copy RIM’s BES gateway technology? Nope. They licensed ActiveSync. The trouble is that, as anyone who has ever owned a Windows Mobile device can attest, ActiveSync stinks. It just doesn’t work reliably. But you know what - no one cares. In one fell swoop Apple just did more damage to RIM then a dozen NTP lawsuits.

When you’re looking to take your product to the next level and add in the “killer” functionality that every single prospect asks for during demos you need to look long and hard at how you can buy or license that technology instead of building it yourself. RIM had nothing to license when the Blackberry first came out - ActiveSync was even worse back then anyway - so they had to do it themselves. But Apple went to the source and did in just a few months what RIM has spent millions of dollars building. So Apple knows what to do. What technology have you licensed for your product lately?

Do Product Managers need Domain Knowledge?

As part of the second Pragamatic Marketing blogfest, I’m responding to Steve Johnson’s post: “Everyone needs to know what we do here“.

In it, Steve writes about the need for domain knowledge for technology workers, particularly in regards to the business they are in and the needs of their market. Whether talking about engineers, marketers, sales people or product managers, everyone needs to understand the company’s strategic objectives as well as some aspect of market dynamics.

In this case, I can’t really argue too much with Steve. If key people in a company don’t have domain knowledge, then the question “Why not?” must be answered. Do your competitors have domain knowledge? Most likely, especially if they are leading you in the market. How can anyone run any kind of successful business without domain knowledge?

For technology companies, the questions to consider revolve around defining exactly what “domain knowledge” is, and how best to acquire and maintain it.

Domain knowledge, particularly in B2B technology companies, can be quite complex. Not only do Product Managers need to understand the overall market, but also market specifics that vary from geography to geography. They need to understand overall trends in the market, as well as technology and economic trends that could impact product performance. Then come the questions related to competitors — who are they, what are their strengths/weaknesses, and where are they heading? Finally, Product Managers need to understand their target customers in detail — what they do, what they find valuable, how they currently use your product (or one of your competitors), and why they would value yours.

All of these areas of knowledge constitute domain knowledge. The reality is, very few individuals can have a full understanding of all of this information. I believe there is a myth that the lone Product Manager can collect, analyse, understand and then react to all of this information. The reality is that technology companies should look at the Product Management function as opposed to the individual Product Manager, as the locus of this knowledge.

Clearly other teams in the company also have domain knowledge, but Product Management needs to collect it and put it all together to make a coherent picture out of it. To do that well, it can’t be the responsibility of a single individual. Companies should be thinking about Product Management teams for each of their products or product families.

Some companies seem to succeed in spite of themselves. You’ve all heard of (or maybe even worked for) at least one of these kinds of companies. They had an innovation that lead to a successful product, but couldn’t repeat that success. Why not? One of the principal reasons is lack of sufficient domain knowledge to make the leap to a second successful product.

Case Study

Remember Delrina Corp? The makers of WinFax? Back in the early 1990s, WinFax was the clear market leader for faxing on Windows operating systems. Everything in the company was focused on the Windows operating system.

I was a technical writer at the time, and was hired to join the “small but growing” Macintosh team at Delrina. The goal was, as I was told, to build out a whole product line of Macintosh products, with the first product being fax software. And who knew fax software better than Delrina, the people who invented it?

At the time, the core Macintosh development team consisted of three people: the lead (and sole) developer (Don), the QA engineer (Mike) and me (the tech writer).

During the development cycle of the first version of Delrina’s Macintosh fax software, a number of things happened that made me wonder if I’d made a good choice coming to Delrina.

Given that the three of us (Don, Mike and I) were virtually the only people in the entire company who had actually used a Macintosh, most people there only experienced the product through the documentation that I was writing (on a Windows PC using Ventura Publisher nonetheless — not my choice!).

On the Macintosh, the software worked by setting the fax-driver as the target for print jobs. This was done via the Chooser in the Macintosh environment.

At one cross-team meeting to review the development and documentation status, someone, I don’t recall who, asked:

“What are these Chooser and Finder things? Who named them that? Can we change them?”

I kid you not. I couldn’t make that up. Almost immediately Don looked at the person and stated, almost robotically:

“No we can’t change them or rename them. They are fundamental to the operation of the Macintosh.”

I gathered that this was not the first time he had uttered that line.

Later on, the issue of the product name came to light. At another cross-team meeting, it was announced that the naming committee had decided on a name for the product, and all software, documentation, marketing materials etc. should use the name. The name was….hold your breath: WinFax Mac.

Now, if you recall back to the early 1990s, it was the height of the Macintosh vs. Windows fight. Users in the Macintosh community were pretty vocal about their disdain for Windows.

Mike and I looked at each other and waited for Don to say something. Don made an attempt to hide his frustration and then tried to calmly explain why the prefix “Win” as in WinFax was not an acceptable name for a Macintosh product.

The Product Manager would have none of it. He explained the enormous brand equity “WinFax” had, and how strongly attached the name “WinFax” was to fax software and that the plan was to leverage it in this new foray in the Macintosh market. Mike also tried to explain the issues with using “Win” in the name of a Macintosh product and was also shut-down.

A couple of months later, at yet another cross-team meeting, the PM announced that feedback had been received from a large number of beta customers indicating their dislike of the product name, and thus a new name would be found without the prefix “Win” in it. Mike, Don and I looked at each other and rolled our eyes.

Once the project was complete, I decided to leave the company and find employment elsewhere. Even back then, early in my career, I could see the dark days ahead if I stayed at Delrina. I found work at a startup, but continued to track Delrina and their Macintosh product line. A few months later, I saw a review of the product in a computer magazine. The review was OK, but the documentation got a 4 out of 5! I still have a copy of that manual.

As it turned out, the fax product was Delrina’s first and last Macintosh product. Aside from Delrina’s lack of knowledge about the Macintosh computer and user community, they also didn’t understand the dynamics of the Macintosh fax market. Delrina had succeeded in the Windows market by being first to market with an innovative product, and then controlling the channels by signing OEM deals with virtually every PC fax hardware manufacturer. In short, virtually every PC faxmodem that shipped at the time came bundled with a copy of WinFax Lite.

The same strategy had already been executed by other Macintosh fax software manufacturers. So when Delrina entered the Macintosh market, it not only was a late entrant, but the channels were all tied up by competitors. Their strategy, leveraging their Windows dominance to enter the Macintosh market was completely useless. And why? Quite simply because they had no real domain knowledge or true understanding of the market they were entering. Decisions made in a vacuum always look pretty good at the time.

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 

Here’s the deal with Biz Dev (Part I)

Saeed has posted two fairly provocative items about business development. (Here are the first and the second.) Frankly, Saeed, you’re not following your own advice. To paraphrase you, “Enough with the missives about Biz Dev”.

If you’re getting annoyed by what’s going on in your company, then you have two choices — help fix it, or move on. There are a couple of other choices actually, such as do nothing, or complain about it on your blog, but to be honest, if that’s what you do, then you’re not as great a product manager as you think you are.

hmm.

Certainly it’s easy to poke a stick at biz dev, and I could tell a few stories of my own. Several years ago, Intel was courting my CEO to have us port my product line to the Itanium chip, and thankfully I got to meet the Intel guy with my CEO for espresso at the old Starbucks by Moscone before we committed to anything. We were interested seeing what Intel might offer us, and my CEO really wanted to ink a deal with them. As Saeed said, it was “strategic”, and the Intel logo would look really great on our investor slide deck, or so our CEO felt. As is well known, the Itanium chip was a failure. Thankfully we didn’t invest.

In fact when we poked at Intel’s proposal, we found that the market for our product on Itanium would have been tiny; it would have been a tool to help people writing apps directly to the Intel metal, a specious group who wasn’t likely to increase our revenue. I suggested that Intel could pay a very large sum for our source code with an exclusive license on its doomed chip, but Intel didn’t bite. At that point our CEO saw that the logo on the Powerpoint slide wasn’t worth the distraction.

But I have also seen business development add major value to a company. When I was at Wily Technology, I saw how business development could be used strategically to strap a rocket to the company and create the engine for the company’s phenomenal growth. (And it was phenomenal. Eventually we were acquired for $375M, greatly exceeding the multiples of our peer group.)
What’s the difference between Saeed’s experience with BD and the Wily success story? It boils down to strategy, alignment, and value creation.

I’ll elaborate in future posts on this topic, so please stay tuned.

What do you want to read about?

Hello. We’ve been at this for a couple of months now, writing about various PM related (and sometimes unrelated) topics. And while we will continue posting as we see fit, we also want to hear from you about what topics you’d like us to cover.

Now that may be atypical of blogs, to ask readers what they want to hear about, but being Product Managers, it would be unnatural of us not to ask.

Is there something about Product Management or Development or Innovation that piques your interest? Want to know more about product pricing, positioning, process or partnerships? Any interest in SaaS or Agile? Want to know more about designing demos? Got a burning question you want to ask?

• What would you like to read about?
• Is there anything we’ve written, that you’d like to see more of?
• Is there anything we should stop writing about?

Let us know.

What’s the deal with BizDev? pt. 2

James McGuirk left a detailed comment on my original post that warranted a response.

Nicely written article and one that addresses the likely perspective of a product-oriented organization. Fundamentally they have interest in cultivating relationships with larger vendors which inherently increases the possibility (at least) of expanding the channel.

Thanks, and yes, correct, though I’d have to say it is from the perspective of a market-driven product organization. i.e. the clash between an overall market focus for products vs. a deal-driven partner/customer focus is the crux of the problem. As I mentioned in my comment to Mike Sabat:

In a sales driven company, product follows the transaction. i.e. the company builds the product to fulfill the transaction criteria.

…

In a market driven company, which is where Product Management looks at overall market needs (and not strictly at individual customer needs), the transaction follows the product. i.e. the company sells what is built with little or no modification.

While sales-driven and market-driven may not sound like they are too far apart, they are almost complete opposites when thought of from an operational perspective. But I digress.

James continued:

My perspective on business development however is derived from the vantage point of a systems integrator, where there are significant differences between services and product. As someone who has spent over 20 years within federal business development, the term implies an understanding of all aspects of winning business.

Companies that sell services, or sell products which include services, are almost always transaction-oriented, and therefore sales driven. I can sell you my generic product, but also sell you services to customize the product for you in some way. As soon as the services component comes in, even if the service is simply to help someone choose a product, the particular needs of the individual customer drive the activity.

In aggregate therefore, business development experts within the federal marketplace should have all those aforementioned qualities to be successful. Suffice it to say because of the level of comprehensive knowledge required, their expertise is always welcomed. Hope that helps. Jim.

The aforementioned qualities laid out in James’ comment are: Sales, Marketing, Capture Management, Proposal Management. What James describes is a different type of business development than what I was describing. In a product development company (vs. a services company), BizDev is usually part of of the Channels organization. It’s goal, as James mentions, is to expand the channel. But the issue that has frustrated me is the way many BizDev managers go about it.

Sales people are told to sell the current product. They can’t sell futures and they can’t make promises of future functionality, even if it is “on the roadmap”. But BizDev managers aren’t always held by these rules, even though they are fundamentally also sales people. I’ve seen too many cases where they sell futures (in the name of being strategic), and they discuss issues that are way off the roadmap — like the IBM mainframe port I mentioned previously. When this happen, serious misalignment occurs.

I have no issue with BizDev or Strategic Alliances in general. I see the need for them clearly. But I also have the responsibility as a Product Manager to do what is best for the product and the company. And much more often than not, that means saying “No” to rogue BizDev managers (and even, with some professional risk, Senior Management), when they go “off roadmap” and start looking for that “company making deal” (I’ve heard that phrase far too often) with some gargantuan organization that frankly, is going to waste a lot of our time, and is unlikely to ever close the deal from their end.

What’s the deal with BizDev?

I’ve worked in a few companies that had a role called “Business Development”. I have to say, this is probably one of the most poorly defined and managed roles I’ve seen in any of these companies. Usually “Business Development” means “Strategic Alliances”. Now what does that mean?