What Is Buying Facilitation®?

Believe it or not, prospect problems and product positioning play only a small part in customers' decisions to purchase or use your product. The majority of obstacles to product adoption lie in the behind-the-scenes decision-making processes that people and organizations face.

It's true I've dedicated many entries on this blog to pointing out that, to market and sell a successful product, you must develop it so that it:

1. Solves problems that prospective customers face.
2. Captures or "owns" a compelling position in the mind of the prospective customer.

Many, if not most, products fail on both these counts. I've explained how the best product managers acquire market understanding and apply marketing principles to address these issues. Nonetheless, even products that solve problems and are well positioned often fail, because buyers weren't able to deal with change management issues that precede the purchase of a product.

Prospects wishing to purchase and use your product face resistance from internal stakeholders, buying processes that are burdensome and bureaucratic, and entrenched ways of doing things that a new product would disrupt. Why on Earth would a prospective buyer subject herself to all these risks and frustrations?

In short, sometimes the buying decision process is so cumbersome and politically difficult that buyers choose not to make a change or purchase. More business is lost to "maintaining the status quo" than is lost to competitive offerings. For a prospective customer, continuing to live with the status quo is often a much more appealing option than slogging through the pain of a buying decision and changing the way they do things.

If we concentrate solely on solving problems for customers and positioning our product in the market, we ignore the most important obstacles to product adoption.

Sharon Drew Morgen tells us how to pave the way for customers to buy and use a new product: Buying Facilitation®. I include the ® symbol because Sharon Drew coined the term and has registered it as a trademark. (At this point, you're thinking that you already know what Buying Facilitation® is, and that you're already doing it. Not likely. When I first began to learn about it, I mistakenly thought I was already doing it. By the way, Buying Facilitation® is not the same as SPIN selling or interviewing prospects.)

Buying Facilitation® is an addition and complement to conventional selling that helps buyers address the change management issues preceding any purchasing decision. It does so by helping them to deal with behind-the-scenes internal politics, processes, relationships that they will inevitably have to confront. While sales does needs assessment and product positioning, Buying Facilitation® comes before these activities and requires a different skill set.

We, sitting on the outside of each individual buyer's unique system, will never fully understand their buying decision processes and challenges. But with Buying Facilitation®, we apply a new set of skills to guide them through the steps they will have to follow to address the change management issues, before considering the pros and cons of our product. As Sharon Drew says, we play the role of "neutral navigator". Before buyers can purchase, they must get internal buy-in. They will do so with or without us. We can play a part by applying the new set of change management skills Buying Facilitation® embodies.

Using facilitative questions, Buying Facilitation® helps buyers:

1. Identify the stakeholders that must buy into any purchasing decision.
2. Identify the individuals, departments, and processes that a new solution would affect.
   
3. Decide if they really need a new solution or can manage a workaround using convenient choices.
4. Manage the relationships, internal politics, and historical baggage they will face as they seek buy-in.
   
5. Formulate a plan to talk to internal stakeholders and assemble a buying decision team.
   

Sharon Drew's latest book, Dirty Little Secrets, has some great examples of the types of change management questions we may ask as we navigate prospects through their buying decisions:

• "Can you tell me how you currently get your site designed and administered?"
  
• "How will you know that it would be viable to use an outside vendor when the current tech team has historically done all of the site design?"
• "What will the disparate groups need to know or understand to decide to work together?"
  
• "What will your CFO need to reconsider or know in order to allow in a new vendor when one of her reports is the tech manager?"
• "How will you know that the historic issue can teach us how to avoid the same problem as we move forward?"

We ask these questions not to get the answers for ourselves, but to stimulate and help the buyer to find the answers she needs. In her training classes, Sharon Drew teaches the sequence of questions, which depends partly on the buyer's specific circumstances. (Incidentally, she is holding small public training programs on Buying Facilitation® in Austin and Boston this September.)

By playing the "neutral navigator" role, we become a trusted adviser. Since we've helped the buyer navigate painful buying decision and change management issues, they are likely to include us on the buying decision team (as long as we stay neutral and focus on change management rather than sales). They may even choose our product automatically when they are ready to buy.

The person employing Buying Facilitation® is often someone resembling a sales person, but with an important new set of skills. How do you think product managers can incorporate Buying Facilitation® concepts?

[UPDATE: Here is Sharon Drew Morgen's legal definition of "Buying Facilitation®":

Buying Facilitation® designates very specific set of systems-based skills that help buyers (and anyone) navigate through the full range of their behind-the-scenes change management and decision issues – usually not need- or solution-related but based on internal relationships, politics, rules, etc. necessary for change: pre-purchase, pre-needs assessment, pre-solution choice…pre sales.]

Provide the Shortest Path

Trying new things - especially new software products - can be both intimidating and time consuming.

You face a challenge when introducing a product in the marketplace. The forces of nature are working against you, since almost everyone but "early adopters" resists trying new products.

A major reason people resist trying new products is the learning curve. People simply don't have the time or patience to wade through pages and pages of documentation just to figure out what a product does, envision what it's like to use it, and how it would disrupt the way they live their lives.

One thing you can do to minimize this obstacle to adoption of your product is to provide the shortest path. Providing the shortest path means minimizing the time and effort necessary for a first-time prospective user to obtain demonstrable value from your product.

To provide the shortest path, you do some combination of the following:

1. Make available a "quick start" guide that a prospective user can read in under ten seconds and get a feel for how she would use the product.
   
2. Provide a demo (or full-fledged product) that enables first-time users to accomplish their primary goals with almost no time or effort.

Your product manager can drive this effort by defining personas and usability requirements relating to first-time users.

Henry Ford's "Faster Horse" Quote

You may have heard the Henry Ford quote:

If I'd asked customers what they wanted, they would have said "a faster horse".

Over at the On Product Management blog, Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations.

Personally, I think the quote is great, but it's a matter of interpretation.

The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are:

1. You must ask the right questions to get valuable answers.
2. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information.
3. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.)

Nonetheless, I find the quote is helpful to combat "armchair product management" in the product development organization. You probably know the drill. An engineer, sales person, or executive insists on a feature and justifies it by saying that many customers have requested it, as if no deeper analysis is necessary to determine whether we should add the feature to the product.

But in our conversations with customers, we shouldn't be focusing on features. We should be striving to understand the problems they face. They are not experts on the features or solutions; they are experts on their experiences and challenges. If we ask them what they "want", they are likely to think of solutions and short-circuit the all-important understanding of the problems they face.

The Henry Ford quote is a stark and simple falsification of the notion that a direct poll of customers is sufficient to draw conclusions about features. We should not use the quote to dismiss the importance of listening to our market., however.

Getting Feedback on Usability

It's common for people at all levels of a company, and in all company departments, to comment on the usability of the product or company web site and give suggestions on how to improve it.

Why? Here's a clue. I wrote in late 2005 that:

Most people, including executives, consider much of marketing to be common sense. We're all consumers, so we all know how we respond to products, names, logos, advertisements, and PR, right? So we're all experts on what works in marketing, no?

Wrong. See the original blog entry to learn why marketing is not common sense.

The same principle applies to usability. In playing the role of consumer in many aspects of our lives, we use products and web sites, and we know which ones are usable - and perhaps even what makes them usable - right?

Wrong. Just as marketing isn't common sense, usability isn't common sense, and for the same reasons.

Nonetheless, debates over usability and strategies for redesign can get quite contentious and time consuming. Even if a company is smart enough to have skilled interaction designers and user interface designers, the designers are often caught in the middle, but their expertise ignored.

There is a way of resolving these questions: a product manager frames the usability metrics and conducts tests on representative users to measure the usability of the current and proposed designs.

Unfortunately, many team members still have a bit of "overconfidence" in their ability to conduct this testing themselves. For example, a favorite idea of executives is to form a focus group, ask members of the group questions about the designs, and possibly ask them for design suggestions. Good product managers and usability experts know this approach is flawed.

Usability guru Jakob Nielsen tells us why usability testing is not as straightforward as the average company employee or executive may think:

The way to get user data boils down to the basic rules of usability:

• Watch what people actually do.
• Do not believe what people say they do.
• Definitely don't believe what people predict they may do in the future.

Good product managers know how to elicit, gather, and interpret usability feedback, because by definition they know how to facilitate market input and draw appropriate conclusions from it.

Costs of Launching a New Brand

Reading Al Ries and Laura Ries' War in the Boardroom, I took particular note of the following excerpt (page 36):

[A] left brainer at a smaller company thinks, "We can't afford the costs of launching a new brand. So let's use our existing name. Furthermore, we already have some good consumer recognition. With a new brand, we'd have to start all over again. We don't have the resources to launch a new product and a new brand at the same time, nor is it necessary to launch a new brand."

The authors ridicule this line of reasoning, which is unfortunately common even among marketing professionals. The authors counter that successful product strategists:

1. Strive to create a new product category.
2. Create a new brand to stand for that category in the mind of the customer.
3. Keep the brand focused on that one category.

In the short run, creating a new brand may be more expensive. But in the long run, trying to "stretch" a brand name to stand for more than one category is even more expensive.

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.

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.

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.

Agile Is Not Just a Development Methodology

Recently, several of my favorite bloggers have debated the role of product management in agile product development:

• Adam Bullied asked if the notion of an agile product manager is baloney.
• Enthiosys argued that agile does and should change how product managers do their jobs.
• Saeed argued that agile only need affect product management incidentally and at the margins.
  

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.

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

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.

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.

ProductCamp Austin Winter 2009

You may know that Austin led the global product management community in holding the first ProductCamp. About ninety product management and other professionals spent a Saturday in June in the air conditioned comfort of the St. Edwards Professional Education Center. ProductCamp is like BarCamp, an informal conference in which professionals meet to share ideas about technologies, tools, and practices.

I'm pleased to announce that Austin's second ProductCamp is taking place in January. We are expecting over 175 of Austin's most talented product management, marketing, and product development professionals to attend. This time the event will be at the UT College of Communications building.

WHAT: ProductCamp Austin
WHEN: January 24, 2009
WHERE: University of Texas, College of Communications CMB Building (Studios 4B-4E)
201 W. Dean Keeton St.
Austin, Texas 78712

For more information on the event, or to sign up to lead a session, visit the wiki. Register for free here.

Pragmatic Marketing, Austin Ventures, UT, NetQoS, and Troux Technologies have already signed on as sponsors. If your company is interested in being a sponsor, please contact Bertrand Hazard.

Brands and Categories

Laura Ries makes two primary points in her recent blog entry:

1. If your product is innovative or the established brand leader, it should own not just a word or idea in the mind of the customer, but should also "own" the category itself. I.e., customers and prospects should equate or strongly associate the category with the product.
2. If your product owns a dying category and you introduce a new product in new or healthy category, don't put the new product under the same brand umbrella. Instead, create an entirely new brand.
   

Some choice quotes:

[L]eaders many times become the generic for that category. The brand becomes a short-hand device for talking about and asking for a particular category.

Kodak is not in trouble because people don't love the Kodak brand anymore. Kodak is in trouble because people don't use conventional film cameras anymore. Moving Kodak to the digital category makes no sense at all.

When your brand owns a category in the mind and your category is in trouble, you need to launch a new brand. You can't save your brand by moving it to a new category.

Ries' entry, as usual, contains many examples to demonstrate her points.