The Productologist

Exploring the Depths of Product Management

Posts Tagged “Sales”

30 11 2009

Product Management Reader: 30Nov09

: Image by » Zitona « via Flickr

A shorter list than usual this time, thanks to the Thanksgiving holiday in the US, but that should in no way diminish the importance of any of the articles listed below. Besides, the list includes a post from April Dunford at Rocket Watcher, and she’s the best Product Management blogger in the world (Note: she’s actually from Canada, but we’ll let that slide).

Capturing Ideas
[Lead on Purpose]
Beta Applies to Messaging Too: Rogers On Demand Online
[Rocket Watcher]
6 “Bootstrapping” Tools for Software Product Managers
[Software Product Management]
Why ROI Is The WRONG Way To Measure Your Product’s Marketing Program
[Accidental Product Manager]
Can You Write Website Requirements Without a Product Manager
[Tyner Blain]
Product Marketing & Management + Sales Ops = Necessary Ingredients to Win
[OutsideIn View]
A Quick, Easy Way to Gather Info for Buyer Personas
[Buyer Personas]
Translation of The Cranky Product Manager
[Cranky Product Manager]

Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.

Popularity: 2% [?]

Product Management Question Corner: Rene Larro, Model N

Posted by Ivan Chalif in Customers, Engineering, Interviews, Marketing, Professional Development, Work/Life Balance

People, people…please calm down. I know that it’s been more than a month since the last Product Management Question Corner, but these things take time. Fortunately, this one is worth the wait! This edition of the Question Corner brings us Rene Larro, VP of Products and Solutions Marketing at Model N, a provider of revenue and compliance management software. Rene brings us the perspective of a Product Manager who started out as a traditional consultant and rose through the ranks of Product Management all the way to the VP level.

Q: How did you come into the role of Product Manager and was it planned?

A: Moving into Product Management wasn’t specifically planned, but throughout my career I’ve always been drawn to roles where I could be involved with both business and technology. In 1999, I made the jump from consulting to the startup world and joined Digital Impact as an Account Manager. At the time, DI was building out it’s second generation campaign management tools and I had the opportunity to work with the Product Management team as an internal beta user for one of our products. I was constantly talking with the Product Manager about things that “I thought the software could do better”. The more we worked together throughout the release cycle, the more I became interested in the role. When an opportunity came up to move into Product Management I jumped at it and have been in Product Management and Product Marketing ever since.

Q: What are the biggest challenges that Product Managers face?

A: One of the biggest challenges you face as a Product Manager is balancing the needs of your company as a business and the demands of your customers when making decisions about the roadmap and tradeoffs for a given release. New license sales are the lifeblood of an enterprise software company, and to successfully grow the business you need to continuously add new products to your portfolio to give you new things to sell. But, the more successful you are and the larger your customer base grows, there are increasing demands to add additional features and functionality to your existing products to keep your installed base happy. Your existing customers don’t always care about the great new product you’re bringing to market next year, they want you to focus on their issues, and to add their key features to the roadmap. There is never enough time or resources to do everything you want to do. It’s a delicate balance and there are always hard tradeoffs to make.

Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?

A: There are a few things that come to mind.

Get to really know your customers and the problems they are facing. You can’t be a successful product manager by sitting in your office. Get on the road, visit your customers, talk to them and sit with them while they use your products. I’m always amazed at the insights I get by sitting with users and watching them do their jobs. Customers love the attention, and truly appreciate it when Product Managers visit and listen to them. And sometimes, the simplest change in the app can turn a frustrated user into a champion.

Get to know your product and your technology inside out. The most successful product managers I’ve worked with become experts in their products, what they do, and how they are built. Great product managers develop a “feel” for what it takes to build their apps, and how their apps fit in with all the other pieces of their technology. Don’t be afraid to get into the details. You’ll get more respect from your engineers, you’ll be able to make better tradeoffs on effort vs. benefit, and ultimately make better decisions about your products.

Finally, get into the field and sell. Designing and delivering the best product in the world doesn’t mean anything if it doesn’t sell. At the end of the day, sales drives the business. If you want to be a real asset to your company, get out with the sales team and learn what works and doesn’t in the sales process.

Q: Where is the best place for the Product Management function in an organization and why?

A: For an enterprise application company, I’ve always believed that Product Management needs to report into the business, not to engineering. It’s easy for Product Mangers to get wrapped up in the day-to-day aspects of the internal side of the role. Reporting into the business helps ensure balance between the demands of building the product, with the necessity of ensuring the product is marketable and can be sold.

Q: If someone told you that they wanted to be a Product Manager, what would you tell them?

A: If you like working on challenging problems, want to be doing something different every day, thrive on being thrown into challenging situations, want to do both strategy and tactics, love getting into the details, and want to make a real difference in your organization, Product Management is a great role to be in.

I think it’s the most demanding job in a software company, but it’s also extremely rewarding. There is nothing better than slaving away on a product for a long period of time, seeing it go out the door, and then sitting down with users and watching them run their business with what you built.

Q: What is your greatest Product Management achievement?

A: Building a $50M enterprise software company from the ground up and having a product that has continued to sell even in an impossibly tough economy. Starting with just a technology platform in 2001, my team was responsible for defining and building an integrated application suite that now contains 12 applications, and is used by over 30 major Life Sciences companies across the pharmaceutical, bio-tech, and medical device segments to manage more than $80B in revenues.

_________________

And now for Rene’s question for The Productologist:

Q: What’s your opinion on the age old question of Product Marketing vs. Product Management. Should Product Managers own both sides, or is it two different roles?

A: What a poignant question given that I recently took a new position as Director of Product MARKETING. There has always been a blurry line between Product Management and Product Marketing. Depending on the company you are working for, these could be the same job, overlapping jobs, or completely different jobs. The complexity around this issue has been discussed at length on many Product Management blogs and in Product Management training classes.

The factors that determine if one person can do both Product Management and Product Marketing are numerous:

size of the company
maturity of the company
sophistication of the product(s)
number of products
other available marketing resources
comfort with talking to the field (Sales, Customers, Prospects)
comfort talking with outsiders (analytst, media, board members)
ability to balance more on your plate than you have room for

In my eyes, Product Management and Product Marketing are not the same, though they share some commmon goals and tasks. The skills necessary to be a great Product Manager and a great Product Marketer are not often found in the same person. Product Managers benefit from technical skills, relationships with/respect from Engineering, project management, and the ability to communicate effectively with internal and external constitents. They have to know the ins and outs of their products and be able to help the field identify how to tackle customer and prospect challenges.

Product Marketers are much more externally focused. They get out and evangelize the products. They work with customers, prospects, the field and oustiders to understand the market and set strategy for how to serve the market.

It’s hard to envision a single person who can do all of that and do it well. in most cases, they don’t. We all have strengths and weaknesses. We find way to compensate for our weaknesses. We get our favorite SE to do the really hard technical demos. We ask for help from someone in finance to help with our excel spreadsheet models. We get help from the PR specialist when we need to write up snazzy content for a presentation. We ask Technical documentation to explain (one last time) whether the API can do what we told the customer it could do.

Even if there are people out there who have the skills necessary to do both jobs, if you combine those two roles, that’s a lot of work to accomplish and you have to ask yourself if it is realistic for them to do all of those things. Can one person do all of that? Maybe, for a short period of time.

Many of us have been there before. Sixteen-hour days, seven days a week (well, maybe only 10 hours a day on weekends). It’s exciting at first, but after a while, it begins to grate. You start choosing your battles. You pick the ones that feel most comfortable. The ones that don’t find themselves at the bottom of a growing to-do list.

Can one person be both Product Manager and Product Marketer? Yes. They can even be successful if the requirements of the position and volume of work match their capabilities and capacity. But the reality is that in a mature organization with a complex product (or suite of products), the combined role is more than one person can reasonably handle.

A bit more about Rene:

Rene is the Vice President of Product and Solutions Marketing at Model N. Model N is an enterprise software company that provides Revenue Management solutions to Life Sciences and Hi-Tech manufacturers. He’s been with Model N for eight years and through that time has played numerous roles in various aspects of Product Management, Product Marketing & Pre-Sales. Rene was the original Product Manager in Model N’s Life Sciences Business Unit and was instrumental in driving the direction of Model N’s product suite and building the Product Management organization. Prior to Model N he was a Product Manager at Digital Impact, a Manager at Andersen Business Consulting, and he started his career as an Actuarial Analyst in the insurance industry. Rene has an MBA from the University of Michigan, and a BS in Managerial Economics from UC Davis.

Popularity: 3% [?]

MRDs: Too Much of a Bad Thing

Posted by Ivan Chalif in Best Practices, Documentation, Engineering, Marketing, Processes, Sales/SE

I have recently been embracing the change from traditional waterfall product development to an Agile framework. In the past, I have been wary of Agile, especially for enterprise products, but as I gained a better understanding of the Agile principles, I started liking it more. There are still caveats for using Agile methods and success of Agile process depends heavily on the staff managing the framework, but I am starting to see why Agile development is so appealing.

From a Product Management perspective, one of the most appealing aspects of Agile is how requirements documentation works. For many years, I spent a ridiculous amount of time creating requirements docs (primarily MRDs, but also some PRDs and TDDs). The reason for this is that MRDs have a broad audience. The same MRD that Developers and QA Engineers use to build their functional requirements also has to be read, understood, and digested by folks from the Sales, Support, Pro-Serv, and Marketing.

That means MRDs are chock full of data which can include some or all of the following topics:

Business Case
Revenue Model
Competitive Analysis
Market Analysis
Feature Descriptions
Feature Design
Staffing Requirements
and the kitchen sink

All of this data makes for a large and cumbersome document, both to create and to absorb. On more than one occassion, I have had to chase down folks who insisted on getting a copy of the MRD (and who promised to provide feedback), only to find that they had not even read it 3 weeks after I sent it to them (and sent out multiple reminders).

Ugh. A lot of work with little or no benefit.

What I like about Agile development is that most of the extra “fluff” is moved out of the requirements process. It’s usually still there in the release cycle, but it’s someplace else, like a hallway conversation with your CEO, or a presentation to the exec team, joining the Sales/Support team’s weekly staff call, or an on-going discussion with your manager. Those are the folks that care about the fluff part of requirements docs.

When you work with the Dev team, for the most part, they don’t care about the specifics around revenue, competitor analysis, or anything else not directly related to helping them write the code. That’s not to say they don’t care at all. Revenue should be very important to ALL employees, but as information that Developers need to do their jobs, those things just to add much value.

So, instead of a 30-page MRD, I like the 5-10 page release specs doc. I focus on what is in the release and what it should do. I usually add a bit about what problem it solves or how it would be useful so that the Dev team can use that information to better understand the requirement, but not much more than that.

To be honest, the short-n-sweet option doesn’t always work out as well as I would hope. It still requires having some lengthy discussions with Developers to iron out issues, but I’d have to do that with the big MRD, too, so why not save time and not write it, and then focus on getting the software built and into the hands of testers and users?

Less work for the Product Manager, which means more time to get out into the field, spend time with customers and partners, and listen to folks explain how I can help them with my product. Everybody wins!

Popularity: 4% [?]

Answers for a New Product Manager

Posted by Ivan Chalif in Best Practices, Communication, Customers, Professional Development

I saw a question on Linked In from a new Product Manager who is switching careers and wanted some pointers about how to make the transition smoothly. I answered the question with some suggestions. She is not a software Product Manager, as I am, so my response to her was not tied specifically to what I do as a software PM. I am re-posting a slightly modified version of my response here. Enjoy!

<original_response>

Welcome to Product Management. It’s a very challenging and rewarding field and provides a great opportunity to interact with many business functions.

I work as a software Product Manager, which is slightly different than what you are doing, but regardless, ANY Product Manager should be doing the following things to be successful:

Learn about your product(s).
Even if you are already familiar with them, do whatever you can to learn more. Review documentation, go to user training, talk to any “experts” within your organization about what they know about the product.
Listen to stakeholders.
Product Managers are the link between many different areas of the business. You will need to take those diverse and frequently conflicting interests into account as you make product decisions. Product Management is not a democracy, but it does require listening to, understanding, and synthesizing input from many different constituents.
Listen to users.
Every product or service has a user. It may be an external customer or an internal one. The Product Manager is the proxy for that user and all users. To effectively be that proxy, you need to listen to feedback from users, both positive and constructive. Don’t let others (Sales, Support, Executives, etc) be a filter. You have to hear for yourself.
Understand your business.
Beyond just making your own product successful, you need to know how your product fits into the overall corporate strategy and what the success factors for the company as whole are. Your decisions need to take those external factors into account.
Make decisions holistically.
Product Management is a long-term process and you will be faced with making many decisions almost every day. As you weigh the details of each situation, focus on how that decision will affect your product over time. The shortest, easiest option may look appealing, but also consider what that decision means for the future. Also consider that each decision is not made in a vacuum. Try to see how those decisions are linked together.
Take risks and embrace failure.
No one does everything right every time. Even with the best planning and analysis, things don’t turn out the way you think they will. Don’t be afraid to do something just because it might not work. If it’s not successful (or as successful as you thought it would be), figure out why and learn from it. A past manager of mine told me once that it is OK to make many mistakes, but not the same mistake more than once.

There is so much to Product Management that it is hard to sum up in short space and this is by no means an exhaustive list, but it should help make the transition a little easier. Some of the information you need to be a successful Product Manager only comes with experience and getting your hands dirty.

</original_response>

One thing I left off of my original response (because she was already doing it to some degree) is to talk to other Product Managers. Success as a PM in one organization does not guarantee success in another, but there is a lot of collective knowledge out there. Search out and use that knowledge to jump from rock to rock as you cross the river, rather than wading across on your own.

For starters, check out the other Product Management blogs I have listed in my blog roll on the right panel (look for the heading: BlogNation). They know a lot about a lot of PM topics. Just ask. They won’t bite.

Popularity: 61% [?]

It’s MY Product

Posted by Ivan Chalif in Communication, Engineering

I was at a SVPMA meeting last month where the presenter, Barbara Nelson from Pragmatic Marketing, was giving a talk about the “Politics of Agile” and during the course of the discussion, she brought up examples of products that she had managed in the past. What I noticed was that when Barbara talked about the products, she always referred to them as “her” products. That’s what I like–making the product personal.

In previous posts, I have referred to products that I have worked on as “MY” products because I believe that the Product Manager should feel a sense of ownership of their product(s). Despite not being the CEO of the Product, the Product Manager is the one person within an organization that has a wholly vested interest in the success of the product.

Now you may be saying, lots of people have a vested interest a successful product. Engineering, QA, Support, and Sales want the product to be successful, but that is not their key function. Engineering builds the product, but it doesn’t have to be the current product; it could be any product. QA tests the product to make sure that it is free of defects and strives to make the product as robust as possible, but again, the QA function is for any product. Same with Sales and Support. They all contribute to the success of the product, but they are not accountable for it and their function is not evaluated on whether a particular product is a “keeper” or a “dog”.

The Product Manager, on the other hand, is accountable for whether the product succeeds or fails, regardless of whether they were directly responsible for the failure (poor feature mix, lack of understanding the market, ineffective pricing) or not (missed delivery dates, bugs, etc). The Product Manager has to answer to the company and customers when their product fails. Conversely, the Product Manager gets to sing the praises of the entire team when the product succeeds.

The main reason that I stake the ownership of my products is that I want to demonstrate to others on my team that I am invested in the product and that I am committed to making choices about the product which will make it, the company and our customers successful. I know that I am not the only one on the team who wants the product to be a “keeper”, but I’m the one who is charged with making it a keeper.

Popularity: 54% [?]

Know Thy Neighbor

Posted by Ivan Chalif in Communication, Professional Development

As Product Managers, we spend a lot of time working with other groups—Prospects, Customers, Sales, Support, Engineering, Marketing, etc–to get our products up and running and out the door. Managing that diverse universe of contacts is an integral and frequently taxing function of the Product Manager’s role. But there is another group that many Product Managers that I know neglect to include in their universe of contacts: other Product Managers.

Read the rest of this entry »

Popularity: 61% [?]

Closing the Deal

Posted by Ivan Chalif in Best Practices, Sales/SE

Ever bought something expensive that you really wanted on sale at a massive discount? Or walked out of car dealership with a new (or used…er, previously-owned) car that you got for WAY below the asking price? That feeling is what drives sales people (of course, they tend to be on the other side of the equation, but the feeling is the same). Today, I got that feeling.

I didn’t get a new car or something expensive that I had been pining for. What I got was a discount on OEM hardware. Well, the truth is that I didn’t just get the discount…I negotiated it.

As a Product Manager, I am tasked with lots of negotiation, but for the most part, it’s largely non-monetary. I have to negotiate with Engineering to get a certain amount of features built into a release in a given release window. I have to negotiate with Support on what they see as the key bugs and enhancements and their priority. I have to negotiate with Sales on when the new features that will help them close “their biggest customer, ever” will make in into the product.

In actuality, the Product Manager spends a LOT of time negotiating, but since there is no money exchanging hands, that kind of negotiation seemed different than what I had to do with our OEM partner. It was much more nerve-wracking. I worried about what my counter-part on the opposite side of the equation would think about me. I worried that I wasn’t going to get the deal. That’s what makes getting the deal feel so good!

Contract negotiation is really a lot like gambling (and Poker in particular). Each player knows what cards they have, but they don’t know what cards the other players have and they don’t know what cards will come up from the deck. With Poker, you know that there are a finite number of combinations and to some degree, you can use statistical analysis and your gut instinct to know whether you are likely to have a good hand, but there is another element that you can use, too. The bluff.

Bluffing in Poker can turn a worthless hand into a winner. All you have to do is lie. Not in a bad way, like when you are shopping with a friend and you tell him or her that a shirt/jacket/sweater/pair of shoes look good, when in reality you are embarrassed just to be in the same timezone as them. It’s more of an omission, like when you were a kid and one of your parents (or a friend’s parents) asked you if you did something (e.g., stick your finger into your sibling’s birthday cake and scoop out some frosting…before the party started) and you said no (which was true), but you didn’t tell them who did , even though you knew (cousin Kenny, of course).

Bluffing makes your hand appear stronger and appearances are everything during negotiation. So I used a bluff to make my position vs. the OEM hardware vendor look stronger to them.

I told them that the original price and the subsequent discount that they offered was insufficient for me to commit to the deal. If they would meet my asking price at the volume I wanted, I would make sure the deal happened. If not, then I was prepared to walk away (that was the bluff). In reality, I needed the hardware and was willing to pay the price that they had originally proposed, but they didn’t know that.

But be careful…bluffing doesn’t always get you what you want and sometimes there are unintended consequences. It’s better not to have to bluff, because that losing hand that you have could stay a loser, and if it does you may lose credibility or leverage with the vendor for the next time you have to negotiate.

In this case, in the end, I got the pricing and volume that I wanted and they got the deal, so everybody wins.

Popularity: 30% [?]

Product Councils

Posted by Ivan Chalif in Best Practices, Customers, Engineering, Marketing, Processes, Sales/SE

One of my goals for this year is to establish Product Councils for my products. Product Councils, or Product Advisory Boards, as they are sometimes called, are made up of people who are familiar with your product and/or the market. In most cases, they are external, meaning that the members are customers or industry experts who can provide strategic guidance or provide feedback on tactical implementations, but they can also be made up of, wholly or in part, internal members.

I plan to have two; one made up of internal team members and one made up of customers. Both are necessary to help me grow the product to meet the needs of the market.

Internal Product Councils are comprised of key members of customer-facing teams at your company. While you can select anyone, I recommend having at least one member from the following teams: Sales, Sales Engineering, Support and Professional Services. Other groups you may want to include (if they are part of your organization) are Account Management, QA, Engineering, Business Development. Internal Product Councils are good for soliciting information for product messaging, new features, pricing, and early prototype review.

You can also use Internal Product Councils to find quick ways to address customer issues. I have found that having a pre-defined cross functional team has streamlined issue resolution process because there is a go-to team that knows all the key aspects of the product and the customer situation. In one case at a previous company, with the help of an internal product council, I was able to get a fast resolution on a high-priority product issue with some configuration changes and manual processes. Finding a quick workaround enabled us to spend time getting the right product fix instead of a right-now product fix.

Internal Product Councils also give other groups and team members a sense of ownership of the product. When other team members are involved in product-related decisions, there is a feeling of goodwill and teamwork generated. But let me be clear, I am NOT advocating that Product Managers should abdicate their product responsibilities to a committee. In my opinion, committee-designed products satisfy the requirements of no one but the committee. What I am advocating is engaging with co-workers in various business functions to help YOU, the Product Manager, make the best possible decision.

For example, while not an official Internal Product Council, I frequently use the viewpoints from the members of my Bug Scrub team to help me understand both the importance and scope of product issues. I regularly solicit their opinions and views on a variety of product and process issues, but I am still responsible for making the final decision. I would be foolish (and a poor Product Manager) if I thought that only I had the answers to solve product challenges, but it’s more important to view this input as a data point, not a decision. The Product Manager has the final responsibility for the product and that starts with decisions about features and process.

External Product Councils are similar in design, but utilize a different group of participants to achieve a different outcome. External Product Councils are especially valuable for getting feedback on new products, early prototypes, product bundles. Depending on the make up of the External Product Council, they may also be able to provide guidance on pricing, but this must be handled delicately, since some of the participants may be sensitive to that type of information. Before selecting members, determine how you want to use the External Product Council. This will help you identify who you want to solicit.

External Product Councils are made up of primarily customers, but may also have industry thought leaders or strategic partners. While it may be easy to just select the most vocal customers to be on your External Product Council, this is not necessarily a wise decision. Members should be selected based on several criteria:

Industry Name Recognition
External Product Councils are frequently publicized as a way of generating credibility and showcasing thought-leadership. For that reason, selecting members who will bring instant awareness is key. However, something to consider in this area is that it is possible to select a member with too much name recognition. While names like HP, Microsoft, Oracle, Sun, etc are definitely names that have cache, they are likely too big to have any real influence (unless your product is tightly integrated with their’s or in key verticals where that company is a clear leader.
Vertical Value
As with name recognition, the vertical value of an External Product Council member can vary based on the vertical market, the size of that market and the number of companies playing there. If there is vertical where your company or product(s) are not very strong, picking a customer who is in that vertical can help solidify your position there. Be careful not to engage with a member who might be polarizing within a vertical, as this could scare away potential customers who don’t want to be involved or associated with such companies.
Strategic Importance
Have you identified/designated any customers who are strategically important to your product and/or business? If not, you should consider it and provide selective special treatment (e.g., discounts on future purchases, support beyond what they pay for, an executive sponsor) to them. As part of that, an invitation to participate on the External Product Council shows your commitment to them, as well as how much you value their input. If they truly are strategic, you should want and value their product input and do what it takes to get it.
Relationship Development
Sometimes you have a customer or partner/reseller who you just have a difficult time with, be it dissatisfaction with product features, support difficulties, account management clashes or whatever. If the customer is not one that you want to chase, you can let some of their requests slide, but if they are important to you (maybe, despite their complaints, they continue to bring high value sales opportunities to your company. By offering them the opportunity to be in the External Product Council, you give them an additional voice and convey to them that they (and their concerns) are important to you. And they may choose to use their voice in the External Product Council, rather than through other channels.

Whatever criteria you use, make sure that your External Product Council has some elements of diversity. The point of having the External Product Council in the first place is to gain additional visibility into the current and future market requirements for your product(s). If your External Product Council is homogeneous, you may miss out on valuable information and subsequent market opportunities.

Before you embark on creating an Internal or External Product Council, make sure that you have first identified what you hope to gain by assembling them. I would also suggest starting with one or the other. The value you get out the first one may influence your decision to form the second one, as well as help to clarify what benefits you want to get from it.

This type of project is not one that you should rush into (especially if you are doing it because I said you should do it). Take some time to think about it and map out what your goals are and how you are going to accomplish them. Then proceed with patience and perseverance.

Popularity: 79% [?]

Product Manager Evaluation

Posted by Ivan Chalif in Customers, Processes, Professional Development

At my company, it’s annual review time, which means that I get to spend quality time writing about what I have accomplished over the past 12 months and how it relates to my role as Product Manager. Now, as an individual contributor, I like the annual review process (I’ve been on the management side, too, and that’s not as much fun). It gives me an opportunity to reflect on how far my product has come from a year ago, identify areas for growth and lets me campaign for a salary increase. But in a role like Product Manager, what are the best ways to evaluate success?

Marty Cagan, principal at Silicon Valley Product Group recently wrote in his blog about ways to measure Product Managers. He comments that there are many factors to consider (revenue, page views, profit, etc) but proposes using customer satisfaction and more specifically whether customers would recommend your product to others, as a key metric of Product Manager success. This method is called Net Promoter Score or NPS and is the focus of a book by Fred Reichheld called “The Ultimate Question.” Note: I have not read the book, so I am neither recommending it nor dissing its ideas or content.

Happy customers typically mean that your product is meeting the needs of users, either by filling a gap or by improving on an existing product’s capabilities, but I don’t see it as a universal success metric for Product Managers. There are too many other variables, not only within a Product Manager’s day-to-day responsibilities, but also as a function of the capabilities of the product and the match with the customers’ requirements.

In this article, I am only going to talk about the latter (the former is a topic all its own). There are many layers between the product and a satisfied customer. It starts with the initial engagement with the Sales team. If it was an inbound inquiry, did the Sales team respond quickly and effectively? If it was an outbound inquiry (read: cold call), was the Sales rep courteous and helpful in determining if the product was an appropriate solution for the prospect? The prospect’s experience with the first touch lasts for a long time.

I just recently heard a story from one of my Inside Sales reps about how she had a call with a prospect who was grateful to get a call from us because the prospect did not want to re-initiate contact with the previous Sales rep due to having had such a bad experience with him (a rep with a reputation for having made many, thankfully, is no longer with the company. How long had that prospect waited to move forward?

Other things affect customer satisfaction with your product, too. Did they have a good experience during the price negotiation? Does the product do what the Sales rep said it would? Have they successfully resolved working with the product support team? Do they hate their boss/job/company? Any of these could impact whether customer x is going to provide a positive score, but they don’t necessarily reflect how well a Product Manager is doing his or her job.

Jeff Lash also writes about what Product Managers should consider as they plan their professional growth. In his blog, he comments about what Product Managers shouldn’t do (all of his intros focus on how to be a BAD Product Manager–

If you want to be a bad product manager, don’t evaluate your performance or attempt to improve. Assume you’re doing a fine job and leave it at that. You were hired for the job and you’re still in it, so you can’t be doing that badly, right? You’ve read some articles and part of a book a few years ago, so you’ve got the basics covered, and since you’re actually doing product management, that’s the best way to learn.

Jeff goes on to comment on an article from PragmaticMarketing.com by Alyssa Dver called Are You Decent? The Naked Truth About Product Management Performance, which talks about Product Management self-evaluation. She addresses 4 topics, but I like the third one, Assess Yourself in a Measurable Mirror, the best. She lists several questions that Product Managers should ask themselves. The following ones struck me as especially valuable (some match the ones that Jeff highlighted, too)–

How many sales calls have you been invited to attend? Is that too many or not enough? Do you decline invitations because you are double-booked? Why haven’t you been invited to more? Is it because Sales has other people who are talented and know the product/market as well as you or is it because the salespeople see you as a liability, not an asset, with customers and prospects?

Do you prioritize a customer meeting over an internal meeting or other diversion? Are you getting in front of as many customers as possible to get product input and better yourself as a PM?

Would your boss hire you again if he/she went to another company? Would your colleagues act as good references for you with a future employer?

If you don’t ask yourself (and others) honest questions about your performance, you won’t have a yardstick to measure how you are doing as a Product Manager. Be prepared to ask painful questions and get (sometimes) painful feedback. It may not feel like it at the time, but you will be making yourself a better, more valuable Product Manager.

Popularity: 41% [?]

Clearly, You Aren’t Hearing Me

Posted by Ivan Chalif in Communication, Customers, Documentation

On a recent trip to a trade show, I witnessed an interaction (several, actually) that underscored the importance of clear communication. For Product Managers, this actually has applications on a few levels. Here’s what happened–

My return flight connected through Washington D.C. and unfortunately, the 767 that was originally scheduled had mechanical problems (or at least that’s what we were told) and a 757 was now what we would be flying. What this meant was that there were instantly 40 less seats available for customers. It also meant that seat assignments changed, but more about that later.

This flight obviously had a lot of connecting passengers, because the gate agents repeatedly announced that international passengers and those making connections should approach the ticket counter. Additionally anyone with seat assignments of H or J needed to go to the ticket counter for seat re-assignment, since the new plane didn’t have those seats (767’s have a 2-3-2 seating configuration (at least on United), but 757’s are configured 3-3). For about an hour before boarding was scheduled to begin, there was a steady stream of harried customers approaching the gate agents.

Each time one of these harried travelers asked about the status of their seat (re-assignment or upgrade), the gate agents kept responding with the following statement (or some variation thereof): “We’ve had a plane change.” What they meant was that there was an equipment change, but what most travelers heard was that there was a plane change (read: You are traveling and you have to take more than one flight), which sounded obvious to them.

They then asked their question again, wondering what changing planes had to do with their seat assignment or upgrade. This seemed to aggravate the gate staff and you could tell by their tone that they were annoyed by having to answer the same question twice for each traveler.

As an external observer, I could see that there was a disconnect between what the gate agents were saying and what the travelers were hearing, but it wasn’t obvious to the gate agents. The problem was that the gate agents were using an industry-specific term to communicate with their customers, who were not familiar with the term. Thus, the repeated disconnect and rising tension between the two parties.

If you have read this far, you may be wondering how this is relevant for Product Managers (congrats if you already know). The key is that Product Management, especially in software and technology, is laden with the secret language of jargon, buzzwords, acronyms and other terms that are confusing to customers, prospects, sales, management and others who you need to clearly understand what you write and say.

Whether it’s verbal communication on a customer call, visiting a prospect, working the booth at a trade show or written communications such as market requirements documents, slide presentation or email about a new product or feature, simplicity is the way to go.

When composing written communications, it’s OK to write your draft using your own secret language, but before you distribute it, make sure to review it, paying close attention to ways that you can remove the secret language elements and simplify the message. When you do that, that’s when you will connect with your audience and they will hear your message. And that’s what you really want as a Product Manager.

Popularity: 27% [?]

The Productologist

Exploring the Depths of Product Management

Posts Tagged “Sales”

Product Management Reader: 30Nov09

Related posts

Product Management Question Corner: Rene Larro, Model N

Related posts

MRDs: Too Much of a Bad Thing

Related posts

Answers for a New Product Manager

Related posts

It’s MY Product

Related posts

Know Thy Neighbor

Related posts

Closing the Deal

Related posts

Product Councils

Related posts

Product Manager Evaluation

Related posts

Clearly, You Aren’t Hearing Me

Related posts

Search

Categories

Archives

Props!

Tweets

In The Productologist Store

Subscribe to Feed

Meta

© Copyright 2007-2010 The Productologist. All Rights Reserved.