Product Management - Recently Updated Pages

Philosophy

lars3loff — Mon, 28 Jul 2008 04:54:55 CDT

Meant to serve as a standardized philosophy about product management. Eventually, this needs to become a single entity. Here is what exists so far.

From Adam:

Product management is the function of serving as a proxy to a defined set of markets (or market segments), in order to be able to ensure appropriate product creation, and ongoing product health and quality for those markets throughout a product’s entire lifecycle, until end of life.

From Scott:

Product Managers understand markets and the problems faced in those markets. Product managers choose the problems to solve, prioritize those problems, and communicate this knowledge to the people who build solutions. Product managers engage customers and learn from them, continuously improving their products, as long as it is valuable enough. Product management is the job of being a product manager.

From Stewart:

Product Managers represent the voice of their existing markets ensuring accurate problem definition and solution facilitation for the sole purpose of sustainable product evolution.

Definition Elements from Lars

Customer - customers and potential customers make up the market. Product managers can interact with customers and potential customers to understand the market.
Market - a group of people with overlapping needs and problems. Product managers can interact with the market through market research and their product offerings
Problem - people in the market have problems. Product managers have to analyze these problems and determine interdependence between problems, determine desirability (market view), technical feasibilty (technology view) and profitability of a potential solution.
Product - a product is an attempt at solving problems in the market through a combination of technological, social and process factors
Solution - product managers have to specify solutions in terms of product specifications and map them to problems detected in the market. These solutions have to be monitored regarding implementation and quality (technology view), market adoption and competitive reaction (market view) and profitability.

Product Management Home

lars3loff — Mon, 28 Jul 2008 04:39:33 CDT

This wiki is meant for product managers across all types of industries. Software, health care, finance, whatever. If you manage a product, your insight is valuable.

The content within is really striving to become a way for all of us PdM's to create a standard framework. What is product management? Why is it so critical to all types of organizations just the way sales or marketing are? What are the key elements (or fundamentals) for performing the job?

Anyone can jump in and contribute; hopefully we get to the point of having a pretty excellent resource form which more and more learning and knowledge about the function can result.

Fundamentals

adambullied — Sat, 05 Jul 2008 00:19:16 CDT

Fundamentals are the key / overarching elements of how to manage products. I have copied the ones I came up with as a simple starting point, with the intention of them changing and growing as we go.

1. Understand the Problem

Before anything else, a PdM needs to understand (read: have the best / most firm grasp on) the problem the product is trying to solve. This is the absolute basic, most relevant path to being a successful product manager. If you can’t define the problem concisely, you are already dead before you even start. If your problem is too broad / cloudy, you’re done for.

Make it clear. Make it real. Make it concise.

2. Know Who It’s For

Secondly, you have to know who has this problem. Again, if you can’t define that (at least in some broad terms to start) you’re failing before you even start. Recognizing there is a problem is the first thing, but you need to know who has the problem (and why the do) before you can start to solve it. Take this out of products for a second. Think of it like a doctor. If you’re McDreamy on Gray’s Anatomy, would you go in to operate on a patient’s brain without knowing a) what problem they were experiencing and b) who the patient was, their history, etc? Maybe McDreamy could because he’s just that good, but trust me - no other doctor in the World would probably do this.

Diagnose the problem, understand who has it (and why) and proceed.

3. Ascertain Appropriateness or Health

Once you have determined what it is you are trying to solve and for whom, it’s time to either a) ascertain if your product in it’s current state (TODAY, i.e., it’s “health”) can get the job done. Or, conversely, determine if there is an appropriate problem and market for a new product to be released in to the wild.

4. Develop a Clear Picture of the Future

Some people claim this is lame. It could be called a roadmap and backlog or something else entirely. But frankly, you need to write down for the rest of the class how you plan on solving the problem right now, next week, next quarter, and maybe next year. Don’t get carried away - remember to make it real - but you need to write it down.

Some people won’t get it. Some people will complain. It’s your job to figure this out and validate it as much as you can. Maybe you can’t. Maybe what you are doing is brand new. Gather feedback where you can and push.

5. Execute in Concert

Now the fun. Of course, you need to actually ensure everything happens with all cross-functional teams. Dev, mktg, sales, support, ops, manufacturing, PR, etc… Plan out the appropriate steps to make sure a) the product is built and b) it gets to the people for which it’s solving the problem. If these things don’t happen you will end-up with vapor (people believing a problem they have will be solved, but in reality nothing exists to solve it) or a product that you believe solves a problem for people, but no one actually knows about it. No one can talk about it in terms that folks understand (um, hello - positioning), or no one can buy it (um, hello - sales and sales training).

Get it done and get it in their hands. Remember, you know they want it. Or you should. See how all this kinda works together?

6. Shepherd and Adapt Based on Feedback

On to maintenance and lifecycle management. Now you have the base - the foundation - of solving a problem for a group of people or businesses and they have bought in. Now what? Do you move on to the next thing? Hell no - get out there and figure out how to make this thing really sing!

Figure out what’s not working, what is working, what the users like, what they don’t like. Then, make it even better. Keep pushing. Keep improving. I don’t like to use the terms “innovate” or “wow factor” or “silver bullet.” If they happen, great - but whatever. You can’t bet on these things. You HAVE to bet on building a real product for a real problem for real people / organizations. Just rinse, lather, wash, repeat. Push, push, push — figure out what really sucks. Have marketing figure out what really works and exploit it.

Chances are, there is something within your product that you never even thought people used / would use it for, but they do. Maybe it starts shaping in to something different that solves a different problem - this is evolution. That’s what managing a product through a lifecycle until end of life is all about, folks. But at the end of the day, you gotta get this thing in front of people and learn what they hate / how they use it to really make that happen.

This doesn’t happen in labs or behind one-way mirrors. This happens in office cubicles, at the dinner table, in front of the home computer, at an airport - everywhere.