More Thoughts on Product Naming

After fielding several comments on my last post regarding product naming (“What’s in Name?“), I realized that I had over simplified the problem some. I’m going to add some necessary follow-up thoughts here.

I was previously considering the product naming exercise from the point of view of a start-up. A catchy name works for a start-up because start-ups are building a brand around the product. The game changes considerably for larger companies. Imagine a company the size of IBM with 5,000 products in its portfolio, all with cutesy names like Wizzi. Discussing the portfolio with customers would go from comical to ridiculous in a hurry.

Companies with large product portfolios and well established brands will want to leverage the brand and provide descriptive, functional names for new products. Recall that in our example, the product detected marketing-speak in presentations. Let’s add to the example the fact that the product is marketed by a large, well-known software company – ByteCo. Rather than use a catchy name, ByteCo would be better served to name the product “ByteCo Presentation Cleanser”, “ByteCo Gobbledygook Cleanser”, or something of the sort. Doing so would allow the company to leverage their brand and would allow the product to describe itself to potential buyers browsing the existing product portfolio.

A similar approach is to develop a brand around a suite of products (in addition to the company brand). Microsoft has done this well with the Office suite of products. Having the Office brand applied to a product immediately tells consumers much about the product: it’s for desktop use, productivity related, integrated with Outlook, Word, etc. IBM has been similarly successful with the WebSphere name.

Note the examples above also indicate that descriptive names aren’t necessarily verbose. These kinds of semi-descriptive names are another great option for start-ups. NetFlix, for example, is both catchy and descriptive at the same time.


What’s in a Name?

photo by pareeericaThe subject of product naming came up today on the Pragmatic Marketing LinkedIn discussion board. Naming is one of those creative subject areas that in practice are a pain – but in theory are lots of fun. So what better place to discuss than my blog where I can air my opinion free of political concerns.

I’m a fan of names that have no semantics attached (Kleenex), very generic meaning (Apple), or very esoteric semantics (Google). I also go for names that are easily remembered and easily pronounced in all major languages.

For different flavors of products I like to take two tacks:

  1. generic packages with generic (standard & advanced) or non-sensical (XE, ES) names
  2. solution-based names aimed at a particular use case / segment.

So let’s assume we have a cool new product that will scan your powerpoint presentations for the detection of marketing-speak; inspired by David Meerman Scott’s “Gobbledygook Manifesto“. We decide to call it Wizzi. There will be a free version called Wizzi Basic that will only scan 10 slides a day. The full version will be Wizzi Pro. There is a package aimed at medical marketing companies which adds common phrases determined to be bullshit in this industry (the medical marketing add-on), we’ll call it Wizzi Pro – Medical Marketing Version.

Seems so easy in the abstract. Why is it so hard in practice?


Product Management Belongs in the Marketing Organization


I recently started a new job, so I’m a little late picking up this conversation . It’s such an interesting topic that I just have to chime in.

Saeed from On Product Management asked if Product Managers and Product Marketing Managers in technical companies should be a part of a single “Products Organization.” The overwhelming response from his readers was yes. Saeed has pitched this idea in several previous posts, so he’s had me thinking about it for a while. He’s suggested in the past that engineering should report in to Product Management as part of this “Products Organization.” Saeed’s a smart, experienced guy whom I respect greatly, and the questions he’s asking here are poignant. Many tech companies have severely dysfunctional organizational structures and it damages their ability to compete and stay profitable.

In short, Saeed has suggested that:
1) PMMs and PM should both report in to a singular Products Organization
2) Engineering should report in to Product Management as part of a Products Organization

I’ll address each point separately, then try to wrap-up my thoughts.

Regarding Saeed’s first point, PMMs and PMs should absolutely report into the same organization. And this organization is the Marketing organization, under leadership of the CMO. Why? Because Marketing is about the Four P’s. And no P is more important than Product. I know, I know, this is 40 year-old business school erudition; surely it can’t be relevant in a Web 2.0 world? Despite the greatly exaggerated rumors of their death, the Four P’s are alive and well today in “Big-M” Marketing.

As a refresher, the original Four P’s of Marketing as put forth by Dr. E. Jerome McCarthy, Ph.D. are:
1)Product – the thing that solves the market problem – your company’s offering
2)Pricing – quantifying the value of the offering
3)Placement – how the offering gets to the customer
4)Promotion – marketing communications

Clearly the world has changed since Dr. McCarthy first wrote about these ideas, and the P’s need a little make-over. For instance, placement needs to include positioning in the consumer’s mind as much as on the shelf; promotion needs to include all aspects of Groundswell Marketing and the need to tell a story; but at the end of the day, this is what marketing is about & it’s what successful marketers do (including David Meerman Scott who recently wrote an excellent post on the death of the P’s). Back to the point…. if you are going to create a functional org structure, you’d be well served to place the market-facing members of your product group in marketing.

To address Saeed’s second proposition, that Engineering should report in to Product Management as part of this Products Organization, I say absolutely not. While the market facing members of your product group should be in the marketing organization, the technology facing members of this group should be in an engineering organization. The most important reason for this structure is that the skill sets required to be good at building a product are very different than the skill sets required to be good at Marketing; and nowhere is this more true than in a tech company. Technologists needs to be focused on technology – they must have command of a wide range of tools and they need to keep up with an ever changing technical landscape. Marketers need to be focused on the market and they need to stay abreast of all of the tools of their trade. It’s rare for anyone to have exceptional skills in both engineering and marketing. If you want an exceptional marketing organization and an exceptional engineering organization, you will almost certainly need to have them led by different individuals.

Another reason for this structure is that there should be healthy conflict between marketers and engineers. I’m not convinced that this can happen if both teams are part of the same functional group.

All this said, the Product Management function is critical to the success of a tech company. The org structure should be crafted in a way that allows product managers to run their products like a business within the business. In a large organization it certainly makes sense to have a VP or Director level position running a “products team,” of which Product Management is a part. I don’t think folks that are responsible for MarCom activities should be part of that team though, again because of the vastly different skill sets required. So, while the PM and the PMM should ultimately report into the CMO, as part of the “Big-M” Marketing organization, they should not have the same direct supervisor. The PMMs should be part of the “little-m” marketing/marcom organization.
All of this discussion is around direct reporting structure. While “belonging to” the Marketing organization, Product Managers should lead a cross-functional team as part of a matrix structure. This team should include empowered members from MarCom, Sales, Account Management, Customer Support, Billing, Fulfillment, and Development at a minimum. Depending upon your product and organization, more folks may be needed.

Let me end with a couple of caveats. Caveat 1: I’m talking about larger companies here (200+ people). In business, as in physics, the governing laws of the very small scale and those of the very large scale don’t always agree. Caveat 2: “it depends” was my knee-jerk reaction to Saeed’s questions. Organizational structure is a function of the people in the organization, not the other way around. The org chart should be created to allow the folks that work in the organization to succeed. It should be created with full knowledge of the strengths and weaknesses of your people, as well as an understanding of the intricacies of your finances and operations. So, it’s impossible to provide a stock organizational structure. However, I’m didn’t feel that I was going to further this important discussion with this answer, so I’ve assumed here that your company is not constrained in any way and you’ve decided that the organization will be best served by a traditional functional org structure.


How Strategic is Product Management?

photo by pshutterbug
In a recent post on his blog, Product Management Consultant, Derick Workman, poses the question “What is the Purpose of Product Management?” I certainly agree the premise of the post; that Product Managers must focus on strategy, as opposed to just being task doers. I would, however, emphasize more strongly the strategic nature of the position. Product Management is not only about executing strategy, but also about formulating strategy. While Executive Management determines the company mission & vision, the Product Manager must translate these goals into measurable strategic goals for the product or brand. The Product Manager should act as the General Manager of the product/brand, and should have P&L responsibility for his/her product.

Before the many tactical activities of Product Management can begin, Product Managers must identify the people in the market for who the company’s product will create value. They must identify and articulate the specific problems the company’s products will solve for these customers. They must validate the many assumptions made in the business plan about the market size, application of technology, cost of production, and the profit potential of the product. From here, the more tactical activities discussed in Derick’s post flow naturally. If the Product Manager is not involved in the strategic activities I mention above they are performing project management – not product management.

In many organizations, this role may be titled “Director of Product Management” or possibly “Director of Product Strategy” rather than “Product Manager,” but regardless of the title, this is the complete scope of Product Management in my opinion. I believe that more companies are embracing this complete view of Product Management because it creates clear accountability for the success or failure of the product. Product Management is ultimately the “one throat to choke” and Executive Management tends to like such an arrangement.


Size Matters: Creating Optimally Sized User Stories

In Agile development methodologies, User Stories express desired product functionality from the perspective of a given persona. It’s these User Stories that the development team will estimate and ultimately implement as part of a development iteration/sprint. As a product manager, if you want predictable results and a steady burn-down from your development team, it’s incumbent upon you to provide the team with stories that are just the right size.

It would be easy to assume that story size is a function of the feature desired, but you’d be incorrect in doing so. In truth, story size is determined by the product manager when he/she determines how best to break-up the desired functionality into User Stories. Any non-trivial product feature can be written as a single large story, or multiple smaller stories. It’s easier up front to write one big story, but the cost will be paid as volatility during implementation. Given the logarithmic scale used to estimate story points, the larger the story, the less precise the estimate. The less precise the estimate, the more volatility there will be in your release. It’s really that simple.

The optimal story size is one that balances the up-front work required to split a feature into multiple stories, with the desired predictability on the back end. If you track the actual points required to complete stories for a few releases and graph the difference by story size, you will start to see a picture like the graph below.

To obtain this information, I measured the difference of “actual points to complete” vs. “estimated points to complete” for stories of various sizes over several releases. The data clearly shows that stories that are estimated as 8 points or more are not only estimated more poorly than smaller stories, but that the estimates are off by a greater degree. As you can see in the graph, there is a clear inflection point at the 5-point mark; this was our optimal story size.

Since we used the point scale proposed by Mike Cohn (1, 2, 3, 5, 8, 13, 20…), it’s true that this observation is simply a function of the algorithmic scale used to estimate. More pragmatically, however, what this indicates is that you will have more volatile, less predictable releases when your releases contain large stories. For this team, the optimal story size was 5 points. Your team may have a different optimal story size, but you can be certain it will be in the 3-8 range.

In summary, if you want more predictable, repeatable results from your development team, then help them out by making the effort during release planning and create optimally sized stories. Track estimates vs. actuals, look for the inflection point, and then try to keep your stories that size as much as possible.


Use Kano Analysis to Prioritize the Product Backlog

Photo by monstroDeciding which features to put into the next release is one of the more agonizing decisions that a product manager has to make. If you are like most, you’ve got a list of desired features which far exceeds the time and resource constraints under which your next release will be created. Leaving some of these features on the futures list can feel like abandoning a child. So, how do you decide which will make the cut? In this article, we’ll take a look at how to use the Kano Model to prioritize the product backlog.

Kano Analysis is one of several techniques you can use, not only determine what goes into the release, but also to explain your decisions to stakeholders. The Kano Model was published by Dr. Noriaki Kano in 1984, for which he was later awarded the prestigious Deming Prize for making an outstanding contribution to the study of TQM or statistical methods used for TQM. Though this sounds like heady stuff, it’s really quite simple to grasp.

Kano Analysis allows you to classify product (or service) features according to their impact on customer satisfaction. The model divides product features into three categories: fundamental, linear, and exciters. To be competitive, your product must satisfy all fundamental features, optimize the linear features, and include the “right” exciters. As you might guess, the juice is in the exciters.

The model is depicted graphically by plotting a given feature on two dimensions:

For example, if the feature is “portability,” then your product would be at the far left end of the x-axis if it weighed 50 pounds and had to be plugged in to a wall socket to function. The product would be on the far right end of the x-axis if it fit comfortably in your pocket and came with a rechargeable battery. Determining the y-axis value is a little more tricky. If portability is the norm for your product (like a cellular phone) then even with the best implementation, you might not get much higher than midway up the y-axis. If, on the other hand, portability is not the norm for your product (like a microwave oven), then even the poorest implementation could get you to the top of the y-axis.

With some relatively easy customer research, you can plot features on this graph. Once graphed, features can be placed into one of the aforementioned categories based on their position on the graph as illustrated below.

Kano Analysis

Fundamental Features

Fundamental features are “must haves” for the product. Think: brakes on a car, remote control for a TV, A/C in a house in Arizona. You aren’t going to win a customer with any of these features, but you’ll almost certainly lose them without. Though they are typically not very interesting, you must have a sound understanding of the baseline features for your product. This is more difficult than it sounds, because customers won’t often talk about them. Missing just one can be disastrous, so be diligent.

Linear Features

These are often called “performance features” because more is generally better with them. Think: gas mileage for a family car, screen size for a TV, and square feet for a home. Talk to customers about your product, and these are the features you are likely to hear about.

Linear features represent the world of standard competition. The more you have of them, the better your product is in the mind of the customer; and the more customers are (usually) willing to pay. The inverse is also true – the fewer you have of them, the worse your product, and the less customers are willing to pay. While your product must offer the right performance to price ratio, guard against getting hung up on these features.

If your product has been around for a while, you almost certainly have a good grasp on the linear features of your product. The trick here is not so much understanding what they are, as to understanding where the sweet spot is for the competitive environment.

Exciter Features

These are the “oh cool!” features of your product. These are the features that your customers, though they weren’t expecting them, love. These are the features that help you to create brand loyal customers.

Unlike baseline and linear features, the perception of your product is not damaged by the absence of an exciter feature. Because your customers aren’t thinking about these features, they don’t gig you for not having them. This aspect of exciters provides one of their most interesting attributes; they don’t have to be perfected in order to have a positive impact. Think about the first iPod Shuffle – it was hardly perfect, but it’s small size was exciting to customers. Consequently, the iPod Shuffle captured 58% market share in less than 2 months on the market. Exciters are indeed exciting.

It’s not easy to create exciter features, which is why so many companies choose to compete on price and linear features alone. It’s unlikely that your customers will help much here. They won’t be talking to you about these features until after you deliver them. This is where innovation, design, and market intuition come to bear. Invest here – it is worth every penny.

The Kano Model in Action

By now you might be asking yourself, how do I go about gathering the data used to plot the features on the Kano Model graph? Customer surveys are a great method, and all you need ask are two questions per feature. The first question measures the customer’s satisfaction with the presence of the feature, the second measures the customer’s satisfaction with the absence of the feature.

Kano Analysis Questions

  1. What do you think of the product if it includes feature X?
  2. What do you think of the product if it does not include feature X?

There are three valid responses for either question: “I like it,” “It doesn’t matter to me,” or “I dislike like it.” I personally prefer to ask customers these questions verbally, and then categorize their answer into one of the three valid responses. Doing so allows you to gather additional information, as well as ask follow-up questions. Follow-up questions concerning price can really help in making trade-off decisions for linear features. Free form verbal responses also provide you with a better idea of the strength of satisfaction, allowing you to better place that feature on the y-axis.

The answers to these questions determine the Kano categorization as follows:

If you receive any other combination of answers, you should dig a little deeper on the issue. Perhaps your customer is indifferent to the feature; in which case you would be wise to omit it from the release. Perhaps you’ve stumbled upon an anti-feature; a feature that the customer would prefer not be present, but which they have learned to live with (THINK: Clipit or DRM). This is a pleasant discovery if you can remove the feature, as it will have a beneficial impact on overall satisfaction with your product.

Once you’ve categorized the features on your backlog, you can begin to think about the next release in terms of the implications on customer satisfaction. Note that there is no “right” mix. Your mix of features will vary depending upon market conditions and product life cycle state. New products will include many more fundamental and linear features, whereas mature products should include more exciters.

In addition to a useful new framework for assessing and prioritizing the backlog, you now also have (somewhat) objective data to discuss with executive management. In my experience, this is a very good thing.


Utilize Patterns to Catalyze Innovation

photograph by Paco CTInnovation is clearly not for everyone. Many companies pride themselves on doing things the tried and true way, or on executing perfectly, rather than doing something new and bold. There are, however, not many surer paths to success than lightning-in-a-bottle innovation. Well managed, innovative R&D can lead a company to amazing technological breakthroughs, market dominance, and financial success. Poorly managed attempts at innovation, however, can take the company down a much uglier path – Think: New Coke. So, how do you harness the creative potential of you customers and employees to innovate for success?

As a product manager, I am constantly saying that we need to “ask the customer what they want.” I use personas during product design sessions and rarely a day goes by that I do not interact with a customer. I am an advocate of usability testing and beta programs. I thrive on customer feedback, but I often forget that you cannot rely upon the customer to innovate. Let me say that again – you cannot rely upon your customer to innovate for you. Countless studies have shown that customers simply do not make the leap required to be truly innovative. This is not a knock on your customers. Doubtless, they are smart folk with the capacity to think outside the box. When they innovate, however, they will be doing so in their own line of business – not yours. My own take on this is that innovation requires a certain amount of mental steeping in the problem domain. Your customers simply don’t spend enough time dedicating their gray-matter to your business. Get them together for a ½ day focus group and they are more likely to suggest small modifications to your existing product than they are to come up with something truly innovative. If you want to innovate, you’re going to have to do it yourself. The good news is that, unless you run a one-man show, you are surrounded by smart folks who spent a great deal of their time contemplating the problems that exist in your business, and they’ve got some killer ideas; the trick to successful innovation is harnessing them.

Google gets this, which is why they have famously provided their employees with “20-percent time.” Many of the successful new product released by Google over the years are products of this 20-percent time, including Gmail and Adsense. IBM has done something similar with their “THINK Fridays.” Try suggesting this tactic to your management, however, and you will likely meet resistance not seen since you suggested that the company provide only decaf in the break room. Why? The truth is that your management doesn’t believe that you and your fellow employees will work on anything that might benefit the company. An argument against 20-percent time that I’ve been guilty of presenting in the past is – “hey, that we’re a small company, we can’t afford to focus our resources on anything but our core product.” The truth is just the opposite – we can’t afford not to have our resources focused on innovating.

OK, problem solved right? Let your team take one day a week and work on whatever floats their boat. Maybe attach some stipulation that says it must, in some way, relate to your business and that, of course, products of this 20-percent time belong to the company. Then just sit back and wait for the light bulbs to start popping up over their heads. Pick a few, build ‘em, market ‘em, and retire young. Simple, right? How’s that Hertz commercial go – not exactly. The truth is that your employees are likely to go to the opposite extreme as your customers. Rather than suggest minor tweaks to existing products, they’ll come up with often brilliant, but way-out left-field ideas that for any number of reasons cannot be monetized by the company. You’re not trying to start a think tank. You want ideas that can quickly be turned into profit. So what’s a good capitalist to do? Well, I believe that there is a way out of this predicament – a way to find a balance between ho-hum minor product changes and far-out ideas that are “someone else’s business” – it’s mixing 20-percent time with a concept called TRIZ.

TRIZ (pronounced trees) is a formalized process for creative problem solving and is credited as the methodology behind thousands of patents from Fortune 500 companies including Proctor & Gamble, Boeing, and Philips Electronics. Genrich AltshullerBased on work by Russian engineer Genrich Altshuller, TRIZ provides a set of patterns which can be applied to virtually any product or service to catalyze innovation. To arrive at these patterns, Altshuller analyzed and categorized patented inventions for over twenty years, seeking patterns across the various inventions. This effort eventually led him to his “40 Principals of Invention.” Since 1969, many other brilliant inventors and process engineers have added to this rich methodology with derivative works.

TRIZ is very pragmatic. Rather than requiring great leaps of thought to invent, TRIZ relies upon the application of one or more of the principals in order to remove technical contradictions; e.g. how can an object grow in size, but not increase in weight. By having developers leverage principals of TRIZ, you can bound their creative juices in a way that is much more likely to yield salable ideas.

Jacob Goldenberg, Roni Horowitz, Amnon Levav, and David Mazursky, the authors of “Creativity in Product Innovation”, have created a derivative work based upon TRIZ that they call “generic innovation patterns.” To illustrate how TRIZ works, let’s take one of their patterns, Subtraction, and see how it might work in practice. The subtraction pattern instructs the engineer to remove important features from a product. In so doing, they are faced with the need to replace that feature, live without it, or require other features to perform double-duty. Consider your standard PC. It has a monitor, a keyboard, a mouse, and maybe some speakers. The subtraction pattern would encourage you to remove the keyboard, and mouse. How then would you get user input; perhaps via voice recognition or touchscreen. This is an incredibly simple example, but it illustrates the point. Rather than sending your engineers into the lab carte blanche, have them start with your existing product and a set of innovative patterns. What comes out of the lab is more likely to be salable to your existing market, by your existing sales team.