Thursday, September 03, 2009

Product Talks #4: Balancing Commercial Initiatives with User Experience Concerns

I will be in Sydney, Australia in early November to facilitate the fourth installment of brainmates' Product Talks. The conversations will focus on the challenges of balancing commercial initiatives with user experience concerns. A copy of the media release follows:

Raising the Bar on Product Management Excellence

brainmates is inviting Product Management specialist, Roger L. Cauvin, to Australia this November to lead public and client events in Sydney, offering his expertise and fresh perspectives in Product Management to local corporations.

Cauvin will be facilitating brainmates fourth Product Talks session, a free quarterly forum that brings together product and marketing professionals to network and discuss issues in contemporary Product Management. Cauvin will lead conversations on ‘Balancing Commercial Initiatives with User Experience Concerns’ on November 5th at brainmates’ office. Registration is required to attend Product Talks events.

A selection of brainmates clients will also be hosting special roundtable events with Cauvin. Product teams will have the opportunity to broach specific Product Management concerns they want to resolve and gain sound advice and new solutions from his Product Management experience and work in the United States.

The series of events are a part of brainmates corporate initiative to build a solid foundation for the Product Management profession in Australia.

In addition to being the principal consultant of his own company, Roger L. Cauvin is the owner and operator of Dadnab, a successful text messaging service for transit planning in the United States. Cauvin also helps manage ProductCamp in Austin, Texas, the American version of brainmates Product Talks.

brainmates continues to invest and promote Product Management excellence and innovation in Australia through their services, events and resources.

For more information contact Adrienne Tan on (02) 9232-8147.

Monday, August 24, 2009

Strategy and Pragmatic Marketing's Framework

Pragmatic Marketing has a framework for creating and marketing successful, market-driven products. A grid familiar to many product managers and marketers depicts an overview of the framework:

The left side of the grid shows the more strategic marketing activities, while the right side of the grid shows the more tactical marketing activities. On the far left side of the grid, we find research activities such as understanding market problems, the competitive landscape, and distinctive competence. On the far right side of the grid, we find presentations and demos, sales or other "special" calls, and event and channel support.

The grid is an enormously useful tool for finding the gaps in your company's marketing efforts. Most of us who have taken Pragmatic Marketing classes know that most companies are severely deficient in the left side of the grid. They either have no coherent strategy or have developed strategies without a thorough understanding of the market.

Does your company have a marketing "strategy gap"? Here are some questions to ponder:
  • Has anyone at your company interviewed (not on a sales call) a broad cross-section of prospective customers one-on-one about the challenges they face?
  • Is there a shared understanding in your company of the top three problems your product solves in the marketplace?
  • Has anyone at your company conducted win/loss analysis, with someone other than a sales person interviewing prospects who opted to buy or not to buy your product?
  • Is there a shared understanding of the strengths and weaknesses of each competing product as they are perceived by prospective customers in the market?
  • Has someone identified, and is there a shared understanding of, a competency that sets your company apart from all of the competition and gives your company a unique and sustainable ability to deliver value to prospects in the market?
If you answered "no" to any of these questions, then you have gaps in the most fundamental strategic aspects of your product development and marketing efforts.

Wednesday, June 10, 2009

Why Product Management Interviews Suck

Before becoming a product manager, I was a software engineer for about eleven years. During my career as a software engineer, I interviewed for many different positions and many different companies. Some of the companies had perfected their interview process; they employed such methods as:
  • Analysis and design sessions
  • Coding quizzes
  • Design pattern questions
  • Development process question/answer sessions
The candidate's performance during each segment was fairly objective and straightforward to assess, and hiring managers felt confident that a candidate would excel on the job if she performed well. Any software engineering "rock star" felt confident that she would come close to acing these exercises and quizzes.

Now, as an experienced product manager having recently interviewed at various companies, I'm struck that 95% of product manager interviews yield almost no useful or reliable information for assessing how well the product manager would perform on the job.

Unfortunately, most interviewers concentrate on broad and fluffy questions about previous experience but don't probe into what methods and principles a candidate employs to make key decisions as a product manager. In particular, notably absent from these interviews have been such tools as:
  • Requirements elicitation exercises
  • Product positioning exercises
  • Quizzes on product management principles, methods, and concepts
  • Product management process quiz (or Scrum quiz for companies that practice it)
In fact, the only quiz on product management I've ever seen is the one that Pragmatic Marketing uses for its certification exam. (Seilevel has a somewhat rigorous set of exercises and questions in its interview process, but it focuses more on product specification than on product management.)

If you're hiring a product manager, try creating a rigorous set of tools for assessing how well a candidate knows product management. You'll not only make better hiring decisions, it will help build a better understanding of why you're hiring a product manager in the first place.

Sunday, March 01, 2009

Agile Is Not Just a Development Methodology

Recently, several of my favorite bloggers have debated the role of product management in agile product development:
You'll find my thoughts dispersed throughout some of the comments in these blog entries.

If you're an executive interested in the debate, here's what you need to know.

First, read a blog entry I wrote in June 2005 entitled "Agile Product Management". In it, I lay out some of the basics of waterfall and agile methods.

Second, read a blog entry I wrote in September 2005 entitled "BUFR". In the entry, I contended that the two main causes of problems with waterfall methods are big up-front design (BUFD) and big up-front requirements (BUFR).

Third, note that the most important set of problems that agile methods overcome stem from BUFR, not just from BUFD. Arguably, this realization renders agile more directly important to product managers than to developers.

An agile product manager works in a fundamentally different way with both developers and customers. It's not just a matter of how and at what pace the requirements are delivered to developers. It's also how the requirements are elicited.

An agile product manager doesn't just interview and observe customers to understand their problems. She involves customers in an iterative feedback loop by "releasing" preliminary versions of the product to them. This feedback loop provides a way of eliciting requirements after implementation has begun but well before the product is officially released into production.

It's unfortunate that the term "agile" originally applied only to development. If you look at agile product management as merely something that a product manager does to co-exist with agile development, then it does seem silly to adopt (or co-opt) the buzzword.

But it turns out agile doesn't just enable developers to design and implement code more efficiently and reliably. It also enables product managers to understand their markets more efficiently and reliably.

So the popular notion that agile methods help developers, and that they therefore need product managers to cooperate, has it backwards. The opposite notion is equally, if not more, valid. Agile methods benefit product managers, and they need developers to fall in line to enable agile product management.

Thursday, January 22, 2009

What's Wrong with Product Management?

Over at the On Product Management blog, Saeed asks us to complete a brief survey on what the biggest problems are in technology product management.

I answered roughly as follows:

Q1. What do you see as the biggest problems facing the technology product management profession today?
  1. Too much tactical activity in the absence of sound strategy.
  2. The lack at most companies of a skilled interaction designer or user experience professional role.
Q2. What solutions would you suggest to address these problems?
  1. Educate executives about the importance of strategy and how to best determine it.
  2. Hire skilled interaction designers or user experience professionals.
Q3. Which of the following best describes your role/department?
Product Management

Sunday, January 18, 2009

Value-Based versus Cost-Based Pricing

Over on the Accidental Product Manager blog, Dr. Jim Anderson writes that cost-based pricing of a product is a bad idea, and that value-based pricing is the way to go.


Cost-based pricing and value-based pricing are two different ways a product manager can decide on the price of a product.

A cost-based price is the cost of producing a unit of the product plus a certain margin. For one example of applying cost-based pricing, see Adam Bullied's blog entry on the pricing new products.

A value-based price reflects the value of the product to the customer. The way I suggest pricing a product based on value is to use negative pricing.

Dr. Anderson points out that price and volume have mutual feedback effects:
Since your unit cost is changing with volume, your price will determine how much you sell. This will then impact volume which then impacts unit cost.
As a result:
So what’s wrong with cost plus pricing? Simple - cost plus pricing will cause you to over-price your product when there is a weak market and will cause you to under-price your product when there is a strong market.
Let me try to reconcile some of the conflict between the two approaches.

The goal that both approaches have in common is to maximize profit. Maximizing profit means finding the ideal balance of margin and volume.

With cost-based pricing, your product manager tries to find the right margin but can also take the impact on volume into account. The hazard is that all the variables are dependent, and maintaining positive margin may result in such small volume that the product isn't profitable.

With value-based pricing, your product manager uses knowledge of the competition and the urgency of the problems being solved to determine the price of the product. A product that addresses urgent problems that the competition doesn't address merits a high price. The hazard is that the value-based price of the product may not cover the costs.

It's fairly straightforward to conclude that there has to be some convergence of the two approaches. Whether it's you, your product manager, or another person in your company, someone has to project the costs and compare them to the value of the product to the customer. This analysis is part of determining whether the product is worth developing in the first place.

Either way, pricing is often an iterative process. Initial research into the market and your projected costs will almost certainly be incomplete or off target. By "testing" prices in the market, your product manager will gain further insight into what the product's true value is to the customer.

Monday, January 05, 2009

Two Approaches

Back in November, Seth Godin wrote about a frustrating experience almost all of us have shared. You call customer service, navigate a long sequence of touch-tone prompts, only to be informed that the office is closed. In Godin's case, he endured nine prompts.

If a typical product manager or business analyst presided over the development of this telephone navigation system, I can imagine how it went.

"Let me talk to your subject matter experts (SMEs)."

"What are the departments a customer might need to contact?"

"Let's draw a chart showing the different paths through the phone system."

Contrast this approach with the following focus on real requirements. The product manager or business analyst converses with customers and customer support to understand the problems that they are trying to solve and avoid by calling support. The problems don't just include the reason they call support in the first place. They also include potential problems with support itself.

Among the problems that customers want to avoid are:
  1. Spending a long time to resolve an issue.
  2. Expending a lot of energy (by pressing a lot of buttons or having to talk a lot).
Armed with knowledge of true customer challenges, the product manager or business analyst formulates metrics corresponding to these problems:
  • It shall take an average of no more than X seconds for a customer to resolve issue Y.
  • Outside of support hours, it shall take no more than X gestures (button presses, voice commands, etc.) for a customer to be informed that the office is closed.
These metrics are off the top of my head and no doubt could use some refinement. But the point is that the frustrating customer experience Godin described is a result of a requirements failure, a failure to understand and formulate in measurable terms the problems the customer wishes to solve and avoid.