How much do you think the product manager should be involved in hiring new team members? At my current position I am involved in a bit of a professional tiff over hiring. I think if they’re team members who are going to be offering technical or administrative support to my product than I have an obligation to be involved. Part of the problem also stems from the recruitment team we’ve been working with; I have been pushing to find more folks through recruiting sites and other marketplaces where we can get specialized recruiters without breaking the bank. But, I have been at odds with both project and hiring managers who seem territorial. Am I over-stepping my boundaries or do I have a case?

Answer from Derek Britton of Micro Focus: It’s not 100% clear to me whether this question refers to hiring other PM’s into your team, or whether you mean hiring others in the organization who will be directly contributing to your Product area. I’ve therefore covered both.

Who recruits is actually a question that goes right to the very heart of whether the Product Manager has true operational responsibility for the entire go-to-market success of a product, or whether they are merely responsible for helping shape strategy and product delivery, reporting to others who own the “business” side.

Re-stated, the question is “Who shapes the team that delivers on the vision (including revenue results, go to market activity etc.) for a product”? Should it, as you might think, be something the Product Manager decides? In an ideal world, we’d all like to think so. But for other teams? What about the fact that the skills required might be (especially sales, maybe very technical positions, even some marketing expertise) unknown (or at least not clearly known) to us. Surely we have to defer to the relevant functional leaders. I mean, if it is a sales guy, surely it is the sales manager who has to do the hiring, as he has the best skills to make the best judgment; otherwise, what is the sales manager’s functional remit? When you consider functional specialism, it is abundantly clear you have to defer responsibility for recruitment to those functional leaders, and trust them to recruit the right staff.

Having said that, you absolutely have every right to — at the very least — specify any product-area-specific requirements you have to that functional leader. Certainly in the cases where the recruitment is going to be unique to your product area (if that is the case, trust me you are fortunate), you may be looking for a unique type of skill, a specific background, a certain demeanor, etc. This may even be part of an existing product area business plan, in which case any failure to listen to your input can be flagged to those responsible for that plan (assuming again it isn’t just you). In software, there is a big difference between repeatable, transactional selling of “upgrades” of existing kit, as compared with new-site major enterprise deals. The sales skills required for each are so different as to be almost mutually exclusive. This does have an impact on recruitment — it is your prerogative to raise such matters.

Where you do want to specify needs, I think that agreeing your requirements with the interviewers (and for the job spec, obviously) would be sufficient. I can’t imagine you necessarily want or need to interview all candidates for a role in another team, for example. Where the teams are separate functional disciplines, again such as sales, development, even marketing, certainly F&A, you’d want to leave that to the functional leads, and simply give input as necessary. If the “team” in question is somewhere within the overall PM organization (however it is structured), you have a stronger case for attending the interview, of course. But again, the leader of the function is probably ultimately going to have the say in terms of who poses the questions. In my role, we have tended to have “informal chats” lined up after the interview where other PMs can get to know any good candidates, to at least have a view of a first impression, but the actual interview process only involves the boss and one other team member, not the whole gang. Frankly, countless people asking similar questions is not a good use of time and does not convey much trust in those doing the interviewing.

To summarise, my personal view here is that the PM should be informed and involved, but not necessarily directly taking part, in any wider (non-PM) team recruitment. For the PM team itself, the involvement is more hands on. Where the recruitment is outsourced in some way, certainly in terms of the initial screening, then the initial specification must be rock solid –and you can stipulate that in the service agreement with your supplier.

Finally, any “tiff” needs to be resolved, face to face. If you have an “issue” with recruitment, you need to understand yourself what you think is amiss, and be sure your view is based on a professional principle, not a personal perspective. I know people who want to control every aspect of their PM sphere of influence, but it invariably results in them alienating people who don’t appreciate the implied lack of trust. The subtleties of influencing skills may be required to yield the best possible results in this case. If you just don’t think your recruiter grasps what is needed, then you have to explain the “gap” in terms of the business value the role needs and therefore the skills required. It isn’t a scalable fix to try to conduct the interviews yourself.

While this response covers a lot of ground, the question implies a lot of possible scenarios, so I was hoping this will be a good general guide and will hopefully cover your specific case. If not just send further comments and I’m sure we can pick up the more specific thread.

How much of a product managers time is spent on project management? How hands on is the product manager during a project phase?

I’m in a situation where I’ve been given more responsibilities without having my previous responsibilities reduced. I would like to know what tasks I should keep, what task I should delegate.

Answer from Derek Morrison of All About Product Management: Tasks that a Product Management performs will vary from company to company and industry to industry. Even within the same organisation the job of the product manager can vary depending on the product portfolio and the type of stakeholders you have to deal with. Bottom line is that there is no straightforward answer to the questions you asked. However there are a number of questions you should ask yourself in order to know what is right for you and your career:

1. Are the additional responsibilities you’ve been given temporary or permanent?
2. If permanent, will they enhance or detract from your product management tasks?
3. If temporary, how long will the additional tasks be your responsibility?
4. Does your organisation use project mangers, and if they do, why are they not using them on your project/products?
5. What’s the financial health of your company – is it becoming necessary to double up on roles due to lack of funding and sponsorship?

Many companies (consciously or subconsciously) combine the job of product manager with other roles such as: technical support, technical sales, business analyst or systems analyst, and — yes you’ve guessed it — project management. Doing so means that the product does not always get the focus it deserves – which results in a less competitive product being launched into the market.

Ultimately you need to be careful that the additional tasks do not detract from your key responsibilities: that of discovering and defining new products and enhancements to your current products and solving customer problems in an innovative way. Wherever possible you should delegate, to the appropriate people, any task that prevents you from focusing on the strategic inbound tasks.

Amy C. Edmondson writes in July’s edition of HBR that “A focus on getting things done, and done right, crowds out the experimentation and reflection vital to sustainable success. “ Bottom line is there may not be a straightforward answer but be careful that you don’t become the critical link in project managing the current product design that you don’t have time to think about the next one.

What is the role of product management within consulting and training services providers? What are the activities of product management should take place in this case according to best practices through the whole product lifecycle from idea to delivered service? Can we consider consulting or training services as a product?

Answer from Steve Johnson of Pragmatic Marketing: What’s a product? What is a service? And with today’s business models, is there even a difference? For most people, a “product” comes in a box; a “service” doesn’t. A “product” has a one-time charge; a service has a subscription fee. I buy Netflix to receive DVDs though the mail and a pay a monthly charge; it doesn’t come in a box; it’s a service. I buy a ROKU receiver for my Netflix service; it has a one-time charge; it comes in a box; it’s a product.

Here’s the important point: so what? How is product management different for products and services? Products and services alike need to be defined before they are delivered, priced before they are sold, and positioned before they are marketed.

Pragmatic Marketing has defined the activities of product management in the Pragmatic Marketing Framework. The framework illustrates the breadth of activities in defining and delivering products to market. The importance of these items vary through the lifecycle of a product but each must be addressed in one way or another.

The real challenge in the world of product and services is that many product managers are actually product designers, development managers and operations managers. If you’re a real business and not a hobby, you should have full-time professionals staffing these roles—design, development, and operations. These roles may change somewhat depending on how the product is delivered.

At Pragmatic Marketing, we offer training and consulting. Each product that we offer has been defined, priced, and packaged before it is delivered. The more you deliver the same thing to more people, the better you get at it.

By the way, I wrote about professional services as a special form of packaged services in Product Management and Services.

I have less experience in the industry / domain than most of the people with whom I work. How do you convince an audience that has spent more time working in the domain than you, that you have something that they should listen to? How have you managed to say that ‘persuasively’?

Answer from Adam Bullied of Write That Down: I’m going to strip this question down a little bit in order to address what I believe is being asked. Essentially, how can a product manager easily change industries?

This can easily be perceived as something that’s more challenging than it is. Especially if you are joining up with an organization that has founders (or a management team) with extensive experience in the industry the company is in.

It’s daunting. How can you possibly execute effectively and ramp up in time to add any value when others already have years upon years over you in knowledge about users, competitors, what works and what doesn’t, and many other factors.

To me, the answer is all about having the right fundamentals and knowing what being a product manager means.

I’m now on my third industry as a PM (enterprise e-commerce, then digital music, and now online travel) and each time I do dive in to something new, it has been much easier than the last. There are a couple of reasons why this is the case. And funny enough, it’s very similar to sales.

I’m sure everyone has heard the expression, “he could sell ice to an Eskimo!” Usually, it’s used to refer to someone who has an extremely firm, death-like grasp on what it means to sell something. Anything, really. Some widgets.

They can pick out who to push something on, and then once they start talking to that person (or those people) really pinpoint how and what to say to them to get them excited about the prospect of completing the order. And then they actually complete the order and get the money.

In all reality, this example refers to someone that doesn’t need to be an ice expert in order to close an order. All they have to know is the science (and the art) of selling.

Product management is extremely similar. I think there are just some more layers to it. To me, it boils down to one thing — you just need to know how to ship a product.

You need to know there are users that have a problem. They need a solution to it. You envision that solution (with the help of your peers) and then construct a multi-step plan (your roadmap) to deliver on that solution. Then those users you are trying to solve the problem for will tell you if you are right or not, or even if you are relevant or not.

I will always respect and try to leverage the knowledge of those with deep and broad industry experience. They have some great wisdom that can help you avoid potential landmines, or tell you what they have already tried, whether it failed or not (and hopefully) why it failed — or, why it was wildly successful.

For example, I’ve stepped into organizations that belong to an industry with which I literally have zero familiarity. I’ve created a product definition and complete roadmap (that only changed based on date for a six month time span) and pushed hard to execute and get that product out the door.

You really have to put yourself in the shoes of your user. Did it really matter if I experienced all they would experience or had all the knowledge the others in the business might? Not a chance.

The reason for this is very easy — and at the risk of repeating myself, I think the message is crucial enough to re-state. If you identify the problem, who you are solving it for, and then the stages by which it will be solved, you have already done more than those with all of the “industry knowledge and experience” have done - otherwise, you wouldn’t be in the organization at all to begin with.

If you take a step back and see this for what it is, it really is a career choice for you personally. Do you want to be a professional “industry veteran” that knows everything there is to know about the entire market and process of making and delivering a single type of widget?

Or, do you want to be a professional product manager who is outstanding at shipping product? My choice is the latter — I would rather be very good at shipping great products than I would be very good at shipping only one kind of product within only one industry.

Don’t let industry experience fool you for actual smarts and know-how. That’s a wolf in sheep’s clothing, because you will start to put too much stock into what those experts have to say instead of listening to your instinct, and in fact, listening to your aggregated user data and statistics.

And that’s what being a professional product manager is all about.

Answer from Jeff Lash of How To Be A Good Product Manager: This is an easy question to answer — there really are not many! Product management still is much more of a role where people learn on the job, as opposed to in school. If you ask 100 product managers, I would bet that at least 90 of them did not learn anything about “product management” specifically in their undergraduate or graduate programs.

The University of Wisconsin — with their Center for Brand and Product Management — is really the only U.S. university I am aware of that has a curriculum focused on product management. In addition to an MBA curriculum, they also have some Product Management Certificate options. The Illinois Institute of Technology has an interesting Master of Design / MBA joint program that covers product development from the “business” perspective and the “design” perspective, though they do not appear to have any courses on product management itself.

Many MBA programs have some elective courses which cover product management, product development, or related issues. Though these can be helpful for your product management education, they may deal more with issues outside the area of business in which you are interested (e.g. you want to manage a Web 2.0 consumer product and you learn about pricing strategies for industrial chemicals), and they rarely cover the day-to-day issues product managers face (e.g. How can a product manager motivate sales? or How to track and manage feature requests?). Don’t get me wrong — undergraduate- or graduate-level courses on product management are useful if you can find them, though they are not the holy grail. I certainly learned some useful information from the Product Management course I took as part of my MBA program, though I learned a lot more by actually being a product manager.

A lot of people have questions about product management education and product management certification, and usually they are asking because they want a job as a product manager. There is no silver bullet to becoming a product manager. An MBA course may help — a whole program, like the University of Wisconsin’s will likely help even more — and certification will help too, though in the end, anyone hiring a product manager is going to look for a combination of “book learning” and real-world experience.

If you are planning on getting an MBA just to learn about product management, I would reconsider. You are likely to learn more and progress farther in your career by joining a company with a strong product management practice and learning from those with experience. An MBA is a good degree to have, and the skills you learn as part of the program — finance, strategy, organizational behavior, general management — will serve you well in many roles, including as a product manager. However, know that less than half of product managers have some sort of masters degree, and many of those may be in fields like engineering. (Though it may boost your earning potential, I think that is more of a result self-selection due to people who choose to get a masters degree than the intrinsic value of a few extra letters after your name.)

Some day we may have a variety of MBA programs to choose from which offer product management courses and curriculums, though for now, it is still very much something people learn by doing.

I am a MBA student with an engineering background looking to pursue a career in product management. This question is about the certifications helpful to people with my profile looking to start in product management, particularly in boosting the intial career search opportunities.

Among the certifications from organizations like Pragmatic Marketing, AIPMM, 280 Group and others, what are the aspects I should look for in deciding about product management certification?

Answer from Scott Sehlhorst of Tyner Blain: I remember going to a stump-speech given by a congressional candidate in Fort Wayne, IN, about ten years ago.  After giving his pitch, he took questions from the audience. After every question, he would say “that’s a great question” and then he would say whatever he was going to say, which was not always an answer to the question. Sometimes I wonder if he meant “that’s a great question” in that it was great that someone asked a question that gave him a reason to speak.

As to the question of which certifications to go get as a product manager — that’s a great question.

When I’m interviewing a product manager candidate, I don’t care if he or she has any certifications. I care a little bit about what they know (what skills do they have), and a lot about what they will be able to learn.  Personally, I have the Pragmatic Marketing “practical product management” certification, which I believe is useful shorthand for “think strategically” and is a primer for discussion, but otherwise does not provide value. Their practical product management training is to this day the best single training class I’ve attended in any topic. I would place significant value on a product manager having the perspective that Pragmatic espouses, and being able to demonstrate their ability to apply it. Having the associated piece of paper is secondary. I’ll also add that I haven’t heard anyone I’ve ever worked with express that they “care about” certifications for product managers.

Great product managers understand their markets and customers. They can discover and value the problems and opportunities faced by the customers in those markets. They can prioritize the problems and their solutions to achieve a product strategy. They can pull that ‘big picture’ together into a vision and a roadmap. And they can communicate — both with customers and with internal stakeholders. A great product manager can lead people (note: I did not say manage, that can be useful, but is not always required) — because a product manager usually has ownership of a product, but not a team.

Are there any certifications that say “I can do all of that?” None that I know of. Can a product manager learn enough about the customers in a particular market, about the competitors in the space, and the team that will deliver success? That’s what I want to know.

Thanks again, and great question.

After starting a PM position at a new company, what do you recommend as a reasonable timeframe to develop a 3 year product plan?  60, 90, 120 days, etc.

Answer from Rob Grady of RobGrady.com: Given the broad question, I defer to the standard lawyer answer of “It Depends.” As every company, culture and product mix is somewhat different, so are the needs. With that said, a good rule of thumb to get the product plan out there sooner than later. With that said, if you can get a draft plan ready for review in 60 days, that is much better than 90 or 120.

Here are a few of the many “It depends”:

• It depends if you’re starting with an existing product and strategy. If you have a legacy product plan, it should give you a head start and it is actually more important to get product plan to validate the existing business assumptions with stakeholders
• It depends on whether you have enough market data. If you don’t have any data, you’ll need time to gather, analyze and define the product plan accordingly.
• It depends on the volatility of the business, competition and product. If your competition is putting a revision out weekly, clearly 120 days won’t work
• It depends on whether you work in a multi-product environment. If you have a multi-product or other product dependencies, you may need a longer time period to coordinate across multiple products.
• It depends on your stakeholders and executive team. If you have a sociopath in the corner office, sooner and more often is better.
• It depends on your collateral duties. If you’re playing roles in product strategy, product marketing and product support set a longer period of time to develop the plan. Set yourself up to succeed.

It is also important to note that a 3 year plan is likely to change unless your product is as static (as in toilet paper). Hope this gives you a few things to consider.

I am a Quality Assurance (QA) professional with Bachelors in Engineering and Operations, and I have a good exposure to the software industry. I am planning to switch to product management and would like to know the necessary skills I need to develop to get into this role and what would be the approach I need to follow. I would also like to know is it possible to switch from QA to product management or not. It has been my long cherished dream to get into this role.

Answer from Jeff Lash of How To Be a Good Product Manager: First, to put you and other readers at ease — I think it is possible to switch from nearly any role to product management. With the right attitude, mindset, and passion, anything is possible. Now, some roles may lend themselves better to making the switch than others. Luckily, a lot of the skills of good QA/testers are ones which product managers need to possess as well.

Before going into the specifics related to switching from QA to product managemement, I should mention that there are a number of other Questions and Answers posted here which relate to moving into product management, including:

• How can I become a product manager without any experience?
• What should I study to become a product manager?
• How can a salesperson become a product manager?

Much of the advice provided for these questions would be applicable to anyone interested in becoming a product manager, regardless of their background.

Now, for testers specifically, most QA people are extremely conscious of details. They have to, of course, because it’s their job. It’s that perfectionist quality that can be very beneficial in a product manager. Especially for technology products, the way a user interacts with the product, the different variations in how it can be used, and the details around how different functionality is implemented is extremely important. QA usually has a great ability to analyze the functionality of a product and identify problems, confusion, or ways to make improvements.

Often, product managers will be good at the high-level strategy yet fail when it comes down to the details. With QA, the opposite is more likely to be the case, since testing is all about the details and less about the overall vision. QA people looking to transition to product management need to make sure that they see the forest” and “the trees” and “the leaves,” to borrow from a popular expression.

Also, QA is usually focused on making sure a product has no defects, or at least as few as possible. As a product manager, however, you will often need to make the choice between releasing a product with a defect or delaying launch or reprioritizing to fix the defect. The natural QA instinct will likely be to fix the problem. As a product manager, you will need to analyze the severity of the defect, the likelihood of a user encountering it, the impact of the defect on the user, whether there are alternative methods the user can go through to get around the defect, and other factors in deciding the overall priority of fixing the problem. While a product manager from a different background may have no problem releasing a product with a few defects, this decision may be much more difficult for someone coming from QA.

These are generalizations and may not apply to all testers. However, anyone moving from QA to product management needs to be aware of these differences before making the switch and work hard to take the appropriate actions once becoming a product manager.

As far as how exactly to switch from QA to product management, the tactic would be similar to How can I become a product manager without any experience? It is much easier to switch from QA to product management within your current company than to try to get a PM position with a new company when you don’t have any experience with the title of Product Manager.

Try to spend as much time with the product managers within your organization and learn from them. Find people who are willing to help and ask questions as much as possible. Express your interest in moving from QA to PM and see if they have any advice — good product managers (and especially managers of product managers) are often on the lookout to recruit people from other departments.

If you are on a project without a product manager or without strong leadership, take the opportunity to step into the product manager role by volunteering to prioritize development work, refine the strategy and goals, or whatever else is needed to show people you are capiable of acting as a product manager. Use this experience as an example when interviewing within or outside your organization — you can sell your skills whether or not you officially had the title of Product Manager.

If you are looking to stay in your current industry (e.g. security software), learn as much as you can about the market and your customers. A solid understanding of customer needs and market opportunities, combined with your experience in the product development process, should make you an excellent candidate for a product management role.

I’ve been a sales manager and then director of operations for a small web based software company for about 5 years. For the last two years I have been an independent consultant for creating and implementing sales strategies and processes. Since my work has been around small companies, we never had a formal “product management” role, but I have always been intrigued by the work that is involved in bringing a product to life.

I have now decided to pursue this passion, and am currently looking for a job in product management. How can I best position myself considering my experience in sales? How can I best persuade a fellow product manager to consider me as a candidate for the job?

Answer from Adrienne Tan of brainmates: Your best tactic for persuading a Product Manager that you are interested in Product Management is talking about the customer and the needs of the customer. Sales people have the added benefit of being at the forefront of organisations and have the opportunity to interact with customers. Having a solid understanding of customers will stand you in good stead in the realm of Product Management.

One of the key roles of a Product Manager is to understand and solve customer problems, and ultimately create products that customers love. Without a clear understanding of the customer problem, the products you develop may be solutions that “miss the mark.”

It’s important to distinguish that Product Managers do not create product solutions for individual customers or individual groups of customers. Product Managers look at the aggregate view of the customer and target a particular segment, a segment that will hopefully derive a return to the business.

You will also want to highlight your work as a Director of Operations when persuading a Product Manager that you are interested in Product Management. Good processes are fundamental to delivering a product. Product Managers that create great core products without the supporting operational processes will not be successful in the market place. Customers will tend to a find a substition to avoid the frustrations of poor processes.

You may want to review your work in small companies to determine the steps you took to “bring a product to life.” You may find that you’ve acted as the Product Manager in parts or throughout the whole development process. This information demonstrates that you’ve had hands on experience as a Product Manager even if you didn’t have the formal title.

Your passion for Product Management should also be noted.

I would hire a Product Manager based on passion because Product Management methodology can be learnt and experience can be gained. Passion however is inherent!

How should a product manager balance listening to an industry analyst opinion versus that of customers? After all, analysts don’t buy the products, customers do. How much influence do analysts really have on purchase decisions? Do they actually spot trends that are for real? Or are they merely pundits who are never held accountable for what they say?

Answer from Paul Young of Product Beautiful: As with all questions, the answer is “it depends.” Analysts play an important role in many industries, but their influence on buyers and users varies widely. IT buyers may look to a Gartner, Forrester, or IDC to help them sort through a variety of confusing and overlapping solutions to their problems. In other industries, such as consumer electronics, analysts have little to no bearing on the purchase decisions of customers. So, assuming you are in a market that can make use of analysts, they can be helpful — if you know how to use them.

Dealing with analysts is like a dance. There is some give and some take, and if you’re a client of their firm (which you probably are if you’re talking to them for advice or reading their materials), you want to not only learn from them but also to influence them so that they show your company as a leader in their various publications (e.g. Gartner’s Magic Quadrant). This results in a lame back and forth where you have to be both deferential to — and challenging of — the analyst under the umbrella of “seeking their advise.”

In reality, many (not all) analysts spend the majority of their time talking to paying clients. Clients who pay for analyst services are companies like yours who are solving some problem out in the Market. Therefore, the prototypical analyst receives information that is an amalgamation of the data that you and your peers at other companies are collecting. There is some value in learning that, and you can glean some good competitive data from analysts.

The downside of the analysts’ world view is that they are more than likely NOT spending time talking to customers and figuring out what their unfulfilled needs are — they’re listening to you tell them!  Then they’re regurgitating what you and everyone else told them about the needs of the Market into a report that they charge you for. Yet you can’t not have a relationship with the analyst because then they tell your story to the world by listing you in their materials as a “laggard” or some other derogatory term, and you can’t control the message. Yes, for the most part my view of analysts is dim.

All that said, there are analysts out there who are very, very good at what they do. My belief is that the Product Manager should know how to recognize this breed of analyst and how to use them. Interview an analyst just like you’d interview a customer, and ask lots of open ended questions. I like to lead off with questions about what trends they are seeing, just to grease the skids — they all have a pat answer to this.  Then follow it up with something like “those sound like some really interesting trends — what examples of companies have you seen those things taking place at?” That will give you a good idea if they are reading from the script or have boots on the ground experience. If it’s the latter, think of the analyst as something between one of your salespeople and a customer, and interview them. Just don’t use talking to the analyst as a proxy for talking to customers yourself.

Do analysts spot trends?  My general feeling is that they may not spot them but they are really good at giving them names and making people realize that there is a trend. As far as accountability, analysts are just like all of us, and are judged on results. Take any prediction of the future with a grain of salt, but someone making wild, baseless predictions will more than likely not last. If nothing else analysts will at least ground their predictions in probabilities, research, and data.  Best of luck!

Do you have suggestions for “best practice” product roadmap tools or literature for technology organizations attempting to develop product road maps with a business focus?

Answer from Ivan Chalif of The Productologist: Whether you are planning a business- or consumer-focused product, the product roadmap process is basically the same–plotting features and/or releases on a timeline. Product Management tools that help PM’s collect, analyze, and prioritize features (Accept, Accompa, FeaturePlan, FocalPoint, and others) can be very useful and they usually provide a way to produce a product roadmap document, either as an export or in a report view. While tools like these are designed specifically to make it easier to create/manage products, I have found that the tools which you already use on a daily basis, like Microsoft’s Office suite (or whatever word processing/spreadsheet/presentation software you use) work just fine for creating product roadmaps, too.

Product roadmaps typically serve two purposes. First, the roadmap is a tool for the Product Manager or Product Management team to use to map out the product strategy over the course of the next few months or years. The roadmap keeps everyone on the same page and provides a wide-angle view of both features/defect fixes and the release schedule.

The product roadmap can also be used as a mechanism for communicating the product strategy or release schedule (more on the difference between those two later) to other business functions or even customers and prospects. There are many opportunities to share the product roadmap with folks inside and outside of the company and providing a glimpse into the strategy and/or schedule can help guide discussions about hiring, resource planning, and strategic alliances.

Let’s look at the second use first. When communicating with other departments, the executive team, or external folks, it’s important to keep the message simple and accessible. That means high-level information in a format that everyone can read. For this type of communication, the information should be the focus. That’s why I prefer to create product roadmaps for communication purposes in PowerPoint. Most times, I am discussing the roadmap with folks who don’t care about the nitty-gritty details of enhancements or bug fixes. They want to know what to expect from the product within the next 1-3 years. What is the strategy? Where is the product headed? PowerPoint provides an easy way to create timelines that highlight where releases fall or what the theme of each release will be.

Using a tool like PowerPoint also provides a lot of flexibility in how the data is presented. I frequently have to modify the roadmap to accommodate the interests or knowledge level of the audience I am presenting to. PowerPoint lets me easily modify both the format and data presented (switching from release themes to release dates is a good example of how you can quickly create different views of the roadmap). At StrongMail, we use product roadmaps created in PowerPoint to share product strategy with customers, prospects, and internal team members.

A product roadmap doesn’t have to be graphical, though. You can just as easily make the roadmap text-based using either Word or Excel (or as I mentioned earlier, similar applications in other office suites). Using a text-based format makes the data even more transformable because it can so easily be moved between mediums and is just easier to work with by its simplistic nature.

Now, let’s revisit the first use of product roadmaps. At MediaPlex, I created a product roadmap in Excel because it made prioritization of upcoming features easier. The roadmap was much more of a scheduling tool for Engineering, so it made sense to have the specific enhancements and defect fixes listed out in detail. Once they were prioritized, I just cut/copy/pasted them into the MRD template, added some additional details and voila, release planned!

When I was working at Digital Impact (now Acxiom Digital), we used a combination of PowerPoint and Excel to manage the roadmap. PowerPoint was used to plan the long-term strategy and release calendar while the focus and details of each product release were tracked in Excel. While this method lets you track and communicate a wider range of data, I don’t recommend it. It requires that you keep two separate documents in sync and sometimes one shows up without the other, and because the data in one document relies on the data in the other document, it can be a bit cumbersome having to switch back and forth between them, both when editing and presenting.

Lastly, here’s a note about communicating product strategy versus the product release schedule. Roadmaps can be used to share information with internal teams, external constituents or as a planning tool for the Product Management team, but whichever you choose, you have to figure out whether you are going to make the focus of the roadmap strategy or release calendar. If it is strategy, your timeline can be vague — quarters or years. If it’s release calendar, the near-term has to be pretty specific: exact date or month, but the future can be more nebulous.

Having said all of that, the choice about how to manage your product roadmap and what tool(s) you use to do that depends a lot on your Product team and the audience for the roadmap. Is your audience going to respond better to high-level data, such as release versions and dates or are they looking for granular details, like which exact features and fixes will be in a particular release?

You also need to consider how frequently you plan to update the roadmap. The more detail and complexity you add to the roadmap, the more difficult and time-consuming it will be to update. This is fine if you are only planning to modify the roadmap a few times a year, but if you are at a start-up and/or your product is in a fluid state, you will want to keep it relatively simple so that making changes doesn’t take as long (or longer) as the actual implementation.

And as a final consideration, determine whether you plan to have the roadmap stand on its own or if it needs to be accompanied by additional details and voice-over. Several companies — splunk, Borland, and even Microsoft — have started displaying their product roadmaps to the public by making it available on their websites. This level of disclosure requires that your roadmap be able to be understood even when you aren’t there to explain it.

Figuring out how you are going to use the roadmap is the first step to identifying which format and tools will best suit your needs. There is no right or wrong way and what you choose now may not be what you need in the future, so don’t get hung up on it too much. Think about it like your product. Evaluate the market need(s) and then create a solution that addresses those needs.

For more on Product Roadmaps, check out my blog post from August 2007: Building a Working Roadmap.

I believe that customer would be more inclined to join a field beta if they knew as much as possible about the beta program. Therefore I would like to provide them with a road map / time line of the beta deliverables much like a project plan. Does that make sense? If it does, does anybody have generic sample project plan or time line showing milestones that they can share? Given that this is my first venture into this, I know I don’t have a complete picture of the milestones.

Answer from Brian Lawley of The 280 Group: There is an overall beta time line available at www.280group.com/beta.pdf (PDF) - it is part of our beta program toolkit.

In my opinion, it is critical that you communicate expectations to them in the invitation to join the beta program, the beta program agreement and ongoing as the program is running. You need to let them know what (and when) you expect of them and what the rewards/incentives are for participating.

I also have a chapter on beta programs in my book Expert Product Management (available from Amazon or also as an ebook) that might help.

We are hiring a new product manager. What would be some realistic goals to expect for the first 30, 60, and 90 days for this person? The candidate is new to this industry but has prior product management experience.

Answer from Michael Hopkin of Lead on Purpose: First of all, congratulations on hiring a new product manager! When a company invests in building out its product management / marketing team, it will reap the rewards.

We all know the first 30 days at a new company are filled with paperwork and discovery. Bigger companies usually have some form of a new employee orientation plan that helps the person get up to speed. A few realistic goals for a new PM in her or his first 30 days might include the following:

• Know the ins and outs of HR: Get the benefits paperwork filled out, signed and out of your hair.
• Know the IT guys: There will no doubt be hiccups in getting your equipment configured, applications installed and understanding how to navigate the company Intranet.
• Know your team: Meet all the members of the teams you will be working with, know their names and give them a chance to know you. Spend time with them. Don’t worry about knowing everything about what they do, but get to know the people. People are assets.

These goals might be better assigned to the hiring manager. The manager can help the new PM get a good start by getting him or her get plugged in to the company.

Within 60 days the new PM will have had enough time to get comfortable with the company and understand where she or he fits in. The second 30 days will be valuable for getting up to speed on the product and the new industry. Relevant goals for this period include:

• Know the industry: Spend at least ten hours a week reading and understanding the industry. Google Alerts work great for this. Charge the new PM with sending out information to the team. This will not only force the new PM to know the industry but will also make him or her accountable to the team.
• Know the products: This goes without saying, but the PM must know the products he or she owns. In my current company we have created an exam that tests the employees on their knowledge of the products. The employees have MBOs on how quickly they need to pass the test and by what percentage they must pass it. Some have merit increases tied to their scores.
• Get appropriate training: The new PM needs to receive training on the company and the products. If the PM has not received specific training in product management, I highly recommend it. When I started a new job five years ago I spent the first three days at a Pragmatic Marketing training seminar. To this day I can still identify things which I learned in that training which have helped my career.

When considering setting 90-day goals, you may want to consider more long-term goals. Not too changes between 60 and 90 days, but a lot happens (or should happen) within the first six months and the first year. I recommend you set six-month and one-year goals (or MBOs). Jeff Lash wrote an excellent post answering a similar questions about goals for product managers. He said:

I think product managers should have a small set of appropriate metrics that align with the larger company goals. If your company is small and growing, you may want to focus on revenue growth and customer adoption. If you are large and in a very competitive market, measuring profitability and margins may be more appropriate.

He goes on to list four baseline goals which I recommend for your review.

Hiring a new product manager is an important step in the growth and success of a company. Hiring the right person is critical. Helping him or her get off on the right foot is critical. Spend time setting sound goals and objectives that will help him or her quickly start to add value to the company. It will benefit you as the hiring manager as well as the new PM.

I’ve been in a Product Management role for about 7 months. I’ve been tasked to determine whether it makes sense to expand a US-based product internationally. The problem is that I’m always feeling like I need to do deeper analysis when folks around me tell me that deeper analysis isn’t needed. I’m told that all I need to do is a quick back of the envelope to determine if it’s even worth it to conduct that deeper analysis. Biz school teaches the deeper analysis: Porter’s 5 forces, SWOT, etc. But quick evaluations aren’t covered.

I’d appreciate any tips and tricks you might have.

Answer from Derek Britton of Micro Focus: “Going global”, or at least beyond your home territory, raises some interesting questions about your product, your market and your organization. There are some important considerations concerning language, geographic market forces, cultural aspects, competition in each of these categories that may affect what conclusions you may draw from a quick-fire assessment of the possibilities. You are right that 5 forces, SWOT et al. are hugely helpful here, but you can get a lot of good material down just by being fairly simplistic.

Before we jump in, I would also add that while it feels somehow ‘wrong’ to made such snap judgments, actually this process is extremely liberating, is seen as an effective management tool (read Malcolm Gladwell’s “Blink: The Power of Thinking Without Thinking“ for inspiration) by many, and supports the accepted mantra for the Product Manager, which is to live life outside of your comfort zone. Yours and your colleagues collective experience may add up to considerably more expertise than you may realise. And the good news is your company appears to be empowering you to do just that!

• Your product. Considerations regarding going global on a product include the following but are certainly not limited to this list:
  • Documentation — Clearly you want to consider providing product packaging, documentation, installation and help manuals in whatever the target language may be. Some regions will insist on local language documentation (e.g. Japan, France), whereas it is less important elsewhere (Nordic regions for example may accept English language).
  • Codepage — Does your product (assuming its software here) support the relevant “code page” (which handles keyboard and screen input of local language) for the region(s)? If not, this is an engineering/testing effort.
  • Character Sets — In the western world your (software product) can work for all codepages and characters the region may need. In Asia, especially Arabic, Japanese, Chinese, Korean, the support needs to be multi-byte character sets (MBCS), which might need your software to be re-engineered to handle this. This is called “Internationalisation” and is a significant engineering effort, and would need ROI justification accordingly.
  • Cultural / Geo issues — If there is an incumbent competitor or “best practice” in a given target region, you need to factor into your plans whether you need to step up to providing some level of compatibility. This could be a big ticket item once again. If a Geo has a bias towards certain environments, product shapes, even pricing models (US pricing might be considered extremely high compared with, say, Latin America or Asia), you need to get inside the norm for the region and play out a few scenarios to test the business case.
• Your market. It is very easy to think that the global market is just the same opportunity just divided by the number of possible clients per region. Not so. IBM dominates the high-end server market globally, but only has a modest share in Japan, where local boys NEC, Hitachi, Fujitsu are equally successful. Similar services organizations have a few global big guys but a lot of local niches. The same will be true for your market, which will be affected in ways that were perhaps hitherto unknown. It is hard to be too specific without knowing the product and the market in question but certainly if you were to list the top 10 characteristics of a market on a region-by-region basis, you will find notable differences that will affect how you take your product there. Culturally, remember US companies may not fare as well in certain regions simply because of the background, and a reputable local distributor/reseller might be a more appropriate route in, to help soften that blow. But then the margins on each sale drop dramatically, affecting your ROI.
• Your company. The size of the company, its existing (global) market reputation, and the aspirations of its board, and its shareholders, without sounding too dramatic, may affect any decision about a foreign go to market plan. Natural beach-heads to test the water are probably obvious (a US product would naturally find a strong candidate market in the UK and Australia, for example; whereas a strong Hispanic market would lend itself then for a foray towards Latin America). The big question then is how is the company disposed to setting up sales offices, or negotiating with resellers, or making what must be considered a relatively speculative investment on such ventures?

If you had a paragraph for each issue, for each region, in no time you have at least highlighted some primary considerations, and pinpointed any significant knowledge gaps that might need filling. Using that as your basis, this is at least the right model for an initial discussion. Add any caveats to allow for change and refinement, and your company seniors will applaud the speed of response and professionalism.

I believe there are a range of responses — everything from trying to keep them out of previewing what you’re working on, surveying about, communicating to beta participants, intentionally feeding them misinformation, etc. What is ethical and what factors can help you decide how much energy/time to spend worrying or tracking this?

Answer from Brian Lawley of The 280 Group: The best way to protect against competitors using your beta information is to include strong a NDA and non-compete/non-use of information clause in the license agreement that beta participants must agree to in order to participate. Make sure this includes direct competitors as well as anyone who provides this information to anyone not under NDA. Then, when you send out your first batch of communications, make sure one of the first bullet points is: “Please remember that under the terms of the license agreement you may not share any information about this product or use it in any way to create a competitive product. If you do you will be liable for significant financial consequences.”

If this won’t stop your competitors then nothing will. And if you find out that they are using it, have your lawyers shut them down.

As an FYI — I was once at a large company where a competitor released a major beta release. Some of the people inside the company got hold of the beta and ignored the terms of the agreement. Within a day they were fired and the company was extremely worried about its ability to compete in the future. Don’t take a chance — it isn’t worth it.

Answer from Roger Cauvin: You can leverage the vocal minority to your benefit, so don’t ignore it. Since the vocal minority is vocal, they can be a powerful part of a positive outbound marketing campaign if you address their needs and give them a ‘megaphone’.

First, employ facilitation to gain an understanding of the ‘whys’ behind the feature requests. A product manager’s job is not to tally requests for features, but to determine the underlying problems that are most compelling to solve.

Second, find the ‘win-win’ commonalities among the problems that the vocal minority faces and those that the mainstream audience faces. The feature requests may not match, but the audiences may share underlying problems. In many cases, these problems bubble up to the top of the priority list.

Finally, assess the problems relative to your product’s positioning. To the extent possible, the problems your products solves, and the features it includes, should support and strengthen the main idea that you would like it to represent in the mind of the customer. In general, you should reject any features that undermine your product’s positioning.

Are there any general rules for when to move to a major (.0 release)? My experience has been that if there is a major functionality change or a new interface or product overhaul, it is good to move to a “.0″ release. Customers plan differently for a major release ,and if we slip a 3.4 release in on them when it is a major change, they will be frustrated, so calling it a 4.0 would be better.

Plus, there is the entire marketing side of things. Can you offer some advice or point me to somewhere to read up on this? Specifically, we just came out with 3.0 of my product back in January — and have released 3.1, and soon 3.2 — and we are overhauling the interface in Q3. I really want to call it 4.0. What do you think?

Answer from Nick Coster of brainmates: I would suggest not to get tangled up on a product’s version number when communicating it to the market. These are useful for support and software development versioning control. In isolation, however, they are irrelevant to a customer.

What is relevant to a customer is what new problems can be solved with the updated product. You can see a trend developing with many software providers like Symantec, Microsoft and Apple who use dates (2003, 2007) as the version number — or, in Apple’s case, types of big cats (leopard, tiger, etc). This breaks away from the successive versioning and the hassle of tracking point releases of software in the product name.

For a new and significant release you should be looking for one or two key new customer benefits that will differentiate the product from other offerings. If your case, ask yourself: “Does the interface improvement solve any new customer problems?” This should not include problems introduced by the previous interface.

For existing customers, what is the benefit of updating their software from a previous version — stability, simplicity or a new solution? Whatever it is will have to outweigh the customers cost of performing an upgrade.

Consider a version re-name or re-number when you are adding significantly more value to the customers. This is when you will have a product change that is worth talking about. Make it count.

I am looking for a product management job. What should I look for when searching for a product manager position?

Answer from Gopal Shenoy of Product Management Tips: First of all, you need to decide on what kind of product management job you would enjoy.

1. What size company do you want to work for — large, medium, small, startup?
2. What kind of work culture do you thrive in — startup chaos or established process culture of established companies?
3. What kind of products — B2B vs B2C, enterprise vs SMB, on-premise vs. on-demand (Saas) etc. ?
4. What industry? Don’t assume that you will be restricted by the domain you are currently in — your skills could be portable to other domains.
5. Where in the life cycle should the products be? Brand new concepts, products with initial traction, well established products, etc.

Once you honestly determine the answers for the above, then find out where you stand in having the skill sets for the product manager, and then go looking for your dream job. I have recently written about assessing a product manager’s skill set and also on job hunting tips based on my recent job searches. The links are given below:

State of you
Ten Job hunting tips for a product manager
Job hunting cheat sheet

One thing I would like to emphasize is that the size of the company in (1); not only does this dictate the company culture, but also dictates what kind of benefits you could get. Believe me, health care benefit costs now constitute probably the largest chunk that eats into your take home money. I personally have had to turn down offers because of this factor.

My question is specific to products used by almost everyone in the world — products like Windows, MS-Word, Adobe Reader. For such products, how does product manager decide for the next release of such products?

Notice that these products are already at a level that almost everyone using it is more-or-less satisfied with them. For example: Having released Microsoft Office 2003, how would the product manager decide that we need Microsoft Office 2007?

Answer from Nick Coster of brainmates: This is a problem that faces the product manager of any product that has matured, become a commodity, or both. For these types of products it can be tempting to keep looking for new features to keep adding to the original product. From the product manager’s perspective this keeps you employed — right? Well… no, not if customers start to look for simplification or the product becomes over engineered and cumbersome.

As the product manager, the first step to take is to make sure that you understand your customer. Define who you think them to be. Segment the markets that you are serving in to smaller groups that have similar behavioural requirements. Even for these mass market products there will be groups that use them differently. Do lawyers use Word in a way that is different than students? What are those differences in their goals?

Now look for the specific needs of each of these groups? Are they being met by your product? Are there any areas that your customers have to find other solutions to use before they can reach their goals? These may be the features that you are looking for.

Alternatively, do the customers know how to use all of the features that are available already? Are there features that are never used? Your next release may either make these more accessible or remove them altogether.

Word’s upgrade cycle has never really delivered any significant feature enhancements for my use. The tool bars have changed over time, but beyond the core text formatting capability and spell check, the rest of the upgrade has been unnecessary. This hasn’t stopped me from making the changes over time. Microsoft introduces compatibility issues in older versions by releasing new versions. Usually just enough customers also tend to have a need to use the latest version. Combining these together can create a demand for a software product, although it is more likely to frustrate customers than delight them.

Finally, if your product is mature, everyone likes it, and it does everything that your customers want and is preferred to the competition — then LEAVE IT ALONE. You don’t have to keep making changes for the sake of change. Instead, look for a new market where it can solve new customer problems.

I have recently been asked to manage an enterprise software application utilized by our IT organization. The application is not our product. Multiple and often competing stakeholders have an interest — they are my market.

We purchased the application and licenses, and then we customize the application to meet our needs. There are quarterly releases from the vendor with enhanced functionality, bug fixes, etc.

I will be the only “manager” of the product and am really also a stakeholder. There will be no other managers — I am responsible for managing the product to meet stakeholder needs, including my own.

I have a Project Management background and am familiar with the product and our stakeholders from both my Project Management role and my developer role. The application is highly customizable so my role will involve managing the customer needs/configuration releases, standards, etc.

My gut tells me the role of Product Manager will be different that my usual Project Manager approach. Would formal Product Management role and methodology be suggested as an effective approach? I don’t want my approach to entail much organizational change but am looking for some key guideposts, etc.

Answer from Bob Corrigan of ack/nak: When I read this job description, here’s how it sounded to me:

“Hi, Bob, we’d like to talk to you about a product management position.”

“Terrific. Tell me about the problem the product solves in the marketplace.”

“Well, that’s a problem, because the product isn’t something we ship to customers. It’s an internal tool we license and use that helps us create the solutions we bring to market.”

“So who are my customers?”

“Our IT department. Oh, and you too, since you’d be living in IT.”

“So I’m not just the manager, I’m a user?”

“Yes.”

“Interesting. So why do you think you need a product manager?

“Because we need to balance the needs of multiple and often competing stakeholders who have an interest in what the product does.”

“And. . . as a user. . . my needs would be competing with theirs?”

“Correct.”

“Who does the development of new capabilities?”

“The vendor does.”

“And they’re balancing the needs of multiple and often competing stakeholders who have an interest in what the product does too, specifically all of their customers.”

“I guess that’s right.”

“So I can’t have any confidence that specific feature enhancements or bug fixes that our company needs will be addressed by the vendor.”

“Well, we do pay maintenance.”

“That doesn’t generally give you the ability to prioritize or force features or fixes.”

“But they’ve been very responsive.”

“I’m sure they have. So let me ask this - when you say that the job needs to balance multiple and often competing stakeholders who have an interest in the product, that refers to how the product is configured for use, and the sequence of how those configurations are integrated into the product, right?”

“That and more.”

“Would the ‘more’ include planning, definition, analysis, design, development, quality control, release, utilization and maintenance of the product?”

“Why yes, that’s a nice way of putting it.”

“OK, here’s what I’m thinking. This is a great job for an experienced IT project manager who would like to learn to be a product manager, because it requires a lot of the techniques and skills associated with being a product manager. Understanding the needs of a target market, prioritizing how you serve that market, those are PM disciplines. But the logistics of managing all of the various phases of how the application is customized. . . that’s a project management job.”

“So what do you recommend?”

“Find an experienced IT person in your company who knows the application, is a tested project manager, and introduce that person to the idea that they will be the product manager of this tool. Treat it like a product that would go to market - look for the biggest return for time invested, find out how each incremental release will align with the strategic direction of the company.”

“I think we have someone like that in mind.”

“I don’t think you need a full formal PM process - just a mindset that this person is the repository of the voice of the customer, and that this person is going to be more than someone who owns the project plan. Just be careful to imbue the role with authority, so that all of the people whose interests this person needs to balance know that he or she is the ‘owner’ of the application. It’s that sense of ownership that makes someone a PM.”

“So why don’t you want the job?”

“Because the product itself is not market-facing, and because the company can’t control the resources who work on the product beyond configuring it for internal use. To a PM, those are two big strikes.”

“But you think that taking a PM approach towards managing it internally is a good idea?”

“It’s a great idea - but only if you staff it with someone who is also a capable project manager with an IT perspective on how the product will be used internally.”