Dee worked in Detroit Michigan for GM. 51 years old and just laid off.
The economy is bad. "At least my three girls have grown up", she tells me.

A few years ago, (actually 9 years) she was a very successful product manager.
She knew what she was doing.
She executed her "system". Her GM team followed a formal CMM level 5 software development process.
The primary team all knew their jobs and had worked together for 3 years, some longer.
She was making good money, head hunters were chasing her down, and her products were the envy of the world.

Smiling, she tells me that she had the skills of that "lean-mean-fighting-machine" that everyone needed.
Looking down at herself, (40lbs overweight), not so much now.

At 17 Dee was a single mom with three young daughters.
No education, living in a single room apartment.
She tells me that one of her coworkers at the Dairy Queen, "Roxy", and her won a trip to Las Vegas.
Those were the good days.
That weekend Dee won $50k. "Boy was I lucky", she whispers with tears in her eyes.
She used the money to get an education and turn her life around.
Who would have guessed it? One thing led to another and she eventually became a product manager.
At the end of the interview, she looks up at me.
Is this a common cycle with product management in general, or is it just me? I told her I didn't know.

What do you folks think?
Is it Luck-Skill-Feast-Famine and repeat?

In all the Product Management literature, have you ever read a book, blog, or tweet addressing how to succeed when your product fails? Somehow, folks have a hard time separating the success/failure of the product manager and the success/failure of their product. Much like when we criticize someone's actions; we're not to take it personally. Somehow our actions are supposed to be isolated from "ourselves".

I'd like to know how many product managers have been responsible for failed products? Are there any that would admit to it?

In this economic war, my friends are dropping like flies. Everyone claims it's not their fault. Well whose fault is it?  Regardless of whose fault it is, failure happens. The professional Product Manager should expect failure to occur sometime in their career. When it does, what should they do?

I believe there are three "best-practices" that professional product managers should put into place and use as guiding principles throughout their careers. Joshua Macht from Harvard Business Publishers published a great post titled "Survival of the Slimmest?". In this post he proposes what I want to call the first principle of failure.

Fail cheap and fail often. In product management, the longer you wait to fail, the more costly it becomes. Don't wait to validate product concepts until the product release. You can fail much sooner by failing during a problem statement validation step. Guess what, at that point it doesn't cost much to fix.  Constant experimentation has to become a routine part of the product manager's life.

Failure should be our prime directive, we should seek failure not avoid it. The second principle comes from Gill Corkindale's post "Resilience: How to Build a Personal Strategy for Survival"."

Be Resilient. Gill suggests 10 steps to resilience. Implement them all. Make a check list and check it off. Make sure that as a product manager your actively taking these steps every day.  If you do then your resilient, if not ...

• Develop supportive and caring relationships at home, among friends and colleagues. Accept help and support and help others when they need it. Product Managers must maintain a social media network.
• Remember that some crises are beyond your control. You can't change events but you can change the way you interpret and react to them. Try to accept this and look ahead. Think of events as bugs on the windshield. By themselves they can be dealt with. But events add up, and it's the accumulative effects of poor visibility, low tire pressure, worn brakes, ... all lead to accents. As we skimp on Product Management activities we start the cycle that leads toward crises.
• Accept that change is part of life and that you will have to adapt to changing circumstances. Prepare for constant change. Seek out change resisters. If you can't remove them, then find ways to reduce the impact of the resistor, and the probability of encountering the resistor.
• Set some realistic goals and take regular small steps towards achieving them. Ask yourself, "What's the one thing I can accomplish today?" rather than focusing on the overarching goal. Remember small steps allow the Product Manager  to fail cheap.
• Be decisive. Do as much as you can rather than avoiding problems and hoping they will go away. Indecision kills the Product Management team, and is normally systemic of poor processes. Good decision making in the heart of uncertainty comes about through understanding trends and turning fact based decisions into intuitive estimates of the future. Small steps are the key.
• Try to understand your own experiences of dealing with loss, hardship or emotional problems. Appreciate what you have learned from these events. The Product Manager must keep a professional journal. This has been a life raft for me and countless of others. Do it. Make sure you're logging lessons learned.
• Develop a positive view about yourself and be confident in your strengths and abilities. I find that a history and trend analysis of key performance indicators is the medicine for this one. Monitor your performance. It'll make you feel better, and those around you.
• Try to take a longer-term perspective and don't blow the significance of the event out of proportion. The product manager can't do this unless they know the significance or impact of the event in context of other events.  Product Management tracing tools are a powerful tool for maintaining a balanced long-term perspective.
• Stay hopeful and optimistic. Visualize what you want, rather than worrying about what you fear. Fear destroys the product manager; refer to the blog post, Fear Tax. Correct balances of practices make this possible.
• Look after yourself - your health, fitness and need for relaxation and peace. This will give you the strength and balance to deal with difficult situations. I know the Product Manager thinks they're the exception. I have not found evidence to back this up; yet most product managers ignore this step.

In my principles, the first was to make seeking failure part of the process, the second was how to lessen failure's impact on you personally, and the third principle is focused on eliminating execution or activity failure through education. Rosabeth Moss Kanter posted "The Best Investment Advice You'll Ever Get".

Invest in your own career How many product managers can clearly articulate the value of product management? If you can't, what makes you think the person determining headcount can? Understanding product management's value, and increasing that value is required to maintain your competitive advantage in the workforce. Lifelong learning and information capitalization is essential. There a many disciplines within the innovation value chain where education doesn't have a direct impact on the value of the chain. Product Management isn't one of them.  When a Product Manager invests in education, they are truly buying stock in the innovation value chain they direct. The time others spend looking for the perfect stock to invest in should be spent by the Product Manager looking for the perfect learning opportunity.

But, failure will happen. When it does, Marshall Goldsmith identifies Four Ways to Bounce Back From Setbacks.  It's a good post that provides a little confidence during uncertain times. Its easy enough to put this information in context of the life of a Product Manager.

The Product Management Community knows the value of failure.
They also know how to address failure.
Meaningful steps toward steering the activities within the innovation value chain to avoid general failure can be taken.
Product Management must effectively keep the path straight.

The good news is that those who wish to help Product Mangers address failure within the innovation value chain can play a constructive - perhaps decisive - role in keeping that path unobstructed.

In Steven Haines book, "The Product Manager's Desk Reference" he refers to Product Management as "the Accidental Profession". He makes his case the following way. "I teach Product Management classes all over the world. At the start of every workshop, I ask if anyone has a degree in Product Management. Virtually all the time, there is no response." He asks, "If you're all product managers, but you can't get a degree in it, how did you get the job?" ... It's a good read, at least that section, and worth a comment or two.

Occasionally I'm asked to provide career advice. 

Last week I had a young lady ask me what she should do to become a Product Manager. I'd talked about the thrill of product management with her previously. And yes, you skeptics, I love product management. So what does it take to become a Product Manager? I'd love to hear other opinions?

"What kind of product manager do you want to be?" I asked her.

Instead of Mr. Haines's "How did you ..." I want to know, "What did you do?" Mr. Haines tells us that those attending his workshop claim they didn't do anything. They're innocent, so they claim. They respond to his questions with things like:

"My boss asked me if I wanted to do the job, and I thought it would be a good experience."

"I thought it would be interesting."

"I was in development, and since I knew the product, they thought I'd do well here."

"I was in sales, and since I understood the product, I thought it was the next logical step."

"It sounded like such a neat job."

"I did marketing before, so this was a good fit for me."

I have to ask you. What kind of Product Manager do you think they are if this is what they did to prepare? At least they're attending his workshops now. With help, maybe they won't be Dogs, maybe, just maybe with help, they can become Monkeys.

I couldn't ask anyone to become a Monkey on purpose.

In Mr. Hanes book, there are 21 chapters introducing various topics such as:

The list goes on ... I'm just tired of writing.

In RYMA's Adaptive Product Management Implementation Methodology there are 20 major functions for the software industry, over 60 across the entire innovation value chain. Each function is divided into three categories of APM Methods. Within some of these categories there are over 100 different methods.

How does one prepare for the depth and breadth of understanding that a Product Manager needs?

You don't do it all at once.
You don't delay your career waiting the day you know everything.

Building your career must be as adaptive as product management is itself, and for many of the same reasons.

Even if your product management team knew everything in Steven Haines book right now, they couldn't effectively apply it. It's the difference between knowledge and wisdom.  It's the difference between a methodology and implementation of that methodology. The team must grow together, and as they grow they adopt new practices. I hear product Manager's exclaim, "Why didn't I do that a year ago?" The truth is they probably weren't ready to a year ago.

I find it's all about change adoption. Individuals have a rate at which they can change. Organizations inherit the rate of change from its people. Adaptive Product Management helps address this rate of change, for the individual and the organization.

The Product Management Community knows the value of change adoption.
They also know how to prepare for a career in Product Management.
Meaningful steps toward steering the activities within the innovation value chain can be taken by using the APM Implementation Methodology.
Product Management must effectively keep the path straight.

The good news is that those who wish to help Product Mangers adopt new practices within the innovation value chain can play a constructive - perhaps decisive - role in keeping that path unobstructed.

Have you ever felt like the Deer in the Spot Light? Don't you just know the bullet is fast coming? Yet, Mr. Product Manager there you stand, frozen in uncertainty.

It's time to cut. "Everyone must do it." Today and in the foreseeable future the business objective is to cut costs. Business objectives change rapidly. Rapid change is the environment that Product Managers live in.

Reduce Costs!

Scott Anthony in his blog "Scott Anthony Innovation Insights"  post dated 28th Jan warned "Cut Customer Service? You'll lose Customers". Product Managers want customers ... Must keep customers ...

NO WAIT.

Scott states, "Companies might think that innovation and survival are discrete choices. They are not." This is an assertion that should have been better supported. Innovation and survival are discrete choices. Like all discrete behavior (that of an individual or organization of individuals), the question is about the time interval. If it appears continuous, shorten the interval. Eventually you'll see the beginning and end.

If this is true, you can cut innovation, and any other discrete event, and still survive. The question is how long.

Go Ahead, Cut!

"How long? What does that mean?" Scott might ask. "If you cut an arm off, it's cut. Can you say, FOREVER?" Companies without Customer Service die, they don't survive. That's a proven fact.

WAIT.

You've hit on something here Scott; arms are a continuous part of the body. It's part of the body's structure. Is there a way we can keep the organization process of Customer Service intact, while cutting the activities of Customer Service for a short periods of time? If so, Product Managers could throttle Customer Service activities to regulate costs. In this way we don't cut the arm off; just reduce blood flow for short periods of time.  We don't have to amputate when we get tennis elbow do we?

OK, Go ahead and throttle the flow!

Customer Service is critical to the survival of your company. How do you know how long the Product Manager can keep the activities turned off? This is a tricky and dangerous business. It reminds me of a video clip "Monkey vs. Tiger" I saw recently. The Product Manager would feel like the monkey playing with the Tiger's tail. Customer Service is just one of hundreds of discrete activities that the Product Manager manages across the innovation value chain. How do they know which activities to reduce, by how much, and for how long? These activities span across the entire organization, the product manager isn't even responsible for some of these things. There are teeth at the other end of that tiger you're playing with.

WAIT!

That's why activities across the innovation value chain should be instrumented with key performance indicators. These indicators have thresholds that are monitored by the Product Manager. When the business environment changes the business objective may change. If the business objective changes some of the targeted threshold values change. The Product Manager doesn't have to cut ...

Never mind - The BULLET just found you.

Your competitors were using Adaptive Product Management. All of the APM practices we're in place. All the KPI's we're being monitored by a set of dashboards. When their objective changed to reduce costs, within seconds, the Product Manager's activities were aligned to the new strategy. In fact, all the activities of the innovation value chain became aligned to the new strategy. They gained significant cost reduction in less than 30 days. While you were contemplating cutting off your arms and legs, they gained the competitive advantage.

Not only are their customers more loyal than ever, but your customers became tired of waiting.

The Product Management Community knows the value of Adaptive Product Management. They also know how Product Mangers can acquire APM capabilities. Meaningful steps toward steering the activities within the innovation value chain can be taken by gaining APM capabilities. Product Management must effectively keep this path straight. The good news is that those who wish to help Product Mangers gain APM capabilities within the innovation value chain can play a constructive - perhaps decisive - role in keeping that path unobstructed.

I received a letter some time ago threatening my family's safety. They were to be killed if I didn't change my proposed position before November 5th.   I reported this to the security officers responsible for our safety. Folks came out to our home and evaluated our defensibility. Their mission was to examine my "exposure". My wife loved that.

They told me my exterior doors were worthless. "Get armored ones. Order bulletproof windows. Build a safe room. Install panic buttons. Upgrade you wireless security system. Get rid of the cedar fence in the backyard and put in a steel-and-concrete one. Screen incoming calls. Don't use the front door. Don't use the driveway. Vary the way I come home - and our entire family's schedule."

Pretty soon, we were talking over six-figure costs and relocation to Canada. And that was back when six-figures were a lot of money.  November 5th came and went uneventfully, but the experience taught me some important lessons about Product Management.

When security is at stake, there is no limit to fear or fortification.

The Al-Qaeda and the like have taken more from Americans than the IRS has. Think about the "extra half-hour" millions of airline passengers waste standing in security lines. The annual cost in lost work hours runs into the billions of dollars. Add to that the freight delays at borders, ports, and airports. Add the cost of checking money transfers as well as goods in transit, and the wages for beefed-up security forces around the world.

I say, "If fear starts like a tax,
behaves like a tax,
and produces results like a tax;
then it must be a tax."

This world wide "fear tax" represents the most significant victory of Terror to date.

Sun-Tzu in the Art of War states that "Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat." Product Managers need to maintain a balance between how they react to their competitor's, and how they advance, much like the balance between strategy and tactics.

Fear of the competitor can tax the product.
Fear of the competitor can tax the process.
Fear of the competitor can tax the technology.
Fear of the competitor can tax the product management team
until there's nothing left to give.

Fear thrives on the unknown. You must to know the competitor if you want to reduce the fear tax. You must maintain a balanced response to competitive information. Building bulletproof products is not a balanced response normally.

Bold new strikes in the market place can come as much from reducing the fear tax, as they do from new innovation processes.

Fact is, less than three out of ten Product Management teams feel they are gathering sufficient competitive information. Even less feel they can adequately respond to the information they have. To me this means that the worlds Product Managers are paying too high a fear tax.

Just like what my mother used to teach me about the play ground, good competitive analysis can help avoid fights. But that's not all competitive analysis can do. Most Product Managers view competitors as a threat. While competitors can be threats, the right competitors can strengthen rather than weaken a product's competitive position.

"Good" competitors can serve a variety of strategic purposes that increase your product's competitive advantage. Accordingly, it's often desirable to have one or more "good" competitors. See Michael Porter for more on that. Competitive analysis should be a part of every Product Management process. Even a little will go a long ways in reducing the fear tax.

Access to good competitive analysis is essential to the Product Management team. The correct response to that information is the Product Manager's responsibility.

At the end of the day, if your product management team is paying too much fear tax ― have a talk with your Product Manager.

The Product Management Community knows the value of competitive analysis.They also know how Product Mangers can develop correct responses to this information. Meaningful steps toward steering the activities within the innovation value chain can be taken by using competitive information.  Product Management must effectively keep the path straight. The good news is that those who wish to help Product Mangers better utilize competitive information can play a constructive - perhaps decisive - role in keeping that path unobstructed.

Sorry, not a job posting... I am all theory here.

In times when people are reducing staff and cost cutting, it would seem odd that I am about to highlight another required role. I want to highlight an article to support a problem that I am seeing in medium to large sized organizations. From Pragmatic Marketing: Software Product Architect Job Description

"As Product Architect, you will lead the design effort on a variety of projects in a highly collaborative, fast-paced environment. Your role is to design innovative solutions to real market problems. You will work closely with product and marketing managers, user interaction designers, and software engineers to develop new product offerings and improve existing ones. This position reports to the VP of Development."

Consider this situation... Two product managers who are based in different offices, organizationally on separate teams and each own one product. Both products are typically bundled and used at a customer site and except for the rare integration scenario neither product manager collaborates with the other. Imagine if you will, each Product Manager receives a separate enhancement request from a different customer asking for the same thing. Separately, they each run through basic sensing techniques to determine the pervasiveness of problem and articulate the problem statement for their product. Awesome! Now what?

They have documented a problem for their product that should potentially be solved in one and only one of products. The challenge at this point, how do they recognize that they are on the verge of writing requirements, getting estimates, passing it through various validation stages for the same problem, in essence duplicating effort? This becomes a bigger problem if the development team builds the solution twice.

In practice, we want one of the product managers to identify a problem, document it and the other product manager to identify a problem and recognize that the problem already exists. Technology can help, at least you will have a central repository for searching, but still required is discipline to collaborate, strong writing skills to ensure they are communicating in the same language and responsibility to do the right thing (make the right decision).

On the development side of the organization there is usually an architect type role that binds everything together, someone who is ultimately responsible that the technical designs are consistent and within the existing framework to ensure efficiency on the development side (no one is duplicating effort). I think the Product Management teams need this role too (or someone with this responsibility). I want to think of this as a Product Management Architect. This is someone who has overall responsibility for the quality of the problem statements, someone who is responsible for the best solution for those problem statements, someone who holds the big picture for the product portfolio and someone who has the potential customers in the front of their mind, not the technology.

The simplicity of my scenario doesn't really do the problem justice but if you start to think about a 15 member product management team that parses maybe thousands of inputs into hundreds of problem statements how pervasive this problem can be.

At the end of the day, as technology providers, operation efficiency is paramount to our success and maybe even a differentiator. Duplicating effort is the opposite of efficiency. The market sensing and problem identification is the bread winner of product management and the key to efficiency begins at the point of problem statement concept.

Last point, for the smaller groups I'd like to see you begin to have problem statement regular (weekly) review sessions on a regular basis. No harm can be done by reviewing the problems experienced by your customers.

I posed this question to my wonderful network of tweeple... here are 4 responses

@chriscummings01 @StewartRogers Innovation is a new idea, system or feature that positively--and measurably-- impacts your product's benefits-to-costs ratio.

@inventeleph @stewartrogers Innovation: Approaching the world looking for different and selecting for better.

@jbrett @StewartRogers creating better solutions to obstacles

@justin_dz @StewartRogers Improvement which is un-anticipated (or under-anticipated).

Anyone want to add their thoughts?

Again, me on twitter ... http://twitter.com/StewartRogers

To be honest... I have no idea how you do it anymore. You are pulled in 5 different directions. You have input flying at you from 9 different sources. You have advice from everybody and their Uncle. Three new Product Management books in 2008 alone! There are blogs to read. There are webinars to watch. Seminars to attend. Trade Shows to work. PRDs to write. Roadmap to update (or create!). You are innovating. You are in the middle of a switch to Agile that is less than successful. My head spins just thinking about it. Yet you deliver product release after release. And you manage this with Microsoft Office. Kudos. I must admit, I have been thinking about Adam's blog (Write That Down) recently and it seems the message behind his posts are to keep it simple. Subtle brilliance.

Let's step back and think about what your "day in the life" looks like... and try to answer why we do the things we do. I assume your company has a vision (or mission) and some goals (and/or strategies) to achieve that mission. This means your job is to put a strategy in place to reach those goals with your product (or product line). There is the answer. Simple. Does going to the meeting help you reach those goals? Does doing that demo? Does that feature?

I bet asking this question cuts out 20% of what you are doing today.

With respect to your product and given the constraints you are likely under, what is the absolute minimum you need to 'get it done.' You need requirements for development. You need features and benefits for product marketing (or your right-brain). You need a roadmap to plan delivery and define priority. Every activity from there should be done to a) execute the roadmap, b) validate the roadmap and c) extend the roadmap.

I'll leave you with one question... Can you trace every requirements (and feature) back to your corporate strategy?

Turn on any news channel today and you can't help but hear the dreaded "R" word. That's right, according to the "experts" we are well on our way to a full blown recession.

So what does that mean for product managers? Do we just hold on and hope for the best? Is there really anything we can do?

I would argue that for most of us, there is a lot that can be done. And now is the perfect time to do it. It seems like every year we are asked to "do more with less" and do it faster, but if this recession is as bad as some are predicting it will be, we're going to see some serious tightening of the purse-strings like never before.

Fortunately, it appears the recession is not fully upon us yet, so there is still time to prepare and "Recession-proof" your product management process. Sure, you could just cut expenses and head-count, that's always worked before when things got tough, right? Well, that may have worked in the past, but times have changed and we can't expect to just tighten up our belts and ride it out like we used to.

We have to find some way to cut development costs while at the same time reaping some other benefits, like increased product quality and decreased time to market. That doesn't come through just reducing headcount but rather through implementing best practices and tools for better product management.

Since you're here, reading this blog, you probably already know that. So why will a lot of us still not react by changing our ways? Is it just the fear of change that Peter recently blogged about in A tale of two monkeys? Is changing process and adopting new tools with a recession on the horizon just adding more risk to an already risky equation? Or is now the perfect time to look at new ways of product management? I would be interested to hear your comments on this.

Last week, Peter posted the tale of two monkeys. He made a very good point about product management strategy. He pointed out that often we get stuck in the same rut, doing things the same way because that is the way things always have been done. When we get stuck in a product management rut, our business often follows.

Innovation is a good way to break that rut. Look for ways to improve -- or even change -- the current product management processes. Instead of taking someone else's word for it, look at the process yourself. Question not only what is happening, but also why it is happening. Only through innovation, and an integrated way of thinking, can you break out of your rut.