I appreciate your site. Thank you for your insights and guidance. I have also gained a lot of knowledge from the others who have commented here.

This is especially important in the midst of the financial crisis, when there’s a lot of bashing and cynicism towards performance evaluation, recognition, and inspirational efforts in the workplace. Just check any bar in lower Manhattan! It’s a shame.

As a VP leading over 100 salespeople, I’ve found that the hard fact is that QUALITY performance recognition works. Not just for morale, but in dollars. I have been using a couple of different tools for retaining
good people and bringing in the larger sales figures. A#1 is Design Your Inspiration
( http://www.dyi.successories.com ), intelligent, customizable with any words or great quotes (like the AMAZING one you mention from Einstein) you want to use. Framed art photography prints.

Again, the quality of these, and the MEANING emparted makes them highly effective for me. So while the cynics shed tears in their beers,
we’re laughing all the way to the bank! Thanks again. Jim

http://www.designfulthinking.com/articles/start-design-thinking-in-five-simple-steps/

Listening to your market is a nice source to identify the correct mix of features which would ensure making of a successful product.

It becomes really important to not only identify unsolved problems of your market, but also prioritize them, before actually resolving them.

Key areas which needs to be considered while decideing which problems to solve first:

1. Does the problem require an urgent solution
2. Will solving the problem help you better your win:loss ratio
3. Are people willing to pay for you to solve their problem

I guess Product Management is the only profession which welcomes problem with both hands

In most cases those working on the problem don’t have enough information to understand or define the problem well. Most of the time they assume they do. It is important to always seek out more information. Information about the problem is the key to understanding it and defining it.

Thanks for you good ideas.

- What the ‘error bars’ associated with your definition of the current problem? Is your definition based on historical data? Was it based on unreliable interviews and stale data? What were the misinterpretations of the folks summarizing the data? What are the unknowns?

- As a product manager planning for a new product that will not be launched for 6, 12, or 18 months, what are the ‘error bars’ on your definition of the problem in the future? At launch? At maturity? How will competitive offerings change the definition? How will world conditions change the definition?

I have found the phrase ‘boardroom logic’ may apply when product management asserts that they have defined a problem. Sometimes, the accepted truthfulness of the claims increases the more the claims are repeated.

Instead of using the term ‘defined, perhaps using the term ‘hypothesis’ may frame the discussion for a higher probability of success.

Since a hypothesis is intrinsically a testable idea that may evolve after testing, there is a wonderful opportunity to collaborate with other team members and discover new insights about ‘the problem.’

The pressure to always be right can cause even the best of us to “freeze up” and not be able to make a decision. The longer we spend thinking about something, the more the pressure grows to make sure that we reach the “right” decision.

I’d add to your post a note to lighten up. Take enough time to reach what seems to be the best solution at the time. Then make sure that you keep double checking yourself as you move forward – just in case.

- Dr. Jim Anderson
The Accidental PM Blog
“Home Of The Billion Dollar Product Manager”

Too often I see problem statements that define problems customers are experiencing with a given product. That’s too narrow and misses the point of problem statements/definitions. Always think in terms of the market(s) you serve. -Michael

“The problem we’re trying to solve is X. How does this idea we’re discussing directly address that problem?” If it doesn’t, it’s a great idea, thanks for contributing, and let’s write it over here in our backlog.

When there isn’t a clear problem statement, product managers (or other leaders) often have to resort to some form of “your idea doesn’t work because I said so” – and that does no good to your organization.

I just wanted to add that it’s very helpful to have these views and stances in mind while identifying a problem. Exploring the entire spectrum of such views as they relate to the initiating problem as a whole is a helpful exercise in producing a comprehensive (correct) solution. It also helps in the understanding of what that solution does and does not do or where there may be other related or unrelated problems worth exploring.

As always, we find ourselves returning to persona-driven design and use cases, the fountain of wisdom from which all good things come. . . in the near- to medium-term.

The black art of anticipating problems remains a black art; if I could articulate how to do it, I certainly wouldn’t as it is as powerful a competitive (and personal) advantage as exists in our trade/craft/profession.

Well, maybe I would if someone asked nicely, and bribed me with ham.

BTW – Great topic, Jeff – thanks for writing it up. You St. Louis guys are OK. And good idea to advertise it on Twitter.

bob

Am I on fire? Roll on the ground. Get in a cold shower. Call 911.

Will I soon be on fire, run like hell, let the place burn down, but get out unscathed.

Might this place burn down, think about egress and fire suppression, spend the money to implement the preventative measures.

These examples illustrate the time stances: reactive, predictive, and proactive. These examples illustrate how the time stance controls the solution. These examples illustrate how getting to the proactive stance is important.

The EMS shows up, and you don’t have your medical insurance card, so off to the country hospital you go. Then, how will your family find you? No cell phone.

Ok, you’re across the street, now you have to call 911, no cell phone.

You are asleep in your bed dreaming of another wonderful day solving problems at the office. Actually, you never have problems at the office.

These last three examples continue the earlier examples. In the first example, the real nature of reactive problem solving reveals itself. There is always another reactive problem to deal with. The predictive situation eventually diminishes into a proactive problem. And, the proactive stance can successfully eliminate the follow on problems entirely.

Again, get proactive as soon as possible. Rushing is contrary to this goal.

As a product manager, you won’t see the opportunites if you are constantly putting out the fires.

Good post. How the problem is cast will directly influence the solution. Scott Berkun talks about this in The Myths of Innovation. The example he gives comes from Scott Cook, founder of Intuit, the makers of Quicken. Cook realized that the greatest competitor wasn’t other software programs, but the pencil. Reframing the problem in this way (i.e., to compete with the pencil) allowed them to develop one of the most widely-used personal finance software packages out there.

Have a look at Chapter 9 of Berkun’s book.

Also, from a designer’s perspective, defining the right problem is critical. In an interview with Peter Merholz, Don Norman suggests that defining the problem one of the most important parts of the design. Don says in unequivocal terms:

“Do not solve the problem that’s asked of you. It’s almost always the wrong problem. Almost always when somebody comes to you with a problem, they’re really telling you the symptoms and the first and the most difficult part of design is to figure out what is really needed to get to the root of the issue and solve the correct problem.”

http://adaptivepath.com/ideas/essays/archives/000862.php

Cheers