Considerations for New Product Development
Carl Knibbs on his aptly named “carl’s product management blog” has a post discussing considerations for getting the green light on development of a new product. I agree on all Carl’s points and would add:
How Big?
Market/opportunity size will typically be the number one concern for a new venture. A new product should make it the same. Find a way to quantify the opportunity and present it in a way that makes sense to someone not familiar with the market.
Why Us?
Carl covered “why me” - I’d like to see some statement that explains why your company is poised to succeed at this new venture.
- Do you have favorable relations with the buyers?
- Do you own technology or other IP that you can leverage to exploit the opportunity?
- Do you have a partnership network that puts you in a unique position?
- Are you able to leverage a unique geographical presence?
- Is your brand readily transferred to the space?
Whatever the reason, spell it out. Why is your company uniquely positioned to succeed in this endeavor?
Who Else?
Who else is likely to attack the opportunity. While the opportunity size defines the size of the pie, the answer to this question helps to define the size of your slice (given the answer to “why us” above). Under most circumstances, a small slice of a small pie is not an interesting proposition regardless of the answers to the other questions.
Why Now?
If you’ve ever been involved with a start-up, you know just how important timing can be. Some might say that it is the most important consideration - though it’s nearly impossible to predict “perfect” timing”. It’s important to explain why this is the right time to solve the problem for your target market. What makes today an important time for the market?
Then What?
Like any good start-up, a new product should have an exit strategy. What’s the long-term vision. Do you integrate with other parts of your portfolio? Does this establish the beginning of a new portfolio? Does the product get spun-off as a new business or acquired by a competitor. This isn’t a “burn the ships at the shore” statement of strategy, but it’s important to have some idea of the potential outcomes as they will drive long-term strategy.
Nice list Carl, thanks for carrying the conversation forward.
Cheffing-Up a New Product
Charlie O’Donnell’s post on “Why Product Management is More Like Baking than Cooking” has some great points. In the post Charlie is lamenting the fact that when it comes to product management, the leadership of startup companies seem to want to wing-it (like a cook) as opposed to execute on a proven process (like a baker).
Having more than a little cooking experience, quite a bit of product management experience, and much less baking experience; I’d rephrase the title to say that being a product manager is more like being a Sous Chef than being an Executive Chef. If you haven’t worked in the F&B industry before the difference may escape you - follow me here, I think it’s worth the effort.
Executive Chefs provide vision. They start with a general direction, an idea of the dish they want to serve and a knowledge of the ingredients on-hand. They turn themselves over to the creative process, relying heavily on past experience and gut feel, and voila! they turn-out a plate. The success or failure of the effort will depend upon the skill of the chef, the quality of ingredients, and also rely a good bit on fortune. Many a chef has ruined a dish while learning something that later helps him to prepare a real gem of a meal. This is the software equivalent to R&D.
Sous Chefs, on the other hand, are professional managers. Their primary job is to productize a creation dreamed-up by the Executive Chef. While the Executive Chef has only to create the one dish, one time, and take as much time as she requires to finish it; the Sous Chef must crank out that dish a hundred times a night, with limited resources, while maintaining consistent quality. To be successful it’s got to be more science than art at this stage.
Which brings me back to the point of Charlie’s post. When you are cooking with someone else’s money, it’s time to hire a Sous Chef. Someone who can bring transparency, predictability, and repeatability to the process of taking new products to market.
Note that this does not mean, as some of the comments to Charlie’s post have implied, that the creative process ends when a professional Product Manager takes the reins. Nor does it mean that you are now following a waterfall process where the product goes into the oven and you are stuck with what comes out. As Charlie rightly points out, measurement tools are a critical component to the long-term success of the product. Going back to the analogy, the Sous Chef will monitor key performance metrics such as the amount of time it takes to prepare and serve a dish, what the temperature of the dish is when it leaves the kitchen, the number of dishes ordered per restaurant guest, and overall guest satisfaction. By monitoring these important indicators, the chef can course correct if things start to go awry. The same is obviously true for the product manager.
If your product is ready to leave the test kitchen and get out into the real world, take a big step towards repeatable, predictable success and hire an experienced, professional Product Manager.
Effectively Communicating Product Requirements
I was just looking at a video of Lizzie O’Leary (Bloomberg) on Alltop.com discussing how to effectively tell a story with numbers. What an important skill for product managers. As the leader of your product it’s not only critical that you have data to back-up your decisions regarding product futures, but that you can effectively tell a story with that data.
If you are a product manager, you’ve likely internalized the tenets embodied by Steve Johnson’s quote, “your opinion, while interesting, is irrelevant.” The best product managers say “no” to every new feature request and to keep saying “no” until the case for the feature is made. The case for the feature is made by data. But the product manager’s job is not done when the feature is added to the backlog and prioritized. It’s important to communicate the need to stakeholders inside and outside the organization. Use data; turn it in to a story; indicate the trend and the opportunity. Explain to all stakeholders why you want to do something - not just what you want to do.
Before You Say Yes…
David Radzialowski and Joshua Steffan of B2B Product Makers have posted a great piece titled “So You Got the Product Manager Position – Should you take it?” It got me reflecting on the same question, so I’ve added some to their excellent list of issues to consider before you say “yes”.
Budget. David & Joshua mention this, but I want to call more attention to the subject. As a new PM you will want to travel. Well, you may not want to, but you’ll need to. You need to hit the road with the sales team, listen to existing customers and prospects, attend trade shows, and get a feel for the market. Depending on the product you may want to visit production or service delivery locations. You’ll often have the need to purchase tools. You may need to fill in gaps by outsourcing important functions like win/loss analysis if no one is doing it today. All of these activities are critical to your success and you’re being set-up for failure if you aren’t going to be able to get the necessary budget.
Product Development. This may seem like a silly question to ask, but it’s an important one. Does the company make their own products or do they resell? Your job as PM for a VAR will be about portfolio management, service delivery, and partner relations. Is this your thing? If it’s not, then you’ll want to get with a company that is developing their own products.
Innovation. David & Joshua talk about idea generation, but I’d like to focus on a slightly different aspect - is the company committed to innovation? Lots of companies aren’t and it’s not a requirement for financial success. But it might be a requirement for your happiness. If it’s important to you - ask the question.
People vs. Process. This could be a sub-header under “culture”. Does executive management put its faith in people or process? It’s not a fair question, as the answer is likely both, but where is the emphasis. If you are a Six Sigma-type, you might be fine with an organization that believes in process over people. If you are the highly creative, color-outside-the-lines-type, maybe not so much. Fortunately salary is a pretty good indicator of the value a company places on talent. If they are paying below market they probably don’t feel like they need the cream of the crop to be successful.
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?
The 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:
- generic packages with generic (standard & advanced) or non-sensical (XE, ES) names
- 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?
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
Deciding 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:
- Product Function - The x-axis represents the “completeness” of your product’s implementation of a given feature. It runs from completely absent (far left) to perfected (far right).
- Customer Satisfaction - The y-axis represents your customer’s satisfaction with the product. It runs from completely pissed-off (bottom) to delighted beyond words (top).
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.
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- What do you think of the product if it includes feature X?
- 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:
- Fundamental: Neutral for presence, Dislike for absence
- Linear: Like for presence, Dislike for absence
- Exciter: Like for presence, Neutral for absence
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.
