The Product Management Manifesto
This is a monster post. Is it really a manifesto? Probably not. I hope we can turn it in to one together. It’s a group effort and I’m pushing hard on some things that I really believe will help take our role to the next level. I hope we can get the right kind of light shining on this thing and we can make it our own. I want everyone involved.
It’s really something that belongs to the community of product managers (PdMs) that have been pushing for something like this for a while - I’ve heard the rumblings and am giving it my best effort. Can we all put our virtual heads together, make it the best we can and take it to the next level?
Only time will tell. So, with that — away we go.
Tom Grant over at the product management Forrester blog referenced a couple of my posts recently, and I took the opportunity to write a longer-ish comment related to how a couple of fundamental problems with product management could be solved. I’ve been thinking about these things for a while.
The way I see it, there are really 2 key issues that need to be resolved with product manager’s and the role in general.
A Common Philosophy
There really isn’t a recognized de-facto philosophy to product management. Well, if there is - I don’t know what it is. I’m trying to approach this from a broader perspective as opposed to just software. So, here’s how I propose it’s defined:
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.
To me, it’s important just to get this out there and then start to gather some feedback from others (yes, readers, I’m talking to you) and then tweak based on the collective.
A Common Set of Fundamentals
Now, the fundamentals. How do we define these? Well, I’ll try to stay away from buzz words as much as I can, but keep it as concise as possible based on the philosophy I have outlined above.
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.
Some Solutions
Aside from getting these things tweaked based on what we all feel is appropriate and getting them used, the next step is to really get them out there. I see this as being done in a couple of ways.
More Books
We need more books on product management. More quality books - not 1/2-assed Coles notes with some templates. Real, hearty books that people can dig in to and really understand this craft. Amongst all of the PdM’s that read this blog and all of the others, certainly we could get some interest in writing one of these things that go through the philosophy and fundamentals.
I’d love to get everyone involved - Scott, Bob, Roger, Jeff, Steve, et al. We could churn out 2-3 complete books on this job to get some detailed, quality information out there to get more folks interested.
Get the Role Taught in Business Programs
We need to take these core aspects and get it in to MBA and undergrad business programs. Quite frankly, I don’t know how this starts or how to even get it going. Maybe it stars with a series of guest lectures or something. Lobbying professors and top-tier schools to get it added as a stream to their programs.
Product management is every bit as important, and deserves as much executive and senior management attention in any organization as sales, engineering, marketing, and customer support. In many cases, it’s connecting these functions together - why wouldn’t it be allotted as much importance when teaching the theories and fundamentals of business?
The goal here is to shine light on this fantastic, and necessary, job function within an organization. We need to stop the extremely common occurrence of people getting thrown in to this job without any clue on what to do. It can be prevented, and quite honestly, it needs to be; it’s simply ineffective to do things this way.
Are product managers that special a breed? Some may say so, but it’s just a job people. We all put on our pants (hopefully), head in to the office and do our thing. We don’t get much recognition, simply (as Saeed Khan has called out) it’s just us doing our job. I think we need to stop breeding the confusion and mystique around the function, though. As I’ve said before — it’s not hard. It’s easy.
But, this starts at the ground floor and moves from there. Educate. Provide the right tools and foundation. We need to really align on this thing and drive it home for it to work.
My hope is that this can catch on. For us to succeed within an organization, more people have to understand just what it is we do and why it’s important. I really believe that every organization has room for product management just as they do with marketing and sales. It shouldn’t be relegated to non-existance or the corner of the development office just because it’s not understood.
Let’s make it understood.
And like anything, to do that - it all starts at first principles. Let’s get a discussion going and take this thing to the next level.
Giving Effective Feedback
I’ve seen several posts written, and written several myself, about gathering effective feedback when you are in product management. But what about everyone else that’s interfacing with product? How can you give PdMs good, solid feedback on a consistent basis?
First, lets take a quick step back - why do we encourage anyone and everyone to give feedback? Isn’t it the PdM’s job to identify the ways to make the product better?
it’s true that one of the core tasks of product managers is to gather and filter input, make decisions based on it and/or make recommendations to senior management about directions to take or priorities to pay attention to. But, there’s one important thing that everyone in an organization should always remember - it’s everyone’s job, all the time, to help make products the best they can be.
Many PMs will tell you that they’d rather receive what someone thinks to be a crappy idea than no ideas at all. Ensure there is in fact a reason for the suggestion and it does provide value - or, at least, you think it does.
I will always try to ask, “what do you recommend?” (or more simply, “why?”) when receiving ideas / notes / feedback to ensure I’m capturing the full thought, and that one is actually there. I want to be sure I get an entire notion or idea - not just cut it off and only take a potentially negative criticism. If a PM in your organization is blindly accepting things like, “this doesn’t work” or “I don’t like this,” they aren’t doing their job.
They need to dig deeper to get the entire request. This is why it’s important people interacting on the front lines (with real users) are trained to inquire and gather that feedback properly. Many times, users will just write a 1/2 finished idea without even realizing it. They may written at a time of frustration or being super happy while using the product; but in many cases they will leave off the “why?”
The “why?” is the most crucial part, because it’s what tells product manager’s what’s actually important to the user giving you the request. If that’s not there, it’s all very binary - a thumb’s up or down would suffice.
This doesn’t just go for product feedback, but delivering feedback in general; especially when managing others. One of the best lessons to help someone that may be more junior (or, depending on how you look at things - less jaded) learn is how to deliver proper feedback. Whether that’s a product idea, making a PowerPoint deck look better, etc… The earlier people get comfortable with the practice of actually explaining why they are saying something, the better. But, I digress.
Product manager’s should always be willing to listen to feedback. And those that want to provide it to them should make sure they have these critical elements in their delivery. Heck, anyone should feel comfortable even asking their PdM if they are providing their ideas to them in the most effective way possible. That should help clear any confusion / misinterpretations up pretty quickly.
Tony Stark - Best Product Manager Ever?
It’s not a secret I like Iron Man. Even if that now, in the Marvel universe, Tony Stark is a total ass.
With that being said, I think it’s pretty clear that Tony Stark is probably one of the best product managers technology-focused founders ever.
Update: See the comment thread with Bob Corrigan of ack/nak fame for the reason why I changed this. He’s totally right…but Stark still gives one hell of a demo.
Nevermind being a successful founder of a huge military-driven organization, but he’s at the centre of all of the products the organization creates and releases to their customers and the market(s) they occupy. While there are flashes / glances of this throughout the comics, it’s pretty defined within the movie. Obviously, I’m leaving aside how crazy that is for the size of company Stark is supposed to be. But, I digress.
If I could link to specific clips I would. However, I will say this - Stark’s product demo skills are unmatched. Here’s his pitch for a new product (a missile, called the Jericho).
*They* say that the best weapon is the one you never have to fire. I respectfully disagree. I prefer the weapon you only have to fire once. That’s how Dad did it, that’s how America does it… and it’s worked out pretty well so far. I present to you the newest in Stark Industries’ Freedom line. Find an excuse to let one of these off the chain, and I personally guarantee, the bad guys won’t even wanna come out of their caves. Ladies and gentlemen, for your consideration… the Jericho.
Stark is every VC’s dream - he is both business savvy and incredibly technically savvy; not a lot unlike Bill Gates.
I’m sure Stark Industries / Enterprise / International (the name depends on where you are in the comic timeline) has seen some pretty brutal product and technical reviews go down in their halls - with engineers either out of jobs of reduced to tears after having Stark rip apart product specifications they have created.
Of course, I’m stretching things a bit here. What am I really trying to say? That an organization needs a Tony Stark in order to truly succeed? Of course not.
But, he does the same thing as any organization ever has in order to make it truly successful. He didn’t start out with all the crazy technology he currently has and billions of dollars. He started out being obsessed with building the best military weapons possible. That’s the point.
Google did the same thing. They didn’t start with Gmail, and Google Gears, and Picasa, and all that stuff. They started with search. They got that right, have billions of dollars today and a myriad of products. But…guess what?
They picked 1 thing (search), obsessed over it, and got it right. Then they made things more complex, and grew, etc… But they didn’t start out with the goal of being a billion dollar, 16,000 person organization.
Just like Stark obsesses over creating the best weapons technology around, products can only be successful if they start with 1 champion (a founder, CEO, product manager, etc…) and it solves a problem, and it’s obsessed over, ultimately by a group of people working to achieve a common set of goals.
Changing Product Direction
From time to time you need to tweak and change your product’s direction. Essentially, this means that you’ll be trying to work in new things, but also change existing things at the same time.
So, how does this impact the organization? Well, in a lot of ways. Namely, it’s the swapping and changing of certain key features that currently exist and changing those out for new features that better match the revised vision.
Really, this is just all about one thing: alignment. Competitors will come and go, but to make a product truly great, it has to align to your overarching vision - the identification of the solution for how to solve your chosen market problem(s).
Now, in theory this is very simple. Turn some knobs here, change out some labels over there - easy, right? Well, not really.
Successfully shifting a product from one chosen strategy to another (regardless of the size of that shift) can face some adversity within the business. People are inherently adverse to change, which is really where the challenge lies. Everyone will be OK with things until features start to get severely changed (or, in many cases, dropped) because they may feel things are working out really well as they are - or maybe, the didn’t understand that a product strategy shift would mean so many new and/or different things.
So, how can you as a product manager help to ease this transition to the new strategy you may have created (or not)? You kind of can’t - just let it run it’s course. Clear things up for people as much and as regularly as possible.
The other thing you can do is communicate early and often. This is something I struggle with because I always ask myself, “why are people interested in what I have to say?” I am slowly coming to the realization that it has nothing to do wit me as a person, but me as a product owner. If you are in charge of the product (and thus, the associated strategy) that’s changing, everyone will be interested in what you have to say.
Why? Because it directly affects them and what they do.
Make the change - buy in to that change. Execute it. Remove features, change features - sometimes more drastic changes are required. It will make the product feel awkward. It will feel drastic, and in some cases downright wrong. But you have to buy-in and you have to commit. Otherwise, you are failing to properly execute the product strategy you believe will make it successful in the end.
