The 2 dimensions of Bundling versus Unbundling - a PM tool

I'm sure you've been faced with the decision on whether to bundle or unbundle certain features or related offerings with your core product from time to time?

Bundling means including the feature, or related offering, into the basic package that is your product. This means that the price of the feature is included in the price of your core product and hence effectively hidden from the customer.

Unbundling is obviously the opposite. Meaning to keep the feature seperate from your core product, thus pricing it seperately, enabling the customer to select or de-select the feature at will.

There are very good reasons for bundling a feature, such as "forcing" the customer to buy the full package or differentiating your product specifications from competition etc. Likewise there can be very good reasons to unbundle a feature, such as increasing transparency, enabling up-selling, making the core product more price-competitive etc.

What I'd like to do today is present to you a small, simple framework that might help you with this difficult decision.

Basically you can look at features from two dimensions:
- The Cost for you to produce the feature (and I'm assuming that this will be true for your competition as well. If not, then you have a different more fundamental problem that needs to be adressed first)
- The Value of the feature for your customer

You are of course aware that pricing a feature has to be done independently of the cost to produce the feature ... right ? :-) but Pricing is an entirely different discussion. By the way, this analysis is valuable for both new features and existing bundles. It is actually a good idea to revisit your bundling/unbundling decisions on a regular basis as part of the normal Product Life Cycle.

For now I've drawn the two dimensions into below 2-by-2 matrix:



As always, there are 4 outcomes of such a matrix (see figure):
- The Differentiators (high cost, high value)
- The Nice-to-haves (low cost, low value)
- The Obvious (low cost, high value) ... and
- The Irrelevant (high cost, low value - I won't spend more time here, but remember to be aware that these features are often requested by your channel and hence you need to seriously challenge such requests).

"The Obvious" are features you could bundle to differentiate yourself. And you will often experience a significant pressure from your channel (sales) to include this for free in an offer to "help close the deal" and "hey, it's almost free for us to do, so why not" ... on the contrary! These are features that you know have a high value for your customers. This in general means that they should always be priced seperately to make the value clear to the market. If you bundle such a feature into the core offering the incremental value of this specific feature falls to zero making it very difficult to extract the revenue from the upsell. Only bundle these features when you're forced to, typically by competition. And then make sure your channel understands how to get maximum benefit of the bundling in the sales process by including this newly bundled, valuable feature in the updated set of Unique Selling Points.

"The Nice-to-haves" are up for discussions. You have two options: firstly you could decide, for the sake of simplicity which is a noble objective for any Product Manager, to dismiss the feature alltogether. Secondly you can also decide to bundle these features, if not for anything else, then to differentiate yourself from your competition with a longer list of included features. But you would never unbundle these features.

"The Differentiators" are features you will never bundle! They help you towards competitive pressure and you enable your channel to increase valuable, and hopefully easy, upsell be adding these valuable features to the sales mix.

Comments are welcome. My primary point being that you need to carefully consider what your bundling/unbundling strategy is. My take is that this is merely another of the wide range of tools in your PM toolbox but this could have significant influence on your P&L so use it carefully.

A few thougths on Blue Ocean strategy and the End2End model

I've just today been introduced to a part of "Blue Ocean" strategy that is referred to as the Buyer Experience Cycle:

http://www.animeherald.com/2012/02/11/blue-ocean-a-look-at-buyer-experience-utility-levers/

Its very encouraging to see how the same thinking that is the foundation beneath the End2End customer experience model, that I have presented previously here, can also be applied to Blue Oean thinking. But there is an additional angle on the customer experience in this model, called the "Utility Levers":

- Customer Productivity
- Simplicity
- Convenience
- Risk
- Fun and Image
- Environmental Friendliness

When adding these to the Experience Cycle (or to our End2End model) you end up with a two-dimensional "Customer Experience Map" that can be used to examine how your new product idea creates a different value proposition from existing products.

So the power of the End2End customer experience model is thereby extended to cover not only the development process (more about that later) and help you ensure that you're "Doing the right things" (the value dimension) and that you're "Doing things right" (the optimization dimension) but also supports you in defining how your product idea is differentiated from competition!

Please comment if this is unclear or if you disagree.

Operational Excellence vs Product Excellence - closely related

A thought struck me the other day about the difference between Operational excellence and Product excellence that made me think ... just a little obviously :-)

Just as well as Product Managers needs to balance "doing the right things" vs "doings things right" they also need to understand the difference between "Efficient" and "Effective" which is basically a different view of the same balance.

Effective refers to the Commercial aspect of making sure your product solves an actual need for the customer. But this also involves an understanding of how the product offering affects the operational excellence of the customers business - how Efficient your product is.

Efficient is about ensuring that the product offerings are not only feasible, but are feasible in a way that is cost effective and optimized. Not understanding how product design affects profitability by carefully considering operational excellence as part of PM excellence can jeopardize your P&L. Actually this is one of the core reasons PMs should have P&L responsibility for their offerings. How would your otherwise keep PM accountable for both sides of this complex equation?

So maybe one of the core links between Operational Excellence and Product Excellence can be derived from the End2End model described in my previous posts (go see, please). Operational excellence is about optimizing the "production" (Operations) of your Product. But all optimization efforts must also begin with the customer experience in mind, just as Product Excellence begins with the customer experience. Bear in mind that some of the primary touchpoints with your product lies in the "Daily Operations" phase of the End2End model (again please refer to previous posts). Hopefully your customer will spend a considerable amount of time in this phase with your product, which implies that the PM - you - must carefully design these touchpoints into the Product during development. I will even postulate that there does not have to be a contradiction between optimizing the operational aspects of your product and at the same time optimizing the user experience as long as you begin your optimization efforts with a careful analysis of the user experience.

... again we're back to one of the core insights for the PM - that everything you do with your product must begin and end with a deep insight into the experiences your customer has with your product. In reality a fairly obvious point, but according to my experience not very well implemented in most PM organizations.

What are your experiences - are your PM team fully aligned with the customers experience of your product(s)?

4 steps to Product Excellence - how to "Do the right things"

As promised in my previous post I'll this time try to give you a specific example of the "end2end" view of the user experience. This example is taken from our work in the Telco industry but the overall concept and method should be valid for almost all industries. If you find it does not match your industry I will be very interested in hearing from you to learn how your industry works and to understand how the model could be adapted to fit your requirements.

Anyway, the model in the figure is firstly divided into the 4 main phases of the user/customer experience. These are the "4 steps to product excellence":

• Procurement (normally referred to as the Sales process, but this is actually only one part of this first phase as you can see)
• Delivery
• Daily Operations
• Fault Handling & Migrations

Starting with the first "touch point" in the top left-hand corner and moving onwards through all the phases of the "customer product life cycle" until the final migration to a new product in the lower right-hand corner.

These four top-level phases are further broken down into the 12 phases of the user experience that more closely reflects the Product - we could refer to them as the "product phases":

• Product Presentation
• Sales
• Ordering
• Delivery
• Provisioning & Installation
• Hand-over
• Surveillance & Monitoring
• Invoicing
• Changes
• Support, Customer Service & Error Handling
• Fault Handling
• Migration

The next step is breaking the product phases into very specific activities and deliverables required to implement the phase. For your inspiration we've outlined a few examples of these activities, typically implemented as processes or workflows in the organization. These activities are divided into external user facing activities, directly impacting the user experience, and internal activities required to support the external activities. An important distinction that ensures a strong linking of all activities (processes/workflows) to the user experience of the Product! This is a main objective of the "Product Excellence" method as you hopefully recall by now.

Hopefully you can begin to see the power of the model by now?

As PM's we found that this perspective on our products fundamentally changes the way we look at what a product is and what we need to have in place when developing new products or maintaining existing products. This is a structure and a method that systematically analyses and captures the user perspective of our products.

... but what about the other side of the "PM balance" (remember the "doing the right things" versus "doing things right")?

This is a subject for the next post: what exactly is a "Product"? What are the different parts of your product? This is where you as PM turn towards the rest of your organization to analyze the company capabilities you can use to design the user experience you need, as captured by the End2End Product model.

By the way, maybe you've already seen this, but the example given here is an example for standard deliveries of standard products. Non-standard deliveries will break down into a different set of underlying activities, but the 4 top-level phases and in some cases even the 12 product phases will often be the same - otherwise, please do not hesitate to comment.

Just as a small side note, you might see how this model can be used to design the main processes in your organization and provide a clear linking of all activities to the user experience, even internal activities that are not normally associated with the users. This can be a very powerful tool for designing and motivating an organization - but that's an entirely different story for a later discussion.

"Doing the right things" vs "Doing things right"

When was the last time you as Product Manager experienced that your job became simpler?

No? right ... that's part of the fun of being a PM.

On one hand we all experience the increasing quality pressure to ensure that no mistakes are made when launching new products.

On the other hand we also experience increasing market pressure to develop new stuff, faster, to make sure we're constantly becoming more commercially relevant to our customers.

In other words PM is torn between "doing things right" for cost and quality reasons and "doing the right things" for market reasons.

Focusing on "doing things right" is currently a main focus for many senior managers due to the consequences of the tough times that forces us constantly into doing more with less resources and hence increases the likelihood of making mistakes. As Product Managers we are therefore challenged with checklists and reviews and other quality assurance tools to ensure that nothing goes wrong. These are all very important and valuable efforts and initiatives for any PM however it can only be a short term focus. At least as primary focus. As PM's we can never allow ourselves to forget our "commercial roots". We must ensure that we're applying all the new sophisticated quality assurance processes on the right initiatives. It should be obvious that we need to remember "doing the right things".

Because if we do not do "the right things" it becomes irrelevant that we're "doing things right"! (if you are to take just one sentence with you from this blog post - this is the one).

One tool that I've found is very helpful in defining what "the right thing" is, is to analyse not just your products as they are normally perceived, but to begin a structured analysis of the touchpoints a customer, or more precisely a "user", has with your product. Of course you're aware that you need to think carefully about the difference between "customer" and "user". In this respect "users" are the critical source of information.

By carefully analysing all the cases where your users "touches" your product you can gain valuable insight into the user experience. An insight that I have seen can sometimes even re-define what your product is!

The analyses should begin with the very first time your user hears about your product. At this first "touchpoint" an expectation is created in the users mind about what the product can do, what it can help her with and hence what the value is. From there the user experience moves on: getting more information, maybe asking for a quote, getting a proposal, issuing an order, getting an order confirmation, delivery, installation, daily operations (MAC - "Moves/Adds/Changes")), invoicing, fault handling etc. Finally, at the other end of the user life cycle, the user decides to migrate away from this product and on to something else. If you've been an effective PM (one that understands the user experience life cycle) you will know by then where the user is going. Hopefully to one of your new offerings.

This complete "end2end" view is defined as a collection of all the "touch points" a user has with your product during the complete user life cycle with this specific product. Understanding this end2end user experience should be second nature to all commercial PM's and is a valuable help in understanding what your product really is.

In a later post I'll show you one specific example of an "End2End" user experience model. Stay tuned.

The "checklist fallacy", on the dangers of checklists

As the quality conscious Product Managers we all are (right?) most of us have experience with long checklists of activities that are critical to have checked off before the launch of our product is allowed to proceed. Typically at some sort of launch review with wide participation from your organization.

As beneficial as these lists often are, there are inherent dangers in the use and interpretation of the results of a completed checklist that we need to consider when using them.

... and just for the record, my point is in no way that checklists are useless, they are a fundamental and natural part of every day work as Product Managers, but they need to be used with great care.

Let's start with a few thoughts about what a checklist really is: The whole point of a checklist is to "boil down complex thinking to a few points of evaluation". This means that a checklist is a summary of a lot of complex thinking and often a wide range of activities into one or a few points on a simple list. In other words: they are abstractions of complexity.

So to use checklists in meaningful way, there are at least two critical pre-requisites that you need to bear in mind:

1. Checklists can never substitute critical thinking. Even in the cases where "all lights are green" there can easily be important assumptions hidden in the checklist - hence always challenge assumptions for the marking of a point on the checklist. 
2. Always ensure you know who is responsible for checking the relevant point off on the checklist! It should never be anyone else but the person ultimately Accountable (refer to RACI) for the results. By that I mean that the Accountable person needs to represent the processes or people that have to live with the results of the delivery after launch. 

I know this might sound obvious to some, I actually hope so, but many of us have must likely experienced checklist "abuse" leading to, let's say un-intended results in unfortunate cases where the CYA potential of checklists makes the realisation of contingency plans very difficult. Why not try to be professional and consider this upfront instead? (and I'm not referring to the CYA part here).


Another perspective on the "checklist fallacy" is the relevance it has for KPI based management too ... but that's a different story.

I would love to hear from you if you have experiences with the "checklist fallacy"?

What is Product Management?

Welcome to the "PM Excellence" blog.

The intention of this blog is to share experiences and views on the discipline of Product Management. As I have a background in high tech, especially Telecom and IT, my own perspectives will obviously come from those industries. However I believe that many of the thoughts and concepts presented here will have relevance in other industries as well. So I hope we will see comments or entries from a wide range of industries and companies.

Let me "kick off" by offering my own definition, based on 20+ years of experience, of what Product Management is:

"Product Management is the discipline of bridging the gap between customer needs and company capabilities"

This definition firstly defines Product Management as a discipline. According to "Dictionary.com" a discipline is an "activity, exercise, or a regimen that develops or improves a skill". Hence it is much more than a job description, it is something we can all be better at by doing it. The objective of this blog is to inspire you to become better even excellent product managers.

Secondly this definition requires a deep understanding of customers actual needs. The excellent product manager will strive to understand exactly what it is the customer tries to do with the help of the product. This might be very different from what the customer initially is asking or expecting from your company but can provide a powerful sales platform for valuable discussions with the customers. This obviously implies that product managers needs to be in very close contact with customers and markets - but this should be obvious, right ?

Thirdly the product manager needs to have detailed understanding of the company's capabilities. Note that this should go well beyond the normal building blocks of the standard products you do and well into any other capabilities the company might have that can be used to satisfy customer needs. This is one of the areas where Innovation practice can provide valuable input to the product managers. You will most likely be surprised where you can find valuable elements for your innovative products when looking outside your normal "product comfort zone".

The next natural step here is then to ask ourselves what a "Product Manager" is! Hopefully I'll get an opportunity to get back to that later.