Cauvin

Top 5 Prospect Interview Mistakes

2012-01-09T06:16:00.000-06:00

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?

2011-12-05T00:30:00.000-06:00

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

2011-07-28T23:28:00.004-05:00

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

2011-07-25T07:30:00.003-05:00

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

2011-06-22T08:14:00.001-05:00

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:

A great leader's effectiveness comes from authority.
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

2011-03-20T20:56:00.005-05:00

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

2011-02-27T07:22:00.002-06:00

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:

Are product managers innovators or innovation enablers?
What do great product managers do to innovate or foster innovation?
What is the relationship between requirements and innovation?
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

2011-01-04T09:52:00.014-06:00

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:

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.
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.
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:

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).
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.
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"

2010-09-12T18:34:00.008-05:00

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®?

2010-08-04T10:13:00.042-05:00

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:

Solves problems that prospective customers face.
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:

Identify the stakeholders that must buy into any purchasing decision.
Identify the individuals, departments, and processes that a new solution would affect.
Decide if they really need a new solution or can manage a workaround using convenient choices.
Manage the relationships, internal politics, and historical baggage they will face as they seek buy-in.
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

2010-07-26T10:26:00.007-05:00

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:

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.
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

2010-07-01T09:33:00.010-05:00

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:

You must ask the right questions to get valuable answers.
You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information.
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

2010-05-09T19:12:00.008-05:00

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

2010-02-19T20:16:00.004-06:00

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:

Strive to create a new product category.
Create a new brand to stand for that category in the mind of the customer.
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

2009-09-03T07:47:00.004-05:00

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

2009-08-24T23:08:00.001-05:00

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

2009-06-10T12:09:00.009-05:00

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

2009-03-01T23:45:00.002-06:00

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.

What's Wrong with Product Management?

2009-01-22T08:28:00.007-06:00

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?

Too much tactical activity in the absence of sound strategy.
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?

Educate executives about the importance of strategy and how to best determine it.
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

2009-01-18T10:49:00.005-06:00

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

2009-01-05T10:47:00.004-06:00

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:

Spending a long time to resolve an issue.
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

2008-12-21T22:04:00.010-06:00

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

2008-11-14T12:44:00.001-06:00

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

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.
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.

Seth Godin on Paying for Logos

2008-11-04T09:52:00.001-06:00

In August of 2005, I pondered, "Why Pay for a Logo?" Logos can be important, but it doesn't require deep thought to create them. It's just a matter of following certain simple (albeit counterintuitive) guidelines.

Now Seth Godin recommends:

[T]ake the time and money and effort you'd put into an expensive logo and put them into creating a product and experience and story that people remember instead.

But when you do choose a logo, keep in mind that your impulse to create one with "meaning" is probably a bad idea.

Solution Management

2008-10-17T07:24:00.002-05:00

Solution selling is a sales approach in which the sales person probes into the prospect's pain points and puts together a package of offerings to address them. Rather than selling a single offering, the sales person combines several offerings for the specific customer. (For a comprehensive introduction to solution selling, I recommend SPIN Selling.)

Just as sales people should consider solution selling, product managers should consider solution management.

Consider how some companies structure their product marketing. A friend of mine works for a company that sells hardware, software, and services. Each hardware, software, or service offering is a "product" in this company's terminology. The company's product managers manage these individual offerings. They determine the roadmap for each product, communicate the requirements to developers, and govern the marketing of each product.

The company's business clients, however, almost never buy any individual product. A combination of hardware, software, and services is necessary to address their problems. Since the product managers operate at the level of individual pieces of the solutions, they are detached from the customer.

Sales people at the company are confused about how and what to sell. Product managers have prepared collateral and strategy for marketing and selling individual offerings, but have provided little or no guidance on how to package them into a sale that comprehensively addresses customer needs.

Fortunately, business development and sales support folks have helped fill this gap. They have worked to understand the top problems that customers face and to prepare materials that help sales recognize them and sell the appropriate combination of offerings. These business development and sales support folks are playing the solution management role, albeit informally.

Have you thought about what constitutes a "product" at your company? Does your company sell solutions, or parts of solutions? Is it possible to combine these parts into comprehensive solutions? Consider transforming product management into solution management, or at least formalizing some sort of solution management role.

Scott Sehlhorst on SaaS

2008-08-14T09:04:00.003-05:00

On his Tyner Blain blog, Scott Sehlhorst has a richly informative entry on software as a service (SaaS). What makes his treatment of the topic noteworthy is his focus on practical customer benefit rather than on the hype that typically surrounds SaaS.

Based on Scott's entry, here is how I boil down the problems with licensed software that SaaS solves for customers:

Deployment time and expense. When a new version of the software comes out, it can take considerable time and money to roll the software out, especially in an enterprise environment. With SaaS, upgrades require little or no deployment time or expense for the customer.
Administration time and expense. Typically, when software is installed at an enterprise site, administrators monitor and manage the installation to ensure it is functioning properly. With SaaS, the provider handles site administration.
Lack of accessibility. If the software is installed locally on individual computers, and a customer needs to use software when she is traveling, she must bring a computer with the software installed or rely on installation on other computers. With SaaS, the service is available remotely via the web or another mechanism.

There are other subtle benefits to SaaS. Yet perhaps I've also omitted some major ones?

UPDATE: Paul Young has some additional thoughts.

iPhone Predictions: A Post-Mortem

2008-07-25T13:10:00.002-05:00

Now that we have had more than a year to assess the success of Apple's iPhone, let's see how the predictions of the marketing gurus panned out.

Laura Ries predicted that Apple would initially sell a lot of iPhones, but that ultimately the product would flop. I think it's safe to say that the iPhone has not flopped. Apple sold four million of them in a recent six month period. Ries has recently revisited her prediction.

Seth Godin predicted that the iPhone would be successful, and that Apple would sell more than two million of them in 2007. I suspect he was right about the 2007 sales.

From a marketing perspective, the most important observation about the iPhone is that it has not turned out to be so much of a convergence device. While much of Apple's initial marketing touted the iPhone's merging of music, Internet, and phone capabilities, that perception in the mind of the consumer has not taken hold. In fact, 51% of iPhone purchasers say they will use an iPod in addition to an iPhone.

If you look at the comments by Brandon and Thomas on a previous entry on iPhone predictions, you'll see that they pretty much hit the nail on the head.

Pearls of Wisdom from Stacey Weber

2008-06-22T11:15:00.005-05:00

Are you an executive who has recently adopted Scrum or another agile approach to product management and development?

If so, Pragmatic Marketing's Stacey Weber has some important observations that will help you understand the roles and skills you'll need on your team. (See my concise description of Scrum first.)

First, your product manager (often equated, unfortunately, with the product owner in Scrum) should focus on the problems to be solved, not features:

How often have you already envisioned the solution before you’ve stated the problem? Begin with the problem-oriented requirement: “Every [frequency], [persona] has [problem] with [result].” Then work with a user interaction designer or business analyst to define the solution.

and

Take a look at your team’s backlog. Is it features? Or, even finer-grained tasks than that?

A Product Manager’s primary responsibility is to know the market – to discover urgent, pervasive problems that people are willing to pay to have solved.

We are generally not trained or necessarily skilled in the area of design.

Second, you need an interaction designer on your team:

The designer should be in charge of the translation of market requirements into features. In an agile environment, that means that the designer must work with the Product Manager to understand the market requirements and their priority –and then lead the team to turning the problems into features and sprints that make sense. This must be done in close conjunction with the project manager, to ensure that the product that comes out the back-end makes sense, and provides maximum impact in the target market segment.

Third, be careful with your product backlog. If the backlog contains requirements (i.e. problems to be solved), the product manager prioritizes them. If the backlog contains features, a designer works with the product manager to prioritize them. If it contains development tasks, then perhaps the project manager should help prioritize them.

In an agile environment, that means that the designer must work with the Product Manager to understand the market requirements and their priority –and then lead the team to turning the problems into features and sprints that make sense. This must be done in close conjunction with the project manager.

Bottom line: don't let process obscure the focus on delivering real user benefit, and make sure you have the right skill sets on your team.

What is Scrum?

2008-06-19T07:33:00.002-05:00

Scrum is an agile approach to product development that is centered around brief, informal stand-up meetings.

The term "scrum" originated in the game of rugby. A rugby scrum is a way of resuming a game that has paused due to an accidental foul or the ball having gone out of play. Opposing players engage head-to-head and compete for possession of the ball, which is thrown into the fray.

A "media scrum" is an impromptu press conference in which the media gather around a political figure and bombard her with questions.

Thus "scrum" has come to refer more generally to a short, informal gathering.

In the Scrum approach to product development, scrums are frequent (often daily) stand-up meetings in which each member of the product team states his immediate goal and any risks or obstacles he is facing. The scrums typically start at precisely the same time every day and are often time-boxed to 15-20 minutes.

Other Scrum practices include:

Iterations ("sprints") with a maximum duration of thirty days.
No changes during a sprint to the planned set of deliverables within it.
Demo to external stakeholders at the end of each iteration.
On-going measurement of progress and re-estimation of remaining scope.

Roles in Scrum include:

Product owner is the voice of the customer and determines and prioritizes what will go in the product.
Scrum master facilitates the planning, sprint, and meeting processes. The emphasis is on removing obstacles rather than dictating how individuals achieve goals.
Team is composed of the designers, developers, and testers that build the product.
Users sometimes attend meetings and give feedback on demos.
Stakeholders are not users but may be buyers or vendors.
Managers set up the environment for the team.

Artifacts in Scrum include:

Product backlog is a prioritized list of requirements or features planned for the product.
Sprint backlog is a prioritized, detailed list of requirements, features, or tasks planned for a sprint.
Burn down chart depicts the number of backlog items (or the estimated task hours) remaining in a sprint or for the product as a whole.

Executives and product managers are concerned mostly with product backlogs and high-level visibility into the team's progress.

Dancer Test

2008-05-17T15:47:00.005-05:00

Are you left-brained or right-brained? Supposedly, your brain lateralization determines how you view this animation.

Some people see her rotating clockwise. Others see her rotating counter-clockwise. Some see her unpredictably changing the direction of her rotation.

Supposedly, people who see clockwise rotation are right brained. People who see counter-clockwise rotation are left brained.

I originally came across this animation here.

Brand Tags

2008-05-12T13:52:00.000-05:00

If you haven't already seen Seth Godin's blog entry on it and checked out Brand Tags, take a look now.

A brand is not just a name or a logo. It's a set of associations imprinted in the mind of a customer. At the Brand Tags site, you can say what various popular brands mean to you. You can also see what words other people have associated with brand names. Best of all, you can view a set of these "brand tags" and guess the associated brand name.

What Dimensions Are Best for a Logo?

2008-05-09T13:24:00.002-05:00

You're choosing a logo for your company. In all likelihood, you either:

Have some creative folks on your team design it.
Hire a creative marketing firm to design it.

Then, of course, your team sits down, reviews a bunch of candidate logos, and each one of you spews out a bunch of thoroughly unscientific, personal opinions about which one is "better".

Fans of this blog know (because I have beaten them over the head with it) that the best logos are blank slates (where the non-name portion of the logo conveys little or nothing about your company or product). And you generally should choose a logo with a single color that is the opposite of a major competitor's.

But how tall, and how wide, should your logo be?

Al Ries tells us logotype should fit your eyes: 1 unit high and 2 1/4 units wide.

ProductCampAustin

2008-05-01T08:29:00.013-05:00

You may have heard of BarCamp, informal conferences in which developers meet to share ideas about technologies, tools, and practices.

Spurred by Paul Young (of Product Beautiful fame), a group of product managers in Austin is organizing ProductCampAustin, which is a similar event for product managers.

WHAT: ProductCampAustin
WHEN: June 14, 2008
WHERE: St. Edwards University's Professional Education Center (PEC)
9420 Research Blvd
Echelon III Building
Austin, Texas 78759

Sponsors include Pragmatic Marketing, NetStreams, AIPMM, and AustinPMM Forum, Seilevel, and Austin Ventures.

There are two ways you can get more info or get involved:

Go to the wiki (collaborative web site) and sign up as a participant.
Join the planning group on Google.

Everyone interested in product management, marketing, and development processes is invited, but we encourage attendees to participate (volunteer for setup/teardown, speak, lead a roundtable, set up wifi, etc.) in some fashion.

Focus vs. Innovation?

2008-04-21T14:43:00.005-05:00

Idris Mootee recently blogged a response to an AdAge article (paid subscription required) by Al Ries.

Here are some excerpts from the Ries article:

"What makes a powerful automobile brand today is not innovation, but a narrow focus on an attribute or a segment of the market."
"Innovations outside of a brand’s core position can undermine a brand."
"Most brands don't need innovations; they need focus. They need to figure out what they stand for and then what they need to sacrifice to get there."

Yep, sounds like vintage Ries. But Mootee disagrees:

Mr. Ries is so wrong on this one.

Mootee counters:

What the automobile industry needs today is NOT a narrow focus or an attribute or another brand. They have been doing that for decades and look at Detroit today.

Really? When I ponder the Detroit automobile industry, I think "scattered", not "focused". This counterexample from Mootee is not convincing. As a matter of fact, it tends to support Ries's point.

Next, Mootee cites Samsung as an example of company that innovated outside its focus and thereby established a powerful brand:

The company focused on product innovation that was not limited by their brand, and saw a meteoric rise in sales and brand value in just a few years and is not a serious threat to big boys like Sony.

Maybe. I don't know much about Samsung.

But I don't think you measure the power of a brand by the success of the company. A company can be hugely successful despite a weak brand, and vice-versa. I don't think you measure the power of a brand by mere recognition, either. Brand recognition is only one ingredient of a brand's power.

How many people go out and buy a Samsung as a result of their perceptions of the brand? The Samsung brand means nothing to me; I buy Samsung products only when their commoditized products come out on top in my feature and price comparisons.

Finally, Mootee avers:

Brand strategy and marketing can only give them a Botox, innovation brings new life.

But Ries hasn't argued against innovation. He has merely argued that innovation is most effective when it establishes or reinforces a focused brand position.

Enable Your Product Manager to Be Strategic

2008-04-17T15:45:00.003-05:00

Pragmatic Marketing's Steve Johnson has written an e-book, The Strategic Role of Product Management. In it, Steve argues that strong product management is key to the success of a company when it is strategic and focuses on identifying and solving market problems.

A key graph from the book is:

Increasingly we see companies creating a VP of Product Management, a department at the same level in the company as the other major departments. This VP focuses the product management group on the business of the product. The product management group interviews existing and potential customers, articulates and quantifies market problems in the business case and market requirements, defines standard procedures for product delivery and launch, supports the creation of collateral and sales tools by Marketing Communications, and trains the sales teams on the market and product. Product Management looks at the needs of the entire business and the entire market.

What can you, as a corporate executive, do to enable the strategic product management that will contribute to your company's success?

Create a product management department in your company.
Ask your product managers to lead the company's positioning efforts.
Hire interaction designers and user interface designers that free your product managers to focus on documenting market requirements.
Support your product managers' efforts to call and visit both prospective and existing customers.
Make sure your QA team tests not just against technical specifications, but also tests that your products solve the problems your product managers identify in the market.
Make sure your product managers are experts in the principles governing positioning, pricing, and naming.

Above all, stand up for the strategic recommendations of your product managers. In the face of interdepartmental paralysis, effective product management requires strong executive support.

"Jewelry Central": A Good Brand Name?

2008-03-29T09:36:00.001-05:00

Not.

Seth Godin rants on generic brand names that append a bland word ("central") to a descriptive word ("jewelry"):

Jewelry Central is a really bad brand name. So are Party Land, Computer World, Modem Village, House of Socks and Toupee Town.

It's a bad brand name because Central or Land or World are meaningless. They add absolutely no value to your story, they mean nothing and they are interchangeable. "Here honey, I bought you these cheap earrings at Diamond World!" Not only are they bland, but you can't even remember one over the other. This is the absolute last refuge of a marketer who has absolutely nothing to say and can't even find the guts to stand for what they do. It's just generic.

In the past, Godin has recommended names that yield very few Google search results. Such names are almost never descriptive or generic.

Innovation Games Class in Austin

2008-03-01T08:06:00.001-06:00

Innovation and agilist extraordinare, Luke Hohmann, will be teaching a two-day class on innovation games in Austin.

I have a copy of Luke's book, Innovation Games: Creating Breakthrough Products Through Collaborative Play. It contains the "rules" for a dozen games that you can play with your customers and design team to better understand your market and create innovative solutions to their problems.

Here are some of the details of the event:

When: March 18th-19th, 2008 (Tues/Weds)
Where: Renaissance Hotel, 9721 Arboretum Boulevard, Austin TX,
512-795-6006.
Price: $1695/person

Luke Hohmann, author of “Innovation Games: Creating Breakthrough Products
Through Collaborative Play” will be teaching an intensive, two-day class based
on the material found in the book of the same name. Used by corporations such as
SAP, Rally Software Development, QUALCOMM, Emerson Climate Technologies,
Genesyslabs, HP, Aladdin Knowledge Systems, Innovation Games® have been featured
in Software Development Magazine and Soft*Letter, numerous blogs and
conferences.

Designed by Enthiosys, the leading provider of agile product management
consulting services, this course will provide you with the tools to plan, play,
and post-process the results of the games. We’ll also provide you with
comprehensive notes, worksheets, templates, and books to help you your
learning’s into practice.

You can register for the event here.

Vodka Delusions

2008-02-16T09:11:00.001-06:00

Sorry, but Grey Goose is mediocre. Ditto for Ketel One. At least according to a tasting panel at the New York Times.

The tasting panel sampled 21 unflavored vodkas, mostly on the high end. But for kicks, they decided to include lowly Smirnoff in the mix. The results?

[A]t the end of our tasting it was Smirnoff at the top of our list, ahead of many other names that are no doubt of higher status in stylish bars and lounges. Some of those names did not even make our Top 10. Grey Goose from France, one of the most popular vodkas, was felt to lack balance and seemed to have more than a touch of sweetness. Ketel One from the Netherlands, another top name, was felt to be routine and sharp, although Mr. Klemm did describe it as "a good mixer."

Here were the top ten:

Smirnoff United States Grain
Wyborowa Poland Single Estate Rye
Belvedere Poland Rye
Absolut Sweden Level Grain
Hangar 1 United States Straight Wheat and Grain
Vox Netherlands Wheat
Olifant Netherlands Grain
42 Below New Zealand Wheat
Skyy United States Grain
Teton Glacier United States Potato

The placebo affect [sic] is alive and well.

Interaction Design: the Neglected Skill

2008-02-13T06:18:00.004-06:00

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.)

One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases.

Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are.

Let's see who typically plays the role at companies.

Engineer. An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware or software, but such skills don't guarantee any expertise in interaction design.
SME. A subject matter expert is an expert on the concepts in the domain. What about such expertise entails any knowledge of what it takes to maximize a product's usability? In fact, SMEs often have a skewed perception of usability, as they are expert users, not typical users.
UI designer. User interface designers know how to lay out a screen. They know the best place to put the buttons, what size font to use, whether to use a drop-down menu or a list, and how to make it all look sharp. But interaction and sequencing is a different matter.
Product manager. A properly-cast product manager is an expert on the problems, users, and buyers in the market. Understanding users is important, even essential, but it doesn't by itself entail any expertise in designing a product to be usable to them. A product manager frames the usability metrics, but doesn't necessarily know how to achieve them.

It's certainly possible that a person playing one of these roles just happens to possess user interaction design skills. And in a healthy, productive organization, some people are flexible and play multiple roles. But realize that, to the extent people playing these roles are qualified user interaction designers, it is a coincidence.

Jeff Lash on Qualitative Research

2008-01-22T20:49:00.000-06:00

I had the pleasure of meeting Jeff Lash when he visited Austin a couple of weeks ago. Jeff authors the How to Be a Good Product Manager blog. Not to put words in his mouth, but I think Jeff and I share an affinity for the more strategic aspects of product management.

I was happy but not surprised to read Jeff's recent entry on qualitative and quantitative research. It looks like he and I agree on the importance of qualitative research and the complementarity of both types of research.

Are Expensive Wines Better?

2008-01-14T17:43:00.000-06:00

Researchers at the California Institute of Technology have confirmed the notion that the price tag on a wine affects people's perception of it. In fact, they genuinely experience more pleasure drinking wines they believe are more expensive:

The part of the brain that reacts to a pleasant experience responded more strongly to pricey wines than cheap ones — even when tasters were given the same vintage in disguise.

and

A $90 wine was provided marked with its real price and again marked $10, while another was presented at its real price of $5 and also marked $45.The testers' brains showed more pleasure at the higher price than the lower one, even for the same wine . . . .

If someone else on the executive team urges you to lower the price on your product, be careful.

Limitations of "The system shall . . . ."

2008-01-12T07:18:00.000-06:00

Is your product manager composing documents with hundreds of sentences beginning with "The system shall . . . ." or "The product shall . . . ."? If so, she should consider a different approach.

Back in 2004, Mike Cohn wrote an interesting article on requirements and agile development. Here is an interesting excerpt from the article:

[C]onsider the following requirements:

3.4) The product shall have a gasoline-powered engine.
3.5) The product shall have four wheels.
3.5.1) The product shall have a rubber tire mounted to each wheel.
3.6) The product shall have a steering wheel.
3.7) The product shall have a steel body.

By this point, I suppose images of an automobile are floating around your head. Of course, an automobile satisfies all of the requirements listed above. The one in your head may be a bright red convertible, while I might envision a blue pickup. Presumably the differences between your convertible and my pickup are covered in additional requirements statements.

But suppose that instead of writing an IEEE 830–style requirements specification, the customer told us her goals for the product:

* The product makes it easy and fast for me to mow my lawn.
* I am comfortable while using the product.

By looking at goals, we get a completely different view of the product: the customer really wants a riding lawnmower, not an automobile. These goals are not user stories, but where IEEE 830 documents are a list of requirements, stories describe a user’s goals. By focusing on the user’s goals for the new product, rather than a list of attributes of the new product, we can design a better solution to the user’s needs.

It's revealing that a product satisfying the first alleged "requirements" specification (the series of "The product shall . . . ." statements) likely would fail miserably at addressing the user's real needs. The real requirements are to mow the user's lawn, and for it to be fast, easy, and comfortable for the user.

Via Jonathan Babcock.

Positioning the Democratic Presidential Candidates

2008-01-06T07:13:00.000-06:00

I watched the New Hampshire debates last night. What struck me on the Democratic side was the extent to which the candidates stuck to their positioning. Three of the candidates have clearly staked out their territory in the mind of the voter.

What do the Democratic candidates stand for in the mind of the voter?

Barack Obama stands for "hope" in the mind of the voter. Last night, he repeatedly used words like "empowerment", "getting beyond cynicism", and "bringing people together". The notion that he is an agent of change is an undercurrent of this theme. He wants voters to think he can change the divisive nature of decision-making in Washington into a more inclusive one. His being a fresh face strengthens this message. Voters perceive the usual faces as partisan squabblers that can't accomplish great things.

John Edwards embodies a "fight the power" mentality. He is the populist of the group, and he spoke of battling special interests, lobbyists, multi-national corporations, and "forces of the status quo". The story of his blue-collar father and grandparents working in the mills, and his fighting insurance companies as a trial lawyer, supports this theme.

Hillary Clinton has projected "strength" as a candidate. Her more muscular stances on foreign policy, her statesmanship and experience, and her claims to be a doer and not just a sayer all contribute to this theme. She did not consistently stay true to her positioning in the debate. There were moments in which she responded forcefully to Obama and Edwards with a "let's get back to the real world" message, but she also tried to claim to be an agent of change. This claim distracts from, and may actually undermine, her "strength" theme.

What single idea does Bill Richardson stand for in the mind of the voter? It was difficult to tell from last night's debate, and I suspect his poor standing among the remaining candidates has a lot to do with his failure to position himself clearly.

The Ultimate in Requirements Traceability: DBA

2007-12-22T12:59:00.000-06:00

Requirements traceability refers to the ease of tracking the relationship of artifacts to product requirements throughout the development process. One form of requirements traceability involves slavishly documenting each design decision and precisely which requirement(s) it addresses. There's got to be a better way. And there is.

If your team isn't communicating well and your process is broken, you are likely to have some of the following problems:

Features that are "neat" but don't address requirements.
Designs that don't address requirements.
Difficulty adjusting to changing requirements, priorities, and scoping.
QA that doesn't know what to test.

For this reason, some managers are enamored with the concept of requirements traceability. An untrusting manager tries to impose some heavyweight processes to ensure these problems don't occur. Usually, the process usually involves some huge, complicated spreadsheet with all sorts of links between various items in artifacts.

Instead, why not nudge the team into adopting a few simple, lightweight practices?

Realize that test-driven development (TDD) goes a long way towards establishing a de facto requirements traceability. Encourage your team to "document" its requirements and interaction design decisions as test cases.

But you'll want to test frequently. Use demonstration-based agile (DBA), in which the team delivers a demo and submits things to QA for testing on a weekly basis.

Let's examine the effects of adopting these practices.

First, if design and implementation decisions conflict with the requirements, it will show when the tests fail.

Second, when requirements change, the test cases change, and any other changes that must happen will happen, otherwise the tests will fail.

Third, the weekly demos will ensure that product manager is able to trace or track adherence to the requirements.

Finally, and most importantly, your team will communicate frequently, which will likely improve the quality and efficiency of its output.

Rather than imposing requirements traceability in a heavyweight manner, use DBA.

A Problem Understood is a Problem Half Solved

2007-12-18T08:34:00.000-06:00

In a Q&A over at Functioning Form, Tom Chi gave us this nugget:

Usually when a group of smart people is at an impasse for a long time, it is because the problem is poorly framed, not because their solutions are not good. Unfortunately, it is par for the course in the tech industry to try to bowl headlong into solving things even before we know what the problem is, or the criteria for success. Defining a problem is also an extremely creative activity. If you are falling back to the same lame problem statements and measures of success, then you aren’t really trying. And there are a ton of reasons to try. The most important is that a well defined-and exciting problem (and its associated constraints) is the catalyst that makes design go. By not drawing a clear and compelling problem, you are cheating your team out of an incredible unifying and driving energy.

More Is Not Always Better in Surveys

2007-12-11T06:54:00.000-06:00

Having trouble getting responses to your survey?

In a MarketingProfs.com article, Dean Wiltse tells us seven rules for achieving higher online survey response rates. One of the rules is:

Rule #4: More is not always better

Many organizations believe the more questions they ask, the more measurable the results will be. However, the reality is the exact opposite. The more questions asked, the less focused and thoughtful survey responses are and the more survey takers rush to exit.

Instead of asking every possible question under the sun, survey designers should keep the survey focused and to the point.

Survey administrators should bear in mind that to get a solid response rate the number of questions should not exceed 30.

I'm even more radical. I recommend limiting the number of questions to 12 in most cases.

Demonstration-Based Agile (DBA)

2007-11-10T08:47:00.000-06:00

Adopting agile development processes means adopting key practices, usually some combination of the following:

Develop in short iterations.
Release frequently.
Write tests first.
Communicate frequently.

Organizations moving towards agile product development typically face major hurdles as many people are entrenched in old waterfall thinking. How can you most effectively move towards agile in such an environment?

Forget about Scrum, XP, and all the buzz words. Let me introduce a new buzz word.

Start with demonstration-based agile (DBA) on a small scale. With demonstration-based agile, you insist on only one thing:

Regular Demos. The development staff demos the product to the product manager and other members of the team at the end of every week (or some other short period).

It's a lot easier for a team to agree to regular demos than it is to short iterations or frequent releases. Yet regular demos aren't much different. The team must iterate on developing the product and must have something to "release" (as a demo) frequently. Regular demos also stimulate frequent communication. Finally, the team sort of plans "tests" by defining in advance what to expect from each demo.

Some curmudgeons may resist the idea of regular demos, but for many the concept is easier to swallow than all of the agile practices that fall out of it.

Positioning Cough Syrup

2007-11-06T20:32:00.000-06:00

Positioning your cough syrup can be like positioning mouthwash.

Last year, I cited the example of Listerine as a product that highlights the weakness within its strength. It tastes bad, but the bad taste instills confidence that it kills germs.

Now John Moore at Brand Autopsy tells us about Buckley's Cough Mixture employing a similar positioning strategy.

Effect of Fees on Your Brand

2007-11-05T07:19:00.000-06:00

Sometimes fees above and beyond the base price of your product are a lucrative part of your business. For example, late fees, though they purportedly are exceptional and merely for recouping revenue that would otherwise be lost, are in fact a major cash cow for video rental stores.

From a narrow economic point of view, such fees are good for your business. After all, business is about making money, and the fees bring in revenue.

But the long-term impact of such fees is hard to measure and may be negative. Fees affect the long-term perceptions of your product and company. They affect the equity of your brand.

For details, see this post by Roger Dooley on the Neuromarketing blog.

Presenting at the SMP Conference

2007-10-17T15:32:00.000-05:00

I will be presenting at the Software Marketing Perspectives Conference and Expo Tuesday, October 23rd.

My seminar will be "A Template-Based Approach to Positioning". Here is the description of the session:

Product positioning is the process of defining your target market and shaping the perceptions they have of your product. Positioning largely determines which product requirements to tackle and how to market your product effectively. Prospect problems, distinctive competence, and competitive analysis should drive positioning. Yet how should these factors combine to determine your product's positioning? We will discuss positioning principles and fill out a positioning template for a sample product.

The event will take place at:

Hyatt Regency Austin on Town Lake
208 Barton Springs
Austin, Texas, 78704

See the full line-up of sessions and presenters here. Register here.

The Differentiation Test

2007-10-12T11:37:00.000-05:00

Laura Ries tells us:

The mission of a slogan is not just to define your brand, but more importantly to differentiate it from other brands.

One way to test the differentiation factor is to reverse the slogan and pin it on the brand’s major competitor. Does it make sense? Could it define another brand? If not, then the slogan is just plain puffery that is likely to be ignored.

Read Laura's entire post. It's a great lesson on positioning with many concrete examples.

Industry Experience: How Important Is It?

2007-09-25T09:14:00.000-05:00

In the latest Pragmatic Market BlogFest, Steve Johnson wrote about the importance of domain expertise. Steve's two main points are:

Developers need to understand the domain and not merely code to specs.
Product managers need to understand technology

I can't disagree with Steve on these points. However, more interesting to me is:

How important is it that a product manager have prior knowledge and experience in the domain?

I have written on this topic in the past. In fact, it was one of the first entries in this blog. Below are some more thoughts.

Should a company hire a product manager with years of experience in, and knowledge of, the industry? How about a capable and experienced product manager with little or no prior domain knowledge?

The key to understanding the importance of domain knowledge lies in recognizing a product manager's most important skill: learning about the market.

Thoroughly understanding a market necessarily entails being intimately familiar with the user and buyer experience, and therefore requires grasping the domain in which they operate. So yes, domain knowledge is fundamentally important.

But "learning" means acquiring knowledge, not having it already. A product manager who is knowledgeable about an industry solely as a result of lengthy prior experience is much less capable - and much less valuable - than a product manager who can quickly master a market and domain.

After all, markets change. New competitors enter the landscape, and user and buyer psychographics evolve. Don't you want a product manager who knows how to keep abreast of, or anticipate, these changes rather than relying on the way things used to be?

Thus we see that prior domain experience, while helpful, can be a crutch. An insistence on prior industry knowledge amounts to a concession that product managers are not capable of performing their primary learning function.

If you're an executive looking to hire a product manager, I recommend de-emphasizing domain experience and focusing on the skills that enable market mastery:

Interviewing prospective and existing customers.
Identifying and quantifying the problems that customers face.
Analyzing the competition and their positioning.
Framing survey questions and interpreting survey results.
Observing customers in their native environments.

A product manager performs many other important duties, but the point is that domain knowledge is no substitute for these skills for achieving market mastery.

The Big Brands Do It, Why Can't We?

2007-09-14T08:53:00.000-05:00

Good marketing often contradicts intuitions and instincts. Those wishing to cling to their intuitions find solace in the fact that big companies are just as likely to make mistakes as little ones.

Kimberly-Clark, a huge company and umbrella brand, chose "Huggies" as the name of a line of diapers. "Huggies" is a descriptive name in that it implies in a not-so-subtle way that it is comfortable and effective. (Similarly, Procter and Gamble sells the "Pampers" line of diapers.) Yet descriptive names generally don't make good brand names.

I can hear it now: "If Kimberly-Clark's marketing department decided on a descriptive name, why shouldn't we?"

I should point out that, aside from its descriptiveness, "Huggies" is actually a pretty good name. It is easy to pronounce, easy to spell, and slightly shocking - all attributes that foster brand recall and recognition. Plenty of products succeed despite a descriptive name.

But let's put to rest the idea that big, successful companies don't make marketing mistakes. Fortunately, Laura Ries debunks this notion on a regular basis. In her latest blog entry, she tears into seven successful companies for recent marketing decisions they've made.

eHealthInsurance.com

2007-09-05T15:41:00.000-05:00

A few days ago, I received in U.S. Mail a notice from UniCare that the premiums on my health insurance were going up. Given that my health plan covers little and now is going to cost more than twice as much as it did four years ago, I decided to research other options.

I originally signed up for my health insurance plan through eHealthInsurance.com, a helpful service that enabled me to browse and compare numerous plans from a number of different providers. At the site, you can specify various plan features (deductible, co-pay, etc.), view a list of plans that satisfy those parameters, and compare the plan details.

It's a great concept. Unfortunately, it has nonetheless frustrated me. The reason is that the service focuses on the features of health insurance plans rather than addressing real-world scenarios.

This morning, I went to eHealthInsurance.com to research alternatives to my existing plan. I brought up various plans but scratched my head when trying to determine what they would and wouldn't cover. So I called their customer service to speak to a health insurance "agent".

The agent immediately asked me what I wanted in a plan. I told her that I don't know and suggested we walk through various scenarios and see which plans best covered them.

I get into a car wreck, suffer massive internal injuries, and go to the hospital for surgery.
I get a minor cut on my leg and go to a minor emergency center for stitches.
I go to the doctor for a routine check-up.
I go to the doctor to get a prostate exam (leaving aside the fact that the one prostate exam I've received was the most unpleasant experience in my entire life).

The agent's response? "I don't have time to go through all that. Just tell me what you want," she replied. "Do you want a co-pay?"

At this point, I told her I was frustrated. She was assuming I was an expert on health insurance concepts. All I know is that there are various types of scenarios. Some plans address them well, and others don't. Co-pays, deductibles, co-insurance, and out-of-pocket limits mean nothing to me except insofar as they affect the bottom line in these types of scenarios.

Though she initially refused to walk through the scenarios with me, she effectively did by the end of the conversation. I felt educated enough to compare plans and make a decision. Despite the fact I was still seething with frustration, I thanked her for her patience.

What product management lessons does this experience teach? I'll examine some of them in a future entry.

Trade Shows: Of What Value Are They?

2007-08-28T07:44:00.000-05:00

The esteemed Steve Johnson recently wrote a provocative blog entry on the merits - or lack thereof - of demoing at trade shows. He implies that showing demos is usually not very effective:

Nobody retains information from a trade show--everyone is yelling to be heard. Perhaps you could be a little quieter and much more effective. Let's use the demo where it belongs, much later in the sales cycle.

And he contends that collecting information about prospects' situations and problems is often a better use of trade show time:

At your next event, try just asking people who come by the booth a few simple qualifying questions about their problem and its urgency to them. If they answer in the affirmative, scan their badge or take their card and invite them to enjoy the show. Meanwhile send a set of materials to them through the mail or better yet, have a sales person contact them the week after the show.

In my opinion, Steve's key point is that:

The best demo is customized to the customers, their problems, and within the context of how we can specifically solve their problems.

If you've read SPIN Selling, you know that your best chance of making a high-value sale is to use a facilitative process that starts with asking a lot of questions. Only after you've fully understand the individual prospect's situation and problems do you describe your solution in detail.

Regarding trade shows, however, the more important questions to me are:

Why are you an exhibitor at the trade show at all?
Who is attending the trade show, and why?

What goals are you trying to achieve as an exhibitor at the trade show? If you're trying to sell product, then Steve's advice is important to keep in mind. But maybe you're trying to affect media coverage? Or maybe you're trying to gather intelligence on the attendees and competition? I wonder, though: perhaps you can achieve this latter goal just as effectively without being an exhibitor (and just being an attendee)?

It matters who is attending the trade show. Is media attending the trade show? Are tech geeks with little or no buying authority attending the show? Are actual prospects attending the show? Perhaps you should attempt to segment the population of the trade show into various personas.

The bottom line is that the issue isn't as simple as whether you should demo at trade shows. You need to research the expected trade show population and shape your goals accordingly. In the end, you may decide that being an exhibitor isn't the best way of achieving those goals.

GSD&M's Idea City

2007-08-27T16:39:00.000-05:00

GSD&M is changing its name to "GSD&M's Idea City". This move seems like a bad idea for at least three reasons:

The new name is too long. The length of the name makes it less "speakable". A brand name that's easy to say is more likely to be remembered and more amenable to word of mouth.
The new name is too descriptive. Descriptive brand names are less memorable and make differentiation in the mind of the customer harder.
Any identity change is costly. Every bit of marketing and sales collateral has to be modified and redistributed.

But the threat of rebranding disease is constant and almost ubiquitous.

iPhone Convergence in Action

2007-08-24T12:58:00.000-05:00

It's just one person's experience, but Amy Tiemann recently described her disappointment with the iPhone. Her conclusion:

It turns out that combining multiple functions into one device isn't always more convenient. For me, a Blackberry Pearl plus an iPod Nano seems to be the best combination. I need basic online access on my smart phone, but I don't browse a lot or compose a lot of e-mail on my Pearl. I either call back, answer e-mails from my desk, or if I am traveling, I have my laptop with me.

Recall that Laura Ries stubbornly predicted that the iPhone would fail (after some initial success) because it is a convergence device. The jury's still out, but Amy Tiemann's experience is an interesting data point.

When the Market Changes, Should Your Brand Also Change?

2007-08-16T13:03:00.000-05:00

Trends in the marketplace affect the appeal of your message and the profitability of your product. When the trends run counter to your marketing message, should you reposition your product?

Laura Ries says, "No." She discusses the Hellman's brand. Hellman's mayonnaise is full fat, so

What do you do when the world seems obsessed with dieting, fat and calories? When every product is promoting it is low-fat, fat-free, low-carb, high fiber or zero calorie? When everybody is on a diet, gobbling up calorie reduced manufacture foods yet still hungry, miserable and (at least in the U.S.) fat?

Most company executives and product managers would either modify the marketing message or come out with a "light" version of the product under the same brand.

What does Laura suggest?

Whatever your brand is, you have to deal with it. Pretending it isn’t high fat isn’t going to change what’s in the package. And promoting your “light” version just reinforces in the mind of consumers how “fattening” the regular version must be.

Like food, a brand is best when it is real, simple and focused. If opportunity strikes in another direction, companies should launch a new brand.

In other words, maintain brand focus.

How a Six-Month-Old Startup Got Bought by Google

2007-07-31T10:42:00.000-05:00

Yes, this piece gives advice (based on an actual startup experience) about how to get bought by Google, but it's really just sound advice for any business:

Don't focus on getting acquired.
Instead, focus on the user.
Ignoring limitations lets you tackle problems from a different angle.
Don't be afraid to tackle the giants.
Pay attention to the details.
Have a really understanding spouse.

See the piece for details.

Buy a Problem

2007-07-25T16:59:00.000-05:00

In my last entry, I described the Buy a Feature innovation game. One of the shortcomings of the approach is that it focuses on features instead of problems.

Unless they are product designers, your customers likely do not know how much a feature is worth to them. What they know - or at least what you can elicit from them - is what problems they currently face and how much those problems cost them.

Before your product designers decide what features to include, they need to know the product requirements. As I've mentioned, requirements are simply a manner of expressing, in measurable terms, the problems that customers want to solve and avoid.

So Buy a Feature can put the cart before the horse. Your team needs to understand the problems customers want solved, and how they prioritize them, before jumping into features. And once your team is considering various features, why do you need customers to prioritize them for you? Your team's job is to weigh the features in terms of how well they address the requirements (which have already been prioritized), not to engage customers in a separate effort of prioritizing features independently of the problems they solve.

Buying Features

2007-07-24T16:46:00.000-05:00

One of Luke Hohmann's great innovation games is "Buy a Feature":

Create a list of potential features and provide each with a price. Just like for a real product, the price can be based on development costs, customer value, or something else. Although the price can be the actual cost you intend to charge for the feature, this is usually not required. Customers buy features that they want in the next release of your product using play money you give them. Make certain that some features are priced high enough that no one customer can buy them. Encourage customers to pool their money to buy especially important and/or expensive features. This will help motivate negotiations between customers as to which features are most important. This game works best with four to seven customers in a group, so that you can create more opportunities for customers to pool their money through negotiating.

A nice consequence of using this approach is that it gets customers away from the mentality that features come for free. They must prioritize and balance the value of features versus development costs.

If you haven't checked out Luke's book, Innovation Games, I definitely recommend it.

Nonetheless, in my next post, I will discuss an important limitation of this approach and propose a variation that addresses the limitation.

Monitor Your On-Line Presence

2007-07-23T10:13:00.000-05:00

If you monitor mentions of your company or product on search engines, in on-line news, or in blogs, you may find yourself manually performing searches on an irregular basis. An easy way to monitor your on-line presence is to use Google Alerts:

Go to the Google Alerts page.
Sign into your Google account (if you don't have one, create one).
Click the 'New Alert' button on the bottom right of the page.
Type the search keywords you wish to monitor.
Select whether to monitor news, blogs, web, groups, or comprehensive (all of them).
Select how often you wish Google Alerts to perform its searches.
Click the 'Create Alert' button.

Then you'll receive e-mail notifications when your on-line presence changes.

Your Product Will Be Buggy

2007-07-17T10:47:00.000-05:00

No matter how thoroughly you test your product, no matter how many quality control measures you put into place, any new or significantly-enhanced product you release will be buggy.

Some good quality control measures include:

Your product manager gathers realistic usage scenarios from prospective and existing customers.
Your testing team maintains a suite of regression tests, adds to them as tricky new scenarios come to light, and runs the tests on a regular basis.
Your developers maintain unit tests and run them on a regular basis.
Your developers review each other's designs and code.
You release beta versions of the product to customers.

Yet even with these measures in place, your product will almost certainly contain defects. Part of your release plan should be to put mechanisms in place to efficiently process defect reports, fix them promptly, and enable users to obtain the fixes as quickly and painlessly as possible.

iPhone Smoothie

2007-07-10T20:36:00.000-05:00

It takes some guts to put an iPhone in a blender.

iPhone: Distinctive and Inviting

2007-07-03T12:37:00.000-05:00

My friend Tamara got an iPhone over the weekend, and I got a chance to play with it Sunday. After watching her use it, listening to her comments, and trying it for myself, I concluded that the iPhone is distinctive and inviting.

The iPhone is distinctive in the sense that I have never seen another phone that simulataneously is sleek, has a large and bright screen, and has a fingerable touch screen. My 8525 has a fairly large screen and a stylus touch screen, and it is more powerful, but it is by no means sleek. It looks clunky in comparison to an iPhone.

The iPhone is inviting in the sense that, while not necessarily easier to use than many other phones, the phone's user interface is innovative and stylish. You want to hold the phone and use it if just because it looks so "neat".

That said, aside from its distinctive and inviting look, I see little reason to buy an iPhone. And it still remains to be seen whether the iPhone will be a success in the long run.

Use Cases for Sales Enablement

2007-07-02T11:56:00.000-05:00

The sales folks in your organization need to connect with customers by addressing their specific situations and problems. Arming sales with use cases and scenarios can help.

The idea is to document use cases and scenarios for all situations that a qualified lead might face. When a sales person is on the phone with a prospective customer, she then can not only tout benefits of the product, but she make those benefits tangible and clear by applying them to the prospect's situation.

Fleshed-out use cases and scenarios contain the following information that is critical to a sales person interacting with a prospect:

Description of the functional goal of the user. The name of the use case/scenario should convey what the user wants to accomplish. An explanation of the context and the reasons is also helpful.
User interactions with the product. The step-by-step description of how the user will interact with the product to achieve her functional goal.
Preconditions and postconditions. Conditions that exist before and after the user has interacted with the product as described in the use case/scenario. Preconditions and postconditions indirectly capture the nonfunctional behavior (usability, performance, etc.) of the product.

But keep in mind that most of what your sales people should be doing is first asking questions to understand the customers' situation, problems, the implications of those problems, and the need/payoff associated with the problems. Only then can they identify the use cases and scenarios that are truly compelling to the prospect.

Laura Patterson has more on use cases for sales enablement here.

Dadnab Media Coverage

2007-06-28T09:22:00.000-05:00

A couple of weeks ago, I sent a press release to Austin media outlets announcing the launch of Dadnab. (The service has been operational for over a year, but for various reasons I had held off on announcing it to the traditional media.)

Two weeks later, stories or mentions of Dadnab have so far appeared in three publications:

Austin Business Journal. A blurb appeared in the 6-22-2007 print edition.
Austin Chronicle. The "Naked City" column dedicated a section on Dadnab in the 6-28-2007 print and on-line editions. Also, on 6-25-2007, an entry on Dadnab appeared in the "Chronic" blog.
Daily Texan. Both the print and on-line editions of the 6-28-2007 University of Texas campus newspaper contain a full-blown article on Dadnab.

Properly-crafted press releases really do stimulate media coverage.

Seth Godin on Focus

2007-06-26T18:52:00.000-05:00

Seth Godin points out one reason that focus is so important in marketing:

[Y]ou can learn much earlier in the process if you've gotten it right or not.
Because you're making more per sale, you can spend the time necessary to figure
out what really sells and modify your offering sooner in the process.

When you're all things to everyone, you're nothing to anyone.

Cognitive Dissonance

2007-06-20T12:24:00.000-05:00

The power and pervasiveness of cognitive dissonance and the rationalization are phenomena that all marketers should understand. Read about them here.

The Ultimate Convergence Device

2007-06-15T11:46:00.000-05:00

If this advertisement is any indication, the iPhone really is the ultimate convergence device :-)

Requirements Elicitation Research

2007-06-13T13:02:00.000-05:00

Over on Seilevel's Requirements Defined blog, Joy Beatty wrote about some research into requirements gathering. The results of the research appeared in a paper, "Child's play: using techniques developed to elicit requirements from children with adults" (IEEE membership or subscription required). The research was mainly into eliciting requirements from children, but many of the same lessons apply to adults.

The main lesson from the paper seems to be that it is foolhardy to elicit requirements from children or from adults by simply asking them what they want. Placing them in realistic scenarios and focusing first on what they are trying to achieve - rather than how to achieve it - is the key to successful requirements elicitation.

Project Comparison: Agile and Waterfall

2007-06-12T18:19:00.000-05:00

Chris Woodill wrote about two software projects that his organization is working on. One project is using agile methods. The other project is using a waterfall process.

Chris compared and contrasted the results so far.

Lessons from Apple

2007-06-08T15:45:00.000-05:00

The Economist has an article about Apple and business lessons to learn from it. According to the article, the lessons are:

Incorporate outside innovations. Not all innovative ideas have to come from within your own company.
Design from the perspective of users, not from the perspective of a technologist. Usability is key.
Be willing to ignore what the market says it wants today. Sometimes, concentrating on prospective instead of existing customers is the best policy.
Fail wisely. Expect some of your products to fail and to learn from those failures.

Seth Godin: Against Meaningful Logos

2007-06-07T09:04:00.000-05:00

The best logos and brand names have little or no preconceived meaning and little or no relation to your product. So it's good to see Seth Godin come out so unambiguously against "meaningful" logos:

If you're given the task of finding a logo for an organization, your first task should be to try to get someone else to do it. If you fail at that, find an abstract image that is clean and simple and carries very little meaning--until your brand adds that meaning. It's not a popularity contest. Or a job for a committee. It's not something where you should run it by a focus group. It's just a placeholder, a label waiting to earn some meaning.

If you find yourself or your team evaluating the quality of a logo in terms of what it conveys about your product - instead of it conveying little or nothing at all - you're on the wrong track.

Google Coming to Austin

2007-06-06T14:04:00.000-05:00

Google is hiring for an engineering director position in Austin. Hmm.

Via Austinist.

Reference Cards

2007-06-05T16:16:00.000-05:00

If your marcom team is thinking of creating a brochure, stop and think about its purpose and context.

Where are you going to make it available to prospective customers?
Do you expect or want them to read it as soon as they pick it up?
Do you expect or want them to take it home or to work with them?
Do you want customers to hand them out to their colleagues/friends?
Do you want customers to keep them on hand for reference?

Depending on the answers to these questions, you might consider information or reference cards instead of a brochure. If you distribute durable cards the size of a standard business card (3.5" x 2"), customers are more likely to:

Take it home or to work.
Hand them out to their colleagues and friends.
Keep them in their purses or wallets for reference.

Sometimes a brochure is the way to go, but it depends.

Ayn Rand and Taxation

2007-06-04T10:42:00.000-05:00

Ayn Rand is a hero of libertarians and other advocates of limited government. Many of her fans complain about progressive taxation and favor a flat tax. A progressive tax system is one in which the tax rate is higher for larger incomes, profit, or sales cost. A flat tax system is one in which the tax rate is the same for all incomes, profit, or sales cost.

Most proponents of flat taxation argue that having the wealthy contribute a disproportionate share of their income towards the government's expenses is unfair and wrong. They may even quote Ayn Rand as part of their argument.

I don't want to argue for or against a flat tax here. But I do want to dispense with the notion that Ayn Rand opposed the wealthy contributing a disproportionate share of their wealth or income to the legitimate operations of government.

The money quote is from Ayn Rand's The Virtue of Selfishness:

It is in their own interests that the men of greater ability have to pay for the maintenance of armed forces, for the protection of their country against invasion; their expenses are not increased by the fact that a marginal part of the population is unable to contribute to these costs. Economically, that marginal group is nonexistent as far as the costs of war are concerned. The same is true of the costs of maintaining a police force: it is in their own interests that the abler men have to pay for the apprehension of criminals, regardless of whether the specific victim of a given crime is rich or poor.

Almost sounds like class warfare rhetoric, doesn't it?

A couple of subtleties and qualifications:

First, recognize that Rand believes the government's only proper role is defense, enforcement of contracts, and law enforcement. Rand's opinions on the funding of government therefore cover only those expenses.

Second, Rand did propose a flat tax of sorts but it was voluntary:

[T]he cost of . . . voluntary [my emphasis] government financing would be automatically proportionate to the scale of an individual's economic activity.

Rand pointed out that most of the poor, since they have little at stake, would likely not contribute at all. So what may have appeared to be advocacy of a flat tax in fact more closely resembles progressive taxation in its effect.

A pure disciple of Ayn Rand therefore must therefore favor not only a minimal role for government, but a progressive system of funding it.

Positioning Statements - Courtesy of Wal-Mart and GSD&M

2007-06-01T19:10:00.000-05:00

A leaked Wal-Mart competitive analysis (prepared by GSD&M) gives some nice positioning statements:

Best Buy = Electronics, because they provide information and knowledge to help you make an informed decision.
Kohl's = Apparel, because they provide a wide selection of brand-name apparel for any occasion, any style and any budget in a stylish environment that inspires browsing.
Bed Bath & Beyond = Home Decor, because they have great displays that provide ideas on how to pull looks together.
Walgreens = Quick Prescriptions, because you get them quickly and efficiently so you can get back in bed.

Details here. Via Brand Autopsy.

Big Screen Productivity, Yet Again

2007-05-31T18:38:00.000-05:00

Another study showing that bigger computer screens increase productivity:

On the bigger screen, people completed the tasks at least 10 percent more quickly - and some as much as 44 percent more quickly. They were also more likely to remember the seven-digit number, which showed that the multitasking was clearly less taxing on their brains. Some of the volunteers were so enthralled with the huge screen that they begged to take it home. In two decades of research, Czerwinski had never seen a single tweak to a computer system so significantly improve a user's productivity.

Big screens are convenient, not just a luxury.

Wiegers on the Requirements/Design Distinction

2007-05-30T19:58:00.000-05:00

Karl Wiegers and I have disagreed in the past on requirements terminology.

Now Wiegers has a good piece (registration required) on the distinction between requirements and design. Or rather he attempts to sidestep the interminable semantic debate and focus on some important consequences of failing to understand the "why" behind product specifications.

In my view, the summary passage in the piece is:

When it comes to requirements specification and design, the essential issue is not one of what versus how. It’s a question of distinguishing the real customer need from just one possible description of how a clever developer might satisfy that need. Incorporating a solution idea into a requirement imposes a design constraint. The requested solution describes one way to satisfy some requirement but perhaps not the only way, the best way, or even a good way. Focusing on solutions masks the underlying requirement. This can make it difficult for a developer to understand what the customer is really trying to do, making it hard for him to devise the most appropriate approach to meet that expectation.

Actually, I think the "real customer need" is the what, and a "possible description of how a clever developer might satisfy that need" is the how, so the what versus how distinction makes perfect sense. Setting aside this quibble over terminology, however, Wiegers hits the nail on the head about focusing on underlying needs rather than dictating solutions to developers.

Wiegers elaborates:

The requirements analyst needs to detect when a requirement imposes unnecessary constraints on designers. This should lead to a discussion with the customer representatives about the underlying need that led to the customer proposing that specific solution. It’s important to respect the customer’s input. Don’t summarily dismiss the customer’s solution idea; important information is hiding in there somewhere. Use that input as a starting point to drill down to a deeper understanding of what the customer is really trying to accomplish. It’s possible that the customer’s solution idea will be appropriate, but don’t let the customer—or any other stakeholder—paint the development team into a constraint corner prematurely.

He then gives real-life examples (drawn from actual requirements documents). Here is one:

"A master power button shall be installed on the front panel." Further discussion might surface an explanation of why this precise design approach is necessary. Perhaps it’s required for compatibility with an existing product, or maybe it will conform to a pertinent standard or safety requirement. Or it could be an unstated ease-of-use requirement. If so, it would be good to know about any related usability requirements that could influence this, and possibly other, functionality or design issues.

In other words, customers don't care about "power buttons" per se. They care about compatibility, compliance, safety, and ease of use. If a requirements analyst fails to document these nonfunctional requirements in measurable terms, the product may end up with a "power button" but still end up being incompatible, not compliant, unsafe, and difficult to use.

Kevin Brennan on Strategic Thinking

2007-05-29T08:41:00.000-05:00

Kevin Brennan explains how we can't rely on customers, unfacilitated, to tell us their problems and what it would take to solve them. A strategic thinker needs to be involved.

The summary quote:

A genuinely effective business analyst is someone who can understand business needs well enough to propose better solutions than the business people can develop on their own.

Well stated.

Toyota to Focus on Hybrids

2007-05-28T07:47:00.000-05:00

Toyota's hybrid vehicles have been a huge success. Now it appears that Toyota is planning to focus completely on the hybrid market.

Strategic Advice for Lenovo

2007-05-25T10:30:00.000-05:00

Laura Ries has three recommendations for Lenovo, the largest personal computer maker in China and a spin-off of IBM's ThinkPad line.

Focus the product line on notebooks and discontinue desktops.
Change the company name to ThinkPad.
Focus on battery life as the company's key differentiator.

While I question the wisdom of the second recommendation, I wholeheartedly agree with Ries' other recommendations. This sort of gutsy strategic thinking about positioning (sacrificing a portion of the market to enhance focus) is precisely what is lacking in many companies today.

Survey Incentive

2007-05-24T20:39:00.000-05:00

Meritline recently sent me an e-mail asking me to fill out a survey. The e-mail stated that Meritline would send me a desktop organizer for free as a reward. I chose not fill out the survey.
The irony is that I might well have decided to fill out the survey had they not offered any sort of reward. I thought, "I don't want a desktop organizer, so why should I bother filling out the survey?" Had they not offered a reward, I might have thought, "If this survey is short, I'd be happy to answer questions to help improve Meritline's services."

Survey incentives not only pale in comparison to the deterrent effect of a long survey, but they can actually make some potential respondents less likely to complete the survey.

Furthermore, isn't Meritline biasing their sample in favor of people who want a desktop organizer?

Alyssa Dver on Great Product Managers

2007-05-23T15:57:00.000-05:00

Alyssa Dver tells us what distinguishes a great product manager from a good one. Great product managers:

1. Know their product but also know their own limits.
2. Listen first.
3. Ask why, not what.
4. Are decisive.
5. Are responsive.
6. Communicate frequently, concretely, and concisely.
7. Manage passion.

For details, read the rest of Dver's piece.

Not an SUV

2007-05-22T11:29:00.000-05:00

Want to differentiate your brand? Sometimes it's as easy as being the opposite.

I just heard a BMW ad on the radio saying that BMW doesn't make SUVs. And BMW's ad for the X3 portrays it simply as "Not an SUV."

Dollar Coins

2007-05-21T23:25:00.000-05:00

Has the government done any product management on its currency product?

Since 1971, the U.S. government has made several attempts to ween its citizens off of paper currency (dollar bills) and onto coins. In many other developed countries, similar denominations of currency have been coins, not paper. Supposedly, the similarity of dollar coins to quarters has been one reason that dollar coins have not gained popular acceptance.

If the government were to gather requirements for a currency product, what would they be? What would the use cases be? What would the attributes and constraints attached to these use cases be?

Some of the use cases might be:

Pay for Goods
Carry Money
Withdraw Money
Deposit Money

Some of the attributes might be:

Fit (Does it fit comfortably in pockets/wallets/purses?)
Weight (Does carrying a lot of it around weigh you down?)
Durability (How well does it withstand the elements and time?)
Identifiability (How easy is it to distinguish relative to other currency?)

I am personally sensitive to the fit and weight of currency. I don't like the feel of a lot of change in my pockets, and I can't stuff a lot of coins in my wallet.

Are Two Brands Better Than One?

2007-05-18T13:39:00.000-05:00

Are two brands better than one? Al Ries says no:

It's a trend. Glide is now Crest Glide. Cottonelle is now Kleenex Cottonelle. SpinBrush is now Crest SpinBrush. And so it goes.

Consumers, however, will usually use one name instead of two. Nobody in their right mind would write Nescafé Taster's Choice on a shopping list. Or Crest Glide. Or Kleenex Cottonelle. It's just Taster's Choice, Glide and Cottonelle.

Furthermore, the most powerful brands are those that stand on their own, without corporate endorsements or master-brand hocus-pocus. If Nestlé bought Red Bull (an acquisition they should definitely consider), should the brand be re-badged as Nestlé Red Bull? I think not.

Also, beware:

Research can lead a company astray because consumers prefer the known to the unknown.

Before Dietrich Mateschitz launched Red Bull, he hired a market-research firm to test the concept. "People didn't believe the taste, the logo, the brand name," he said. "I'd never before experienced such a disaster." But he launched it anyway. And today Red Bull does $3.4 billion in worldwide sales.

A good market research firm likely will test the concept with qualitative research and indirect questions rather than focus groups.

Agile Development

2007-05-17T16:01:00.000-05:00

Is your company doing true agile development?

At one time, most people thought of agile development as shown on the left. Determine the requirements up front. Then iterate on the analysis, design, and implementation.

Slowly, people began to realize that BUFR is often a bigger risk than BUFD. The new model of agile development is shown on the right. Iterate on the entire process: requirements, analysis, design, implementation, and testing.

This depiction of the new model is still somewhat crude and incomplete. Testing really occurs throughout the process. And when market research and strategy appear in the iterative loop, it turns into agile product management.

Is Positioning Strategic?

2007-05-16T13:21:00.000-05:00

Branding and positioning are highly relevant to "outbound" marketing and marketing communications. So you might wonder if:

They are relevant to the requirements for a product.
They are part of strategic product management.

I believe the answer is "yes" to both.

As your product manager is understanding the problems in the market, the distinctive competence of the company, and the competition, she should be formulating the positioning of the product using established positioning principles.

Branding strategy and positioning should in fact drive product requirements. Should your focus be on ease of use, customizability, or style? The answer to these sorts of positioning questions determine which problems you choose to solve and thus what the requirements for the product are. They also determine how to prioritize those requirements.

A strategic product manager is a product manager who sets the strategy for building and marketing the product but doesn't necessarily do a lot of tactical outbound marketing (e.g. writing white papers, creating brochures, etc.). Positioning in many respects is a less tactical activity than specifying product requirements, because it sets the vision for the product into which the requirements must fit.

When Convergence Can Work

2007-05-15T08:30:00.000-05:00

Al Ries and Laura Ries post a new video each month on their Ries Report web site. This month's video is about the iPhone and convergence.

In the video, Al Ries echoes his daughter's prediction that the iPhone will flop (after some initial success), saying it

Will not dominate the market.
Will not have a big market.
Will not be a success.
Will not make money for Apple.

One important nugget that stuck out was his statement that:

Convergence can work where convenience is a major issue.

People buy products with a singular purpose except when doing so creates a compelling problem. Mobile phones are an interesting case, because their users usually carry them everywhere. But some people also want to carry cameras, digital audio players, and computers everywhere, too. It would be a problem to carry all of these separate devices.

The convergence of these devices in a PDA phone thus solves a real problem for some people. The question is whether the seriousness of the problem outweighs the drawbacks of combining the devices into a single product.

Weinberg on Healthy Negotiation

2007-05-14T10:57:00.000-05:00

Want to see some contrasting examples of healthy and unhealthy negotiation? Check out Gerald Weinberg's piece from last year.

Intrinsic versus Extrinsic Motivation

2007-05-11T08:42:00.000-05:00

My friend Chris H. recently sent me a link to this Joel Spolsky piece.

Measuring results and basing employee evaluations and compensation on them is important. However, you risk killing their intrinsic motivation:

Intrinsic motivation is your own, natural desire to do things well. People usually start out with a lot of intrinsic motivation. They want to do a good job. They want to help people understand that it’s in their best interest to keep paying AOL $24 a month. They want to write less-buggy code. Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.

Intrinsic motivation is much stronger than extrinsic motivation. People work much harder at things that they actually want to do. That’s not very controversial.

But when you offer people money to do things that they wanted to do, anyway, they suffer from something called the Overjustification Effect. “I must be writing bug-free code because I like the money I get for it,” they think, and the extrinsic motivation displaces the intrinsic motivation. Since extrinsic motivation is a much weaker effect, the net result is that you’ve actually reduced their desire to do a good job. When you stop paying the bonus, or when they decide they don’t care that much about the money, they no longer think that they care about bug free code.

You also risk having your employees focus too much on the metrics, to the exclusion of what really matters:

Another big problem with Econ 101 management is the tendency for people to find local maxima. They’ll find some way to optimize for the specific thing you’re paying them, without actually achieving the thing you really want.

When it comes to dealing with people, be careful with metrics and incentives.

Use Case as a Black Box

2007-05-10T12:33:00.000-05:00

Consider the following use case:

Purchase Items
Actor: Purchaser
Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40.
Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased.

The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items.

What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement. Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint:

Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no longer than 30 + 20 * n minutes to purchase n items.

When you think about requirements in this manner, it becomes apparent that you shouldn't just treat the product as a black box, but also the use cases. The steps in use cases don't matter as long as your product fulfills the preconditions and postconditions.

Requirements and Functional Decomposition

2007-05-09T11:35:00.000-05:00

What is the difference between these two specifications?

1. Security: a team of 10 hackers [profiled elsewhere] per hour attempting to access account holders' credit card information shall be successful no more than an average of once every five years.
2. The system shall require users log in with a user name and password. On the third consecutive unsuccessful log-in attempt using a particular user name, the system will lock the corresponding account.

The first specification is a nonfunctional requirement. The second specification is a functional decomposition of that nonfunctional requirement.

All nonfunctional requirements can be decomposed into functional specifications.

In fact, when an interaction designer fleshes out (defines the particular steps in) a use case, she is functionally decomposing both functional and nonfunctional requirements. She is specifying functional steps that will satisfy the requirements.

Revisiting the Technology Adoption Curve

2007-05-08T09:45:00.000-05:00

[Graph from CNET]

A recent Pew research study categorized adults' "evolving relationships to cyberspace" as:

Omnivore (8 percent)

Devoted Web 2.0 users of either gender, though usually under 30, who voraciously update personal Web pages, blogs and mashups to publicly express themselves. Likely to watch videos on an iPod or participate in a virtual world. Most social interaction takes place via instant messaging, texting and blogging via a high-speed Internet connection at home and work.

Connector (7 percent)

Mostly female thirtysomethings who have been online since the early 1990s and have a fully loaded cell phone or smart phone. They are happy to use the Internet, usually via Wi-Fi, from either device as a place to manage content and connect for work, community, family, hobby and entertainment interaction. They are twice as likely to blog or have a Web page than the average American.

Lackluster veteran (8 percent)

Been there, done that on the Internet since the mid-'90s and could care less about Web 2.0 or mobile media. Usually fortysomething men who have a laptop and a broadband connection. E-mail and cell phones are seen as essential for work for these users, and they surf the Web to find information, as well as e-mail to stay in touch with family and friends, but the interest ends there.

Productivity enhancer (8 percent)

These moderate users, likely to be fortysomethings of either gender with kids, have a positive view on what the Internet offers, in terms of getting their job done and learning new things. They like to use the Internet to stay in touch with family and friends, but you'll be hard-pressed to find them watching a Lost video clip on a cell phone or laptop.

Mobile Centric (10 percent)

Typically thirtysomething, you'll find these users' cell phones jam-packed with things like video clips and games. They, however, are less enthused about connecting via a computer and have been online only for a relatively short time, compared to other groups. Pew found this group to include a high share of African-Americans.

Connected but hassled (10 percent)

These users have invested in technology and connectivity but see it all as nothing more than modern "intrusive" necessities. Usually females in their late 40s, they are interested enough to invest in broadband accounts, cell phones and digital cameras, but they suffer from "information overload" and couldn't care less if they have lost access to the Web, e-mail or cell phone.

Inexperienced experimenter (8 percent)

Having the necessary technology and desire to join the party but unsure of what to do with it, these usually female fiftysomething users of above-average income are below average when it comes to using the Internet and cell phones. They probably have been online for only five years but have tried a little of everything, including posting a comment to a message board, downloading music or sharing photos via e-mail.

Light but satisfied (15 percent)

Also usually females in their mid-50s who went online in the last five years. They are satisfied with the technology they own and use but do so only occasionally and could easily do without it. While the majority have cell phones, they are feature-light and would not consider using one to replace a landline.

Indifferent (11 percent)

Mostly men in their 40s who do not have broadband, these annoyed users have cell phones and Web access but rarely connect. Their slow connections are "no doubt a barrier" to more actively using the Internet to pursue hobbies and share with others.

Off the network (15 percent)

People in this group, tending to be 65 or older, do not have a cell phone or Internet access. Some have computers or digital cameras.

More on the study here and here.

Cingular 8525 Received

2007-05-07T08:08:00.000-05:00

Over the weekend, I finally received my Cingular 8525 (a.k.a. HTC Hermes) mobile phone. Here are some observations:

Navigating the phone with the touch screen is fast and easy. (The exception is the camera; I am still learning its touch screen interface.)
The touch screen dialing is convenient and straightforward now that I'm getting over my expectation of a separate numeric keypad.
Synchronizing contact, calendar, e-mail, and tasks with Outlook took me a long time to get working properly, almost exclusively due to problems with Microsoft's ActiveSync software.
The SMS synchronization software I installed works beautifully. Now copies of all of the text messages I send and receive automatically are stored in Outlook on my computer.
The speakerphone is clear and sufficiently loud.
The slide-out QWERTY keyboard is very handy for typing out text messages, e-mails, and Word/Excel documents.
Wi-fi initially seemed to work well, but now it seems flaky, and configuring it is a bit confusing.

Overall, I'm very happy with my purchase.

Requirements Elicitation Technique

2007-05-04T22:16:00.000-05:00

Bob Corrigan recently described an interesting requirements elicitation technique. The basic idea is to observe while a third party participates in a discussion of a possible requirement or feature idea.

Four Keys of Great Managers

2007-05-03T17:36:00.000-05:00

In First, Break All the Rules, Marcus Buckingham and Curt Coffman tell us the four keys of great managers:

Select a person based on talent, not so much for experience, intelligence, and determination.
Set expectations by defining the right outcomes, not by defining the right steps.
Motivate the person by focusing on strengths, not by helping to overcome weaknesses.
Develop the person by helping him find the right fit, not by helping him get promoted.

Somewhat counterintuitive, but based on some sound premises and research. I recommend the book.

Style and Usability

2007-05-02T13:12:00.000-05:00

For what single idea does "Apple" stand in customers' minds? Here are some possibilities:

Stylish
Easy to Use
Design

It occurs to me that style and usability are both aspects of design, and that customers may perceive them synergistically. The ease of use seems to heighten perceptions of style, and aesthetics seem to strengthen perceptions of ease of use.

I haven't thought deeply about the issue, and I haven't researched it. So it may already be a known fact or may just be plain wrong.