Choose the Right Tools for your Product Management Process with Peter Ganza

FULL WEBINAR TRANSCRIPT:

Peter Ganza: Thanks everybody for attending today's session around best practices in product management tools.

It's going to be an interesting session. I'm going to talk about a few different things here. Let's start off with a brief introduction, and talk a little bit about what we're seeing in terms of trends in the PM community and the tools they use, and the best practices or lack thereof, of using these various tools that they are dealing with on a day to day basis.

We'll talk a little about that - about what we see in that space in the community - some of the best practices we've gleaned from working with these various systems and the various groups that we have to collaborate with.

Then we'll finish off with a couple of carrots to leave you with around some of the growth opportunities we've seen for product management, and what life after product management may potentially look like.

To kick off, what does product management look like today. We are, of course, the center of the world in any given organization. We're the one group that everyone is screaming at, looking for answers from and trying to be involved in our process.

This slide gives us a simple view of the day to day life of a product manager. If we look at the top layer, these are the different tools or groups within the organization that we tend to have to work with in some fashion. In most cases they are automated in some way. We'll talk about those different groups.

So we get the different pieces of the puzzle; things like CRM tools that Sales is using - which may interface for perhaps win/loss data or customer information. Everyone's personal favorite - having our enhancements and our bugs flowing in from our customers and constituents in some fashion. It could be through emails; in most cases we've got something on line via the web - some kind of a web data base to store this information.

We're getting lots of information from the field. This could be people in sales, services representatives or people in support screaming at us in one way or another. We can't forget about research - depending on the organization, some of us live and die by market or analyst research. I can remember many times in my past loving the gardener magic quadrants and using those on a day to day basis. We can't forget about the research entity.

Last but not least are our developers and our QA. We have to work very closely with those two groups. There are a variety of tools, methodology, and process behind that segment in the organization, and we have to interface with them very, very closely.

All these things are streaming into us as product managers and as you can see by the funny little icon, we end up being very, very tired and having a few too many bottles of bourbon in our desk at the office.

We have to output out of that process, something. In most cases, there's a variety of documents or reports; you can see a few examples here - things like MRDs, PRDs, contractual or business case documents and everyone's favorite, the roadmap.

So we have a lot of people screaming at us, a lot of things we have to use, and a lot of things we have to develop out of this process.

Let's drive a little bit into the different areas and see some of the things we're going to find.

The first place is probably the simplest; CRM tools. More or less everybody has a CRM tool in some fashion or other. I've listed a couple of the common ones we seem to run across here such as Salesforce.com, Oracle, Siebel, and some others. This is one of the most traditional tools we find in any given organization, and of course one that's being used most often by Sales.

But as product managers, we often try to get a very valuable piece of data from Sales in the form of win/loss data. It's an interesting problem we're seeing in the industry because on one hand, the tools are there; everyone has a Salesforce, everyone has an Oracle, everyone has a Siebel or something. In most cases there is some win/loss data there but there are a couple problems we run into.

The first problem we run into is we have difficulty getting the information. We often don't have ownership of that tool. In most cases most PMs don't' have access to the Siebel or the Salesforce or whatever CRM tool is being used.

We have to get that information from someone. We have to request it; send out emails; get approvals to get a client or just a dump of the data base. So the first problem we have, is just getting to the data.

The second problem which is the bigger problem in this industry, is the data itself. I can remember a great project that I was involved with many years ago at Symantec, specifically around win/loss where my director had asked me to do a win/loss analysis; go through the last two quarters only for our products. Come back to me with a couple of slides, number 1, 2 and 3 reasons why we won, why we lost.

I spent about four, five weeks just getting the data. I had to find the right person in California to get the data because of course I don't have access to it. I have to spend quite a bit of time plowing through a 30,000 line Excel dump spreadsheet, which in itself is an exercise and frankly a job in its own right.

At the end of that process, I ended up with a slide that was useless because the data was useless. In the case of that project I was dealing with, all the loss records had the same thing. We lost because of account management. Or we lost because of pricing.

What had happened, was the sales people are smart. They are going to do the quickest thing that they can to get onto the next sale. In this case, they were simply picking the first option in the pull down for why we lost.

Account management and price were the first two options. Those are the problems we are seeing today; one is getting the data and two, is getting valuable data. The win/loss data is useless to us unless there is some real information in there.

We're not losing because of price. We're not losing because of account management. That just tells us we didn't do a good job selling. Perhaps we didn't do a good job in demonstrating our value or it might be as simple as the understanding of the need.

If we really don't understand the customers' problems and what the customers' needs are, we're going to have a very difficult time in convincing them to go ahead with the purchase of our solution, our products, or the suites that we actually may be offering.

Those are the two things we see. One of the easiest ways I've found to get around that is to work with sales management. We need to have sales management on board with us; have a good relationship with management. They need to understand how important it is for us to get win/loss data that's valuable. They need to understand it's not a bad thing for us to lose or for their sales people to lose, and more importantly, for us to find out how that happened so we can make changes.

We can make improvements in our products, we can make improvements in our processes, our materials; they way we approach the market, to avoid losing the deal in the future.

Great data if we can get it and if the data is valuable. If we're having problems there, again, best place to go is sales management; let's forge that relationship; let's drive down to sales the importance of that information and let's get it, get access to it, and start to use it.

The next section we see is enhancements and bug tools. Pretty much everybody has one of these tools, whether it's a simple web data base -- it could be an open source tool. Bugzilla is probably the most frequently seen one that we come across here at Ryma. A good deal of our customers are using Bugzilla.

We are seeing a couple of issues here. First and foremost, we don't tend to see a good solution that covers both enhancements and bugs. There's a lot of tools for enhancements and a lot of tools for bugs; specifically Bugzilla, we'll use as an example.

We're fine if people have to by necessity pigeon-hole their Bugzilla systems or other bug tracking tools towards enhancement requests. The two are very different.

When we're talking about enhancements, we're talking about requests from current customers who have purchased our products to improve the product; make it better for the next version, for the next year, or for the next product.

Whereas a bug is something critical. The bug is saying I can't do what I want to do with your product or it's not working as designed.

We're going to look at the two very differently, and we're going to push them down very different paths.

Of course a bug is going to be pretty high priority depending on the issue and it's going to go through a development cycle, a QA cycle, or some sort of analysis to understand how critical is the bug -- how is it affecting us and what do we need to do about it. Whereas the enhancements tend to go into this larger catch-all bucket; things people want us to do and eventually at some point we're going to get into that list, go through it and analyze it in some way, and potentially include some of those enhancements either as features in a new release - potentially changes to our product and how they work - or even in a brand new offering, depending on the enhancements themselves.

Again, the problems here are similar to the CRM problem that we saw earlier, in the sense that one, we have sometimes difficulty in getting the data. In almost all cases, product management does not own the bug system; does not own the enhancement request system whatsoever. It's generally under QA, Dev, potentially IT or some other flavor of the organization.

We have problems getting the data in a valuable way; getting access to the tool or getting hooked up with the data. The biggest problem that we find here is that the data is not valuable.

If we are classifying bugs and enhancements as the same thing, we're starting to blur the lines. That's very difficult for us to tell well, what's really an enhancement - what's really a bug - or is this a feature - or frankly, is this working as designed and we don't need to do anything about it.

We need to get access to the tool; we need to start using the tools correctly. The tools are there. Everyone has one of these tools. We need to start using them better. There's a host of different tools available for you in those rights - lots of free stuff - can't recommend Bugzilla - I'm not for the instant side of the house.

Next, let's talk about research; I mentioned a little bit about market and analyst research. This depends on how you are running your business. Some companies live and die by the Gartner metric quadrants; the IDC data; looking at NPD and what we're selling through - some people don't.

It's an important piece of your solution or what you are offering; if your customers are using analysts or different types of market research to evaluate tools, evaluate solutions, then it is going to be important for you and you're going to need to latch onto that band wagon in the sense that we need to have the information to see what's the market saying, what are the analysts saying specifically, so we can tie in our offerings around that speak and make sure that whatever the analysts are recommending is going to speak favorably to our offering.

In terms of tools here, there's very little out there today. The number one tool that we've seen here at Ryma is really around Microsoft's offering specifically Sharepoint, just as a place to store the information in our organization; have some web links in some different folders so we can get to the Gartner Report, the IDC Report or the Forester entry that may be in the system.

Generally something we don't own as product management - there's a whole other side of the organization that will deal with markets and analysts. We like to deal with them and often times are called upon to talk to analysts and help with that relationship, but generally don't own market or analysts research.

So we need to pull that group in if it's valuable for us; get the information in some way and have it somewhere available to us. So again, when we're building out our solutions, building out our products, making our plans; that we can keep the analysts and market research in mind as one of the variables we're going to use to make our decisions.

Just a little bit on the research side.

Next we'll talk a little bit about development and QA. This is definitely the most mature space in the market from what we've seen. There's a lot of tools out there that have been out for a very long time. I've given you a few examples here of some of the larger development tools that we see; a lot of offerings from the IBM side of the house and Rational products. A few others like Borland, Mercury and MKS - there are also a variety of other ones out there -- a lot of good tools in this space. All of these tools are great for what they do. They are great for development in understanding what it is they are doing day to day; what piece of the source are we touching; what DLL are we dealing with; what certifications do we have to be aware of; how is our test cycle going to work and our documentation - very low level tools - lots of task tracking, project management, really day to day low level development and QA information.

Great for development; great for QA; definitely tools that we need to have in the organization but not the most valuable tool for product management. They are not tools that are geared for product managers to understand market needs, competitive pushes and threats that are in the industry.

They are a great tool for us to build requirements once we have them. They are just not the greatest place for product managers to plan out what we are doing. With that said, we definitely need to interface with these tools and in most cases, with development in some way, to help them work through the requirements.

We may need to give them the requirements. We may need to implement them into these tools. Or we may need to just work through these systems with development in various phases, stages, reviews and cycles, as we are actually building these things.

In terms of problems that we see today? The biggest problem we see is these are not PM oriented tools. They are generally very difficult to work with; they are very techy, very tree-viewed; very few buttons; very light on a user interface but great for development.

It's generally not a good place for PMs to spend too much time. But we do want to make sure that Development is using the tools in a way that's going to be valuable for everyone including ourselves. That really means defining the tool we're going to use, having the processes built in, and making sure that everyone is on the same page. So that when we check in a requirement or check out a requirement or make a change, there's a process that Development can follow, and at any time we can get a good understanding either ourselves or through a constituent to see where things are, what has changed; what impacts are actually coming down the line.

A little bit on Dev tools.

Last but not least, we have a new space coming now, which is PM tools: tools that are specifically built for product managers. This is a fairly new niche in the space around product or application in life cycle management. There are a very few amount of players in this space. Of course Ryma is one of them with our FeaturePlan offering.

I listed a couple of others here in the list, in terms of some companies that are starting to speak our language. A lot of the development tools are trying to go this way. They are realizing the need to work with product management. They see how critical it is and that we are the source, in most cases, for what is going to go into that Dev tool so it just makes sense to try and pull them in.

The Dev tools aren't there yet. They're just starting to speak the language and just testing the market to see if there is a need there, and if frankly there's some money to be made there. But they're just not there yet.

There are a couple of small companies like ourselves that are out there, really trying to build a PM tool for product managers and solve that problem.

With that said, let's talk a little bit about PM tools, and potentially why we would want to use one, and what some of the benefits and pitfalls of that may be.

First and foremost, why would we want to use a PM tool. Outside of being on information overload and needing just one place to put our information, and being able to track it, there are a variety of corporate reasons that may be pushing us to invest in some kind of a PM tool.

The first is strategy. A lot of organizations now are starting to gear away from being development or sales-driven, and understand the need to be market-driven; to actually listen to the market, to our customers and our constituents, and build solutions for real problems.

The idea is if we solve someone's problem and we solve it well, they're going to buy our solution because we're solving the problem that they need. If there is a strategy to become market-driven, if the executives, the executive management are starting to speak that language, that's a good reason to start thinking about going into a tool because it's going to help us to do that.

We can start to weigh the market needs and the market problems against our strategies, against our criteria internally, like how many developers we have and how much money we have - and really start to develop plans, products and solutions that are focusing on the market.

Regulatory compliance is the next one I have on the list here. This is enormous, and it's becoming more and more important as the days go by. A lot of different regulatory compliance issues around there, depending on your business. Before we're dealing with health care in any sense of the word, we may be dealing with HIPPA on a day to day basis, and have some very stringent needs for the way we store information or being able to come back to auditors in these regulatory compliance cases and prove how something happened.

We received the enhancement from Customer A on this day and this is the cycle that it went through. There's dates and times and stamps and we have to be very compliant with these regulations.

There's a ton of other ones out there - Sarbanes Oxley -- SOX, otherwise known as, Gramlisch Bailey and a few others -- a lot of things that are focusing on information, integrity, information security and frankly just having the information. Prove to me why you built this. Prove to me why you've changed this. We need to see the flow of that; we need to see the life cycle of when things came in, where they went and what the decisions actually were.

So if you're being driven by regulatory compliance at all, it may be a good reason to invest in a tool because we can make sure we're always keeping that regulatory compliance in mind. As we're building whatever we're building, every single requirement, we're always keeping in mind that we have to build it around SOX or we have to keep HIPPA in mind, or whatever regulatory compliance we may have to deal with.

Those are some higher level reasons from an executive perspective, or from a market regulation perspective. Outside of that, there are a lot of good reasons internally that we would want to invest in a tool.

I use two big words here; justification and visibility because those for me speak very well to the need that I've been seeing at the 50 or so customers I've visited in the last year or so.

The first is justification. We find a lot of companies have difficulty justifying internally their decisions. If you are sitting there nodding your head, remembering the meeting last week where the development manager asked you why do we have to build this - that's the justification. We need the data. A lot of times we need to be able to go back to constituents internally such as let's say development management, and give them justification.

Tell them that 42 customers have asked for this feature and we've lost $42,000 because we don't have it. We need to justify our decisions and without having a tool in place, it can be very difficult and time consuming to do.

We need to go through emails and documents. We have to log into a variety of different tools perhaps to find the data, like our CRM tool and others. It's a time consuming and very difficult thing to do that we just can't do off hand at a whim and give them the information.

This is one of the places where a tool can help us. We have a tool; we've got all the information in there - why we made our decisions - and at any time, perhaps even in that meeting, we can literally get into the tool and say here you go. This is why we need to build this or frankly, this is why we don't need to build this.
Maybe it's the decision that we decided not to do something and we need to justify that. Great reason for having the tool.

Visibility. Similar to the justification in the sense that we need to see this information and not in five or six different places. We need to see all the data amalgamated into one place so that not only we can make our decisions, but we can have the conversation internally and start to hash out what we are going to build.

Product management is very unique in the sense that we generally don't have actual deciding authority over very much. We're sort of the middle man or middle woman and what we have is influence.

We have to influence people to do the things we want them to do. We have to convince people that yes; we need to build this new product because of this and this, and that. We can't necessarily make the decisions. Again, like I said, it's because we don't have, generally, that power but we have the influence.

Without the data in front of us, available to us in all fashions, it can be very difficult to get that visibility, to have those discussions and frankly to make our plans.

If any of those things are hitting you in terms of things you deal with on a day to day basis, those might be good reasons to potentially look at investing in a PM tool, to give you the justification, give you the visibility you need, and potentially meet any other goals that we outlined above.

A little bit on why we would use the PM tool and the positives. In line with that, talk about some of the benefits. We've talked about justification and visibility, meeting regulatory compliance - but really, what are some of the benefits for us going to be outside of those high level things.

First and foremost is collaboration. Because we have to work with everybody in the company in most cases more than anybody else, we need a way to collaborate. As much as I love my Outlook and my Excel, they're just not good ways to collaborate on a large scale, on a global scale; dealing with multiple people in multiple offices and multiple time zones.

That's one of the biggest benefits of having a PM tool; is having a place for people to collaborate. Everyone comes into one place. We've got all the information to us; we can have our give and take, we can have our reporting, we can have our notifications and keep stakeholders up to date and we're instilling collaboration and we're empowering people to make decisions and be able to do their jobs more effectively.

We want to all turn one dollar into ten, or in my mind, from one thousand into ten thousand - but the idea is less with more. We want to be able to be more productive in our day to day jobs. Today don't think I've met a single product manager that does not work, say, 60 hours a week or less.

We are busy people. We have a ton of things to do. There's always a ridiculous amount of fire drills coming in. We need more time. Since we can't get that 28-30 hour day going, we need things to help us. That's where a tool can come into play and really benefit us by streamlining a lot of the tactical day to day almost clerical duties we have to do to get through a lot of this information.

Of course along with that is the time and the clarity. We've now got more time on our hands to make more strategic decisions; less time to waste on gathering all this data and doing very, very little tactical - and we can see and use the information and use it in our decision making, in our processes, and in all of our meetings.

Some of the good stuff - what about some of the pitfalls.
This is a slide I put up - I like to talk about 2 separate things here.

First is a quote I've heard a few times. I hope no one has ever had to say this. I hope I'll never have to say it. The idea of, 'I loved her when we got married'. I think that applies very well to a PM tool in the sense that any tool we go out to get, whether it's a PM tool or a CRM or even a Dev tool, a lot of times there's so much there; it's so impressive - we absolutely fall in love with it.

When we get it, we get buried in the weeds. There's so much available to us. So many cool factors or features that we want to be able to use and we end up getting lost in this nightmare of information. It's something where we have to focus on and understand; well, what do we actually need - let's get that and not worry about all these other whistles and bells.

The same thing is true here for our little friend on the skateboard -- for a friend of mine who is obviously going to land on his face pretty soon -- this is the other problem we tend to run into with these PM tools, in the sense that a lot of people who implement PM tools or other tools can fall flat on their faces because the focus is not there. Because we're not sure what we're actually buying, what we actually need, and what we actually need to do.

As product managers who are swamped working 60 hours a week, it gets put off to the side lines very, very quickly. I can't tell you how many times I've walked into a prospect or customer, seen a very expensive implementation of a tool; let's say a development tool which could cost well over $100.000 - that is simply sitting on the shelf.

There are a lot of issues behind that. Around that, what are some things we can do to avoid these pitfalls. Avoid falling on our faces. The first line is pretty simple. Don't buy the whole planet. Don't buy the whole moon when all you need is a rock.

Really get an understanding of what are your problems. What are the three things that are keeping you up at night, driving you nuts in your day to day jobs, that if you solve those problems would increase your productivity significantly. Don't worry about the whole life cycle your entire life; every little whistle and bell that you could automate.

Focus on the keys. Your three biggest pains. Solve those pains. As you solve to hose pains, you're going to develop time; you're going to develop processes to speed things up, and the solutions will grow themselves. This applies especially well to PM tools but I think it applies just as well to any other tool we are looking at whether it's a CRM tool, a development oriented tool - any enterprise application that we are going to pull in to help automate, consult that information; we need to focus it on what we actually need. Let's start with the first two or three big problems that we need to solve.

The other pitfall is value. Demonstrating value. This is probably one of the reasons that some of these implementations for various tools can fall on their faces because we don't have buy in from the organization, we don't have demonstrated value to people to understand why we need to use the tool or how important or valuable it will be for us, and more importantly, we don't have people tasked to do it. It's not on our MBOs. It's not on our quarterly list of things to do. At the end of the day, we're busy people.

We're going to look at our list of MBOs or our quarterly objectives, and whenever a request comes in, we are going to measure it against that and guess what; if it's not on the list it's going to go to the other pile. That's the pile of stuff we'll get to eventually.

If a tool falls into that pile you're never going to pick it up again and it's never going to get anywhere. So we need to have the onus in the organization to say yes; we need to start using this tool. It's a corporate mandate. Have it on the MBO or the quarterly objective, and start to demonstrate the value to the organization so that people jump into it.

If we can demonstrate value, if we can demonstrate time saving and cost saving, people are going to want to plug into the process. They are going to want to start using the tool. They are going to find additional ways to bring it into their groups, or ways they can make their lives better in working with you and using that tool.

Last but not least, we can't talk enough about planning. We need to plan, plan, and plan. We need to focus our implementations. We need to focus on our problems, and we need to plan them out in a way that's going to work with our day to day lives. We've all got jobs to do; we've got a million things on our plate. If we don't plan out our implementations of any tool, they're generally not going to be successful.

It's not a question of planning out the first two weeks. It's a question of planning out the first two years. What do we want to do in the first quarter, second quarter third quarter. What do we need to accomplish by the end of the first year, and what value and return investment do we want to see in the second year.

That's generally where we can start to see and measure things, and come back to our executives, our managers and say look; I'm saving a day a week by using this tool. I no longer have to type everything in, in Excel or plow through my emails. It's there. I hit a button and I get my MRD or I get the report that I need.

So demonstrating value, planning it out, focusing it in and driving it forward over whatever period of time makes sense.

That covers a little on the PM side of the house; the tools, some of the problems that we're seeing.

It's interesting as I go through those slides and speak to those things, I think you'll find that the title of this presentation is incorrectly titled for a reason. We don't have best practices in product management today.

We're new in the organization. We're growing in the organization. We're starting to move up the chain and it's not a question of not having a tool.

The problem rather than the question is, we have too many tools. We've got a Serum tool, we've got a bug system, we've got a Dev tool; we probably have a few others though the question isn't what tools I need to use. It's how do I use them all at the same time. Because there are tools. There are so many. And we do have them.

With that said, let's talk about some of the carrots I want to leave you with here. Some of the things I found in the last year that I love to pass onto people.

The first is just some growth opportunities for PM. A lot of people ask me Peter, what do I do to grow. What's out there in terms of training, certification; how do I get involved with the community; how do I learn from other people. What presentations are out there and conferences.

Let me just talk about a couple things I'd recommend. First there are a variety of training options out there. Of course there's Pragmatic Marketing that I can't speak highly of enough - very common sense methodology and training that's provided worldwide for product managers, very straight forward. It's basically common sense in a nutshell. If you haven't taken it already, it's a great place to start; to have it on your resume and in your brain; to use the pragmatic methodology.

There are others out there. Zigzagus is one of the ones; they have some similar methodologies to Pragmatic that they offer. There is a PM University you can look up - just look up PM University on Google or Yahoo and you will find it there.

They offer a variety of courses you can take and add those to the list, so to speak. The PM associations - the Product Management Associations - I can't speak highly of enough.

These are a phenomenal place to get together with PMs, people in our industry that are doing similar things to us - learn from other people - there's always some great presentations, great places to find people if you're looking for talent.

I can tell you myself personally, I found this job at Ryma, through the Toronto Product Management Association. I simply went to the meeting because it was a meeting of product managers, happened to meet my boss and at the end of the bar session, gave me the offer, basically, on the table there.

It's a great place to meet and network with people; phenomenal place to find talent. I can't recommend them highly enough. There's pretty much always somebody at the PM meetings that is either looking for a job or looking for people to add to their organization.

There are a variety of PM organizations out there in almost every major city; a few here in Canada, quite a few in States and a few abroad. If you're looking for the full list or trying to find your local PM organization, you can go to our website and go to the community link. At the right side, there is a list there of the major PM associations in various cities in North America and abroad.

Feel free to take a look at those and jump into those sessions.
If there isn't a PMA in your location, feel free to drop me an email, and we'd be more than willing to work with you to start your own PMA wherever that happens to be.

There are also some strategy networks out there, as they are called, for product managers. Again, this is another good item you can look up on Google and find some places. They're generally just website where you're having a community come together - similar to a blog - to define strategy, to bounce ideas off people - to talk about industry changes - things that have happened - oh, look what Microsoft's done and is that going to affect my television or my kitchen in the next ten years or whatever it happens to be.

A lot of great places to just lean and define our processes, get ideas from people, or just bounce ideas off of a community of strategy individuals. Again, a good Google search where you can generally find some stuff.

On hiring, I'll just finish off with the opportunities here. Can't speak highly enough about the associations - phenomenal place to find people - if you're looking for PMs - definitely go to the PM associations first to try and find someone.

There's a ton of news groups and blogs out there - Ryma, of course, has sponsored our community page - which is our community blog. You'll see the link for it at the end of this presentation. Great blog. There are a few other ones out there.

Great place to learn from people; see what's going on - see ideas - everything from what does a good report template for MRDs to what's a use case - all the way up to what's the 12 or 15 steps of product management. It's a great place to get some information, see some funny war stories, and get peoples' insight on experiences in the past.

Ton of news groups, ton of blogs - just do a quick search for product management news groups or product management blogs and you will find some information there.

We do have some links off of our site as well.

Last, I just want to talk about recruiters around this hiring option.
I've talked to a lot of companies in the last year and everyone in a large organization or enterprise, has recruiters. Whether internal or a third party company we generally use to try to pull in people.

We do see a significant problem with these recruiters in that recruiters who don't have product management experience, tend to have a difficult time relaying the value and experience someone may or may not have, or frankly the role, to a potential hire or hire-ee.

If we're looking at recruiters and are planning to use them to try to find us product managers, the only thing we have to do to evaluate them, is ask them a very simple question. How many product managers have you gotten jobs.

If the answer is zero, you may want to call a few more recruiters because there is a night and day difference, I've found, between recruiters who have experience in getting PMs positions and the ones that don't.

The ones that do, understand the speak. They understand the wording we are using; the nomenclature around market-driven, around development, around products, around live cycles, requirements - all the stuff we deal with on a day to day basis.. They are familiar with it and they get it.

With that said, they have a much better chance of communicating the information to hire-ees or hire-ers to get us the position or to find us a potential person.

Just a little bit on growth opportunities - and last but not least, before we open up Q&A, I just want to talk about life after PM. It's a common question I get in a lot of my business which is Peter, where do we go after this.

I've been a Product Manager for X amount of years ... what is next ... there really isn't a clearly defined path like there is in other parts of the organization.

A good example, is if we look at development. If we step into development, and we join in and we're a junior developer at the bottom of the totem pole, there's a very clear path, generally, for us to move forward. There's steps and stage and development. There's development management. There's a variety of ancillary roles to development.

But it's generally a clear cut thing that a developer can look at and say, this is where I want to be in four or five years. I want to be development manager. I want to be the director of development or whatever it happens to be.

That's really not there today in product management. In most organizations we tend to get as high as director of product management if we even have that - but then it starts to skew after that because product management is not yet its own entity in every organization.

There's a few but for the most part, product management reports up to development; reports up to marketing or potentially to product marketing, if they've got product marketing.

With that said, we find there are two baselines or backgrounds that tend to denote where people will start to flow outside of product management; when we start to move forward.There's Dev and marketing.

The first of the Dev oriented background, we find the product managers who have a development oriented background, tend to lean back towards development in terms of development management.

So being a development manager, a director of development, VP of development or potentially towards the CTO's office working on technology in some technical fashion; potentially even IT in some cases. But we find the development-backgrounded PMs tend to lean back towards development when they start to move on from product management.

Whereas the other side of the house is this marketing oriented background. So not a technical background but someone who is more marketing oriented or more of a sales oriented background, tend to lead towards a different direction.

We start to move towards business development; that's one of the most common ones I've seen - where product managers who have been doing it for a while who have a market or sales driven background, will tend to move towards sales development as a good step to another role.

It still involves some of the PM duties, still might be technical, but is generally a higher level position. Of course product marketing is a natural one. This is a section of the organization, if we have it; we tend to work with it on a day to day basis.

It is a logical step for a PM to potentially go into product marketing and experience that side of the pure marketing house.

And last but not least, what I'll call solutions and strategy teams. We're starting to see a lot more of these in especially larger level organizations where we have a specific team to help us build solutions; a team that works with product management, product marketing as well as others to define requirements for our solutions.

That may affect how we actually build our products to make sure we fit in with that solution.

Same is true around what I'll call strategy teams. These could be special teams, special projects, or just a straight forward type of strategy team; a team that owns the strategy. We need to be the number one market sharer in our space in the next year. Well, that might be a strategy; let's put a team aside that's going to actually devote their lives to that and pus everyone else in the organization to make sure it happens.

Very common; I'm starting to see a lot more of these teams.

The best advice I can give you - plain and simple - make noise.
When I say noise, of course I mean good noise but not bad noise - but we want to make some noise. We want to be heard within the organization. When opportunities arise, we want people to think of our names. You know what? That guy or gal would be perfect. I remember when they did that press release or that presentation at the conference or that demo for a customer; they would be perfect for it.

So get involved. Whether it's a press related items to get your name out in the industry; great place to have on your resume. Recruiters will often go up and google you and see if you show up on the web.

Great place to have press releases. If you have press releases, and someone googles you, they're going to start to find you.

Conferences are huge. Depending on your business, I'm sure there's a variety of conferences that are out there. Get involved with those conferences. Try to help to promote those conferences and speak at them or any presentation or speaking engagement you can.

It's a great place to get your name out, to build relationships, learn from other people - and of course - our special projects.

Depending on your company, you may have lots of these or none of them. I know I had a few myself back at Symantec - where there's an executive level special project. Somebody has to go and define something. Let's re-do our licensing or re-do our pricing or re-do our strategies.

There may be a whole team and a project set aside for that for multiple quarters, let's say - perhaps just a few months - it would be a great place to get involved in and work on a special project because it's going to help you. People are going to start to hear about you. You can always reference back to that project.

Depending on how high level it is, it's a great place to get some visibility in and potentially outside the organization.

Those are just a couple of things on what I would say is life after PM, that we see.

That's all - I'll close it up here with this last line where I've got my information - I'd love to hear from anybody if we have questions so I will throw it back to see if we have any. I would highly recommend if anyone is interested in topics of discussion - if you want to have a chat around product management or have some ideas for potential webinars that we could do - I 'd be happy to ask a lot of our customers on topics around product management and come back to you with the results.

Feel free to drop me an email. Let me know your thoughts. Check out our website. We have a great community blog with a lot of information; a ton of WebEx's - just a ton of information for the product management community to come together, build some mind share, get some information and work with other people in the organization.