Cauvin

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