Top 5 Prospect Interview Mistakes

One invaluable tool that product managers use to understand markets is the prospect interview.  We identify prospective buyers and users who may share a common set of problems, and we conduct one-on-one interviews with them to probe their situations and dig deep into the challenges they face.  The situations and challenges inform our product strategy and decisions.

If you're a company executive, you may be reluctant to empower your product managers to conduct interviews with prospects, as what happens during these interviews could potentially jeopardize a future sale.  Even if you have confidence in your product managers not to jeopardize a sale, you may view prospect interviews as a dubious way of gaining market understanding.

Rest assured that prospect interviews will tend to foster trust and enhance future sales possibilities while providing a richer understanding of the market.  But only if product managers conduct them properly and avoid certain pitfalls.

The top five mistakes product managers make when conducting prospect interviews are:

1.  Pitch the product.

The biggest no-no when conducting a prospect interview is to attempt to sell the product or pitch its benefits.  It immediately puts the prospect on the defensive and undermines the purpose of the interview, which is to understand the prospect.  It communicates to the prospect that you think you already understand her needs, without even having probed into her unique circumstances.  You're effectively telling her what she needs instead of determining what she needs.

2. Ask the prospect what they want.

If, during our conversations with them, we focus on what prospects want, we distract them from what we really need to understand.  We need to guide the conversation to the situation and challenges they face, not to what prospects think they want.  Once we understand what problems they face, and choose which ones to solve with our product, our team of design and implementation experts can come up with the innovative solutions to those problems.

3.  Ask the prospect to design the product.

As a general rule, prospects are not experts in designing solutions to the problems we may choose to solve for them.  If they were, they probably wouldn't need us or the products we develop.  With a product manager's skilled facilitation, however, we can work with prospects to uncover their problems.  In some cases, it may be beneficial to "co-create" the product with prospects or customers, but a prior investigation and mutual understanding of what problems to solve is a prerequisite.

4.  Ask hypothetical questions.

"How much would a product that does X, Y, and Z be worth to you?"  "How many times per day would you use feature X of our product?"  These types of questions are hypothetical and generally yield little useful information.  Prospects don't know what they would do.  They know what they actually (currently) do.  Conclusions extrapolated from what prospects actually do are often more reliable than direct answers to hypothetical questions.

Some hypothetical questions are necessary and useful.  In general, however, try to rephrase hypothetical questions as factual questions that give you insights into the patterns likely to guide prospects' future behavior.  For example, instead of asking how much they'd pay for a product, determine how much it costs them not to use your product.

On a related note, be careful with direct questions.  A direct question isn't open ended; it makes assumptions that may not be valid and ignores other possibilities that might be important.  Start with open-ended questions to allow for answers you can't anticipate and delve into more direct questions only after you've given the prospect an opportunity to introduce unanticipated topics and concepts.

5.  Ignore change management issues.

No matter what problems a prospect faces, and how much it costs his organization, the problems are usually nestled comfortably within a system that's resistant to change.  Explore these change management issues with the prospect.  Determine the people and processes tied to the problems the prospect and the organization are facing.  Use Buying Facilitation® to determine change management issues that would precede any purchase or attempt to adopt a new solution.  Standing outside the prospect's system, you will never be able to understand all of these issues, but you'll get a more complete picture of the prospect's situation and challenges if you stimulate her to consider the system in which they occur.


In many organizations, it can be an uphill battle for product managers to talk to prospects outside of a sales call or presentation.  Consequently, product managers who do manage to interview prospects feel a sense of accomplishment and confidence in their market understanding and product decisions.  However, this confidence can be misplaced if the product manager has made these common mistakes when conducting prospect interviews.

Who "Owns" the Product?

Recently, I've noticed a number of product managers on social channels claim that product managers "own" the products they manage.  On the surface, this claim seems rather innocuous and uncontroversial.  But the claim bothers me, for several reasons.

Let's examine why anyone would make such a claim.  I can think of a few reasons.  (I'll get to the notion of "product owner" in agile development later.)

First, a single point of accountability simplifies how we conceptualize the product management role.  It's understandable that product managers are tempted to find a simple definition of product management.  The responsibilities of the role vary greatly across different companies, and few people can articulate concisely what a product manager is or does.  So it's nice to boil it down to ownership of the product.  But what does it really mean to own the product?

Second, many folks in the product management community are familiar with the debate about product management "authority".  Product managers typically lack formal authority but assume much of the responsibility for the output of the product team and for the ultimate success of the product.  Perhaps some product managers believe that, if we convince executives and team members that we "own" the products we manage, they will grant us the authority to make product decisions that stick.

For example, if the product manager disagrees with a user experience (UX) designer on the team about a design decision, the product manager can "overrule" the UX designer's recommended approach, since somehow the product manager's ownership of the product trumps the UX designer's design expertise.  I don't subscribe to this authority-based model, and I doubt product "ownership" does much to support it in practice.

Third, the other side of the product management "authority" debate believes in the romantic notion of leadership as unilateral self-empowerment with little or no enablement from others.  Under this view, product "ownership" implies that the product manager steps up to take full responsibility and accountability for the success of the product despite the lack of formal authority.  It's a statement of confidence and sometimes derision towards those who complain about the lack of formal authority.  Yet this view rests on a naive and overly simplistic view of leadership, as I have argued before.

But the practical reason you should reject the notion of product management "owning" the product is that it undermines one of the key determinants of product success.  The most successful product teams possess a culture in which the team owns the product.  Each member of the team - whether a developer, sales person, marketer, support specialist, or tester - has strengths and plays roles that contribute to the team effort, and ultimately to market acceptance and product profits.  They all feel accountable for the success of the product and the team, and there is no need for a "single throat to choke".  This form of accountability is a highly effective motivator and yields impressive productivity and outcomes.

A product manager's unique role on a team is informing the strategy that drives all the team's product decisions.  She does so by leading the process of eliciting and sharing market knowledge and applying marketing principles to form the basis for sound product decisions.

Finally, no discussion of "product ownership" would be complete without a note about the use of the term "product owner" in agile development.  The original use of the term referred to a person on the team who could serve as a proxy to the customer or market.  It wasn't someone who was solely responsible or accountable for the success of the product or project.  Originally, it wasn't even someone who necessarily had tactical "backlog management" responsibilities.  No, it was mostly a role that helped inform the team's requirements decisions from a customer and user perspective.

A product manager's role is a bit broader than agile's original notion of product owner, in that a product manager's insights and perspectives drive not just requirements, but positioning and messaging as well.

Join Me at ProductCamp Austin 7

Join me Saturday, August 6th, 2011 for ProductCamp Austin 7.  ProductCamp is an "unconference" where  product management and marketing professionals teach, learn, and network.

Along with a team that included John Milburn, Scott Sehlhorst, and founder Paul Young, I attended and helped organize the first ProductCamp Austin.  This time, assuming our proposed session makes the cut, we'll be leading a panel discussion on the future of product management.

You've heard the traditional challenges product managers face (basing product decisions on market problems, leadership without formal authority, getting buried in tactical tasks).  But product management has grown up, and there are new challenges we face.  What is the future of product management, and how will it address these new challenges?

Austin's "Gang of Four" product managers will lead an interactive conversation on such topics as:

1.  We've gone agile.  Do we still need product management?
2.  Will product managers join the executive ranks?  (CPO = Chief Product Officer)
3.  Will product managers embrace cutting edge "lean startup" and "customer development" processes?

What do YOU think the future of product management holds?

WHAT: ProductCamp Austin 7
WHEN: August 6, 2011 from 8:30 AM to 4:30PM
WHERE: AT&T Conference Center @ 1900 University Ave., Austin, TX 78705
COST: Network, volunteer, pitch a session idea, or just make new folks feel welcome.

You must register (free) to attend.

You can get transit directions to the event by visiting the Capital Metro trip planner and filling in your starting location.  If you choose to drive, parking is available for a fee in the AT&T Center underground parking lot.

An Epic Conversation

The following is a fictitious example of the type of conversation that could occur at many organizations claiming to use agile development methods.

Joan is the VP of engineering at Trendy Startup, a rapidly-expanding company developing a suite of cloud storage products and services.

Joan's organization uses the popular scrum development process to develop its products. Product managers and owners create user stories, allocate them to iterations and releases, and manage them in backlogs.  Quality assurance (QA) engineers write tests for the user stories, and developers implement the user stories.  Team members meet daily to review the previous day's accomplishments, agree on what they'll do today, and surface any obstacles they are facing.

Joan is proud of her teams and their adoption of agile methods and practices.  She touts the Trendy Startup's development processes to her fellow executives and to prospects and customers.

All members of her product teams have embraced agile methods, but two of her independent-minded engineers, Raquel and Oscar, are frustrated and have begun to question the results. They decide to meet with Joan to discuss their concerns.

Joan: "What's up, Raquel? Oscar?

Raquel: "We're concerned about our development process at Trendy Startup."

Joan:  "Raquel, you know we're an agile shop. It's important that we all buy into agile practices, and frankly I don't think there's a place in our company for engineers who can't fit into agile teams."

Raquel:  "Oh, I have no problem with agile methods. My concern is that I don't think we're really doing agile."

Joan: "Hmm. I'm not sure what you mean. We've adopted all the major practices, haven't we?"

Raquel: "Sort of. But what we call 'stories' are really just development tasks. We're not defining acceptance criteria for our user stories. And our product roadmap is oriented around features instead of what really matters to users."

Oscar:  "Exactly! I'm frustrated because we seem to be losing sight of delivering value to customers. I actually don't care whether we are doing 'theoretically pure' agile, but we've gotten too far in the weeds."

Joan: "Ultimately, we can't deliver value to customers and be successful in the market without dealing with the details; things like font sizes, the positions of buttons and other user interface elements, and even grammar."

Oscar: "Of course. But we need to tie these details back to the larger picture of what the user is trying to accomplish as they are exposed to these details."

Raquel: "Right. That's part of what I mean about not doing agile properly. Many of the stories in our backlog are development tasks to 'move the Cancel button two pixels to the left'. But there is no tie-back to a real user story, which should state what the user wants to do and why she wants to do it."

Oscar: "I would go even further. Even when we do have real user stories, I sometimes lose sight of the big picture."

Raquel: "Good point! We've made some attempts to group user stories under features, but that's not how Mike Cohn says to do it. Cohn says to use epics and decompose them into user stories."

Joan: "But we do use epics. We group our user stories into epics such as 'asynchronous storage' and 'cloud infrastructure'."

Raquel: "But those aren't real epics! A story is a narrative. An epic is a long narrative. Look them up in the dictionary! In agile, a story is a placeholder for a narrative that achieves users' goals, and an epic is a placeholder for a longer, end-to-end narrative that captures and implements the larger goals of the users and buyers."

Joan: "Okay, I have to draw the line here. This organization doesn't care what the real definition of 'epic' is. We're not employing poets or novelists here. And in the final analysis, it doesn't matter whether we're doing what some purists think is agile. We care about producing quality software that will sell in the marketplace."

Oscar: "I couldn't agree with you more on those points, Joan, but I think Raquel has hit on precisely why the team loses the user perspective. Users care about what they're doing and what their goals are, not about 'asynchronous storage'."

Joan: "What would you suggest as an alternative? Can you provide an example of what you consider a true epic, Raquel?"

Raquel: "Here's one: 'As a gadget guy, I want to view and edit my documents from any device connected to the Internet so that I'm not dependent on any particular device for access.'"

Joan: "Okay, that seems to capture succinctly what the user wants to do, and the overarching value of our suite of cloud storage products. Your concerns are starting to become more concrete for me. Raquel, how do you suggest we modify our agile process to address these concerns?"

Raquel pulls up the following diagram from a Mike Cohn presentation on user stories.

Raquel: "Let's make sure we include real epics in our portfolio and product roadmaps.  Let's decompose epics into user stories and include the user stories in our backlog. When we need to split a user story to fit into an iteration, our first instinct should be to split it by iteratively strengthening the acceptance criteria, not always by decomposing it along functional lines. All development tasks we include in the backlog should reference the user stories they support.  Also, let's follow Mike Cohn's template for epics and user stories to ensure they are understandable to users and are verifiable. We can also group stories according to themes, but let's make sure the themes tie back to prospect problems."

Oscar: "Works for me! I really like the idea of epics standing for lengthy, end-to-end stories. They really tie everything together to show the value to customers and users in such a way that I, as a developer, can see how the details fit into the big picture.  As a matter of fact, I've noticed a recurring pattern we could employ."

Oscar proceeds to draw the following diagram on Joan's whiteboard.

Raquel: "Pretty cool, Oscar. Your diagram shows a decomposition of an epic into smaller strories.  The epic encompasses what the user ultimately wants to do and the unfortunate - but often necessary - system interactions that administrators must perform behind the scenes to enable the true value for end users. You've divided what we would need to implement into chunks our product owner could put in the backlog and our developers could complete in a single iteration. At the same time, none of the individual user stories by itself delivers what the end user needs. The top-level epic captures all of the stories playing out and satisfying the end user's needs."

Joan: "Now that you've explained them, these ideas make a lot of sense to me. We need to make this a team conversation and decision. I will fully support your starting this conversation with the team and proposing your ideas. I suggest a series of 'brown bag' lunches to discuss our process and possible modifications to it. Let's set the expectation that no decisions will be made at these lunches, but through open sharing of ideas and perspectives, we'll naturally converge on some improvements to our processes."  

Debunking Leadership Myths

Typical Conversation Between Product Managers

Many conversations about product management and leadership have taken place in the blogosphere and Twitter.  The typical exchange goes something like this:

Product Manager 1:  "Product managers have a lot of responsibility but no formal authority."
Product Manager 2:  "Authority is something to be earned, not granted."
Product Manager 1:  "But developers and sales don't listen to me, because they don't report to me and are in different departments."
Product Manager 2:  "Great leaders work with cross-functional teams."
Product Manager 1:  "Yes, but I don't get any support from executives when I work across departments."
Product Manager 2:  "You shouldn't need support if you are a great leader."

Leadership Myths

Let's put to rest the two opposing leadership myths that underlie these types of exchanges.  The opposing myths are:

1. A great leader's effectiveness comes from authority.
2. Great leaders are largely self-empowered and require little or no help to influence others and be effective.

Some people believe leaders are granted authority.  Other people have a romantic model of a leader as someone who, with little or no help, achieves great things and influences and earns the respect of others.

Both of these notions of leadership are ill conceived.

What is Leadership?

On page 12 of Becoming a Technical Leader: An Organic Problem Solving Approach, Gerald M. Weinberg defined an organic model of leadership:

Leadership is the process of creating an environment in which people become empowered.

A person can lead in many ways – by fostering a shared understanding of problems the group will solve, by organizing and putting supportive structures in place, by motivating others, by stimulating or managing the flow of ideas, and in some cases by acting unilaterally.  In almost every case, the leadership manifests itself in enabling or helping others.

But guess what – leaders also need empowerment. They need help. In fact, one great talent of many leaders is that they know when and whom to ask for help.  Indeed, Weinberg wrote on page 261:

People become leaders thinking they will help other people.  Before long they realize that it's they who need help.  They need help to see themselves as others see them, to carry them through their mistakes, to learn about other people, and to deal with the frustrations of trying to be helpful.  The only way to learn to be helpful is by learning to be helped.

A great leader may appear completely ineffectual in one environment yet masterful in another environment. The difference lies in how supportive and empowering the environment is for the leader.

Product Management Leadership Challenges

The formal authority that most product managers lack may not limit their leadership, but the lack of formal authority often reflects a disempowering environment.

Most people – executives included – don’t fully understand the product management role.  They don't recognize that product managers need to be like therapists to understand markets.  They aren't aware that marketing principles tend to defy common sense.  In a work environment where executives and fellow employees don't understand the role and what it means to be effective in it, product managers receive limited support.

At this point, if you still believe in the romantic model of leadership (the one in which great leaders don't need support from others), you think this description of product managers' situation is just whining.  Why don't product managers just "buck up" and overcome this situation?

To overcome the situation, product managers can attempt to build credibility and educate executives and others around them. But recognize that most product managers are hired into a poorly-defined role, are expected to behave tactically, and are actively discouraged from spending time defining their role and educating others about it.

Indeed, the worst corporate environments actively prevent product managers from realizing their leadership potential.  On page 166 of Leading Change, John P. Kotter wrote:

Highly controlling organizations often destroy leadership by not allowing people to blossom, test themselves, and grow. In stiff bureaucracies, young men and women with potential typically see few good role models, are not encouraged to lead, and may even be punished if they go out of bounds, challenge the status quo, and take risks. These kinds of organizations tend either to repel people with leadership potential or to take those individuals and teach them only about bureaucratic management.

Take note of the last sentence about this type of organization repelling people with leadership potential.  We'll revisit it at the end of this piece.


What to Do?

As an executive, you can empower your product managers by providing them with support.  Support doesn't necessarily mean giving product managers formal authority.  But you can:

• Encourage (and budget for) your product managers to visit prospective and existing customers, to observe them in their native environments, and to conduct one-on-one interviews with them.
• Encourage your product managers to share their market knowledge with others throughout the organization.  For example, suggest that a product manager set up a mid-day meeting and have the company provide lunch for everyone who attends.
• Encourage (and budget for) your product managers to attend training and learn and share best practices in public forums.
• Let others in the organization know that you believe these activities, and the functions of product management, are important.

For more information on the challenges of creating an organization that empowers its employees and fosters innovation, see this paper by my friend and colleague, Becca Frasier.

Self-Empowerment

Finally, let's consider how product managers can empower themselves.

When a great leader finds herself in a disempowering environment, she changes her environment.

In some cases, she does so by establishing mutually supportive relationships with others, by "speaking truth to power" (making the case to executives for organizational change), by teaching, and by demonstrating competence and building credibility over time.

However, the often-overlooked quality of great leaders is that they quickly recognize disempowering environments, extricate themselves from them, and seek out and place themselves in empowering ones.  People who hold onto the romantic notion of leadership might see such a tactic as cowardly or as a form of avoidance, but it is in many cases the only realistic - and the most empowering - approach.

Talents of Great Agile Team Members

Recall the advice of Marcus Buckingham and Curt Coffman: hire people based on talent, not so much for experience, intelligence, and determination.

Talent is defined as “a recurring pattern of thought, feeling, or behavior that can be productively applied”.

So, what are the talents that great agile team members share? Here are some possibilities:

• focus – sets goals and uses them every day to guide actions
• discipline – imposes structure onto life and work
• reflection – examines past choices and learns from experience
• adaptability – quickly adjusts practices to achieve goals
• strategic thinking – plays out future alternative scenarios
• cooperation – interacts with others constructively

Note that, when a person possesses them, talents span every aspect of a person’s life and do not merely manifest themselves in a particular job or work environment.

How would you add to this brainstorm of possible talents that great agile team members share?

ProdMgmt Talk on 02/28/2011

Join me on 02/28/2011 (Monday) at 5 pm CT for the next ProdMgmt Talk. ProdMgmt Talk is a weekly Twitter event in which product management professionals examine and answer questions about a particular topic. You can follow the conversation here or configure your favorite Twitter tool to show tweets containing the #prodmgmttalk hash tag.

This week's topic is innovation and how it relates to product management. We will be discussing the following questions:

1. Are product managers innovators or innovation enablers?
2. What do great product managers do to innovate or foster innovation?
3. What is the relationship between requirements and innovation?
4. Does agile product management foster or hinder innovation?
   

How would you answer these questions? I'll be sharing my thoughts and hope to see yours on Monday.

How to Prevent Product Paralysis

Does your company suffer from product paralysis? Product paralysis occurs when progress halts on improving or innovating a product. At some point, you've probably experienced:

1. A product team can't agree on major product decisions, so they concentrate on minor bug fixes and enhancements that have little or no market impact.
2. Bold product decisions are made (often by members of the team that just happen to wield the most influence at the time), but the decisions come under fire and are put on hold shortly thereafter.
3. Team members don't buy into product decisions, so they undermine them, stall their execution, or just aren't motivated to be productive in executing them.
   

The most effective product managers - to the extent that company executives empower them to do so - employ three approaches to prevent product paralysis:

1. Base product decisions on market understanding and marketing principles. Teams will not buy in to major product decisions unless they can make a compelling case for them. It's hard to make a smart product decision without understanding the market and the principles of marketing (which are often counter-intuitive).
   
2. Involve the team in making product decisions. In the authoritarian model of product management, a product manager becomes an expert on the market, gets input from development on the technical feasibility of implementing new features, and makes unilateral decisions. In the organic model of product management, a product manager leads the process of collective product decision-making and arms the team with the market information and marketing principles necessary to produce quality decisions. A product manager applying the organic approach uses change management and decision facilitation to foster buy-in and to motivate the team to execute.
   
3. Iterate on the research and development of products. Product teams will make mistakes. They will never fully understand the impact of product decisions on their customers until the team at least partially executes and tests those decisions in the market. Thus the team will and should revisit decisions. An effective product team leader helps the team confront risks and uncertainty quickly and in a disciplined fashion. Frequent iterations provide a systematic way of learning and of evaluating and revisiting product decisions.

Thanks to Joshua Duncan for helping me to refine my thoughts on the organic model of product management.

Business Week: "Stop Hiring Leaders from Your Industry"

In their Business Week piece, "Why Innovation Is Beginner's Luck", G. Michael Maddock and Raphael Louis Vitón write that companies emphasizing industry experience in their hiring practices do not, as a general rule, innovate well.

On a related note, I've written before that industry experience is a poor substitute for the ability to learn markets. And don't forget Buckingham and Coffman's observation that the best managers hire for talent, not for experience.

If you are hiring for innovation, the first bit of advice from Maddock and Vitón is:

"Stop hiring leaders from your industry. Ask recruiters to look for a specific problem-solving ability instead of industry experience. Find leaders who have created the results you want in a unique way. For example, if you are faced with disintermediation issues—and all service companies are—look for experts who have tackled disintermediation. It's likely better that they know nothing about sump pumps or whatever your business is, because it will enable them to solve your problem and challenge your paradigms. Beginner's luck."

For executives looking to hire product managers and designers, I think this advice is particularly important.

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.