Ensuring the Customer experience in your project plan - it's harder than you think

Have you ever had the feeling that some of the project activities you had to complete during your development of a new product were somehow not adding value to your customer?

... or had that scary intuitive sense of not addressing a critical part of the customer experience in the project but not really knowing which part is was?

I can answer yes to both. Can you?

In my experience a lot of companies are spending significant ressources to ensure that the internal development projects cover everything needed to avoid failures. I'm sure most of you have been part of internal programs to increase quality (dare I say ISO 9000?) or efficiency (LEAN, Six Sigma, etc.). This strong focus on efficiency can be a good and necessary effort for an organization, but unfortunately it sometimes leads to the project losing track of the customer who is supposed to buy and use the product in the end - what I've previously referred to as the effectiveness of the product and project.

Today I'll introduce an advanced use of the End2End model that enable you to both map the customer experience to your detailed development project and provide you with a powerful reporting tool for stage gate reviews (e.g. before product launch).

First you draw the end2end model on the horizontal axis of a matrix (the "customer experience dimension"). Then you add the activities and deliverables from your project plan to the vertical axis of the matrix (the "project planning dimension").

You'll end up with a matrix like the one below where you can recognize the End2End model at the top.

Note how the individual "cross points" in the matrix have been filled out with status indicators (the normal project "traffic lights" indicating the status of the project activity). As you can see you have now a good overview of how each and every project activity addresses one or more elements in the customer experience as outlined in the End2End model. A powerful checklist that can almost directly be used at project reviews in more or less condensed form.

The project example given here indicates that the Ideation and Project planning phases seem to have been almost successfully completed. But there seem to be serious issues with Project execution.

Now ... if you look carefully the matrix you can see a vertical and horizontal axis with no status indicators (see A and B outlined below).

The "A" line indicates a project activity that has no direct relation to any part of the End2End customer experience. This might be fine, as there are a wide range of internal activities addressing for instance internal financial reporting that needs to be done during a development project, but as a market/customer driven PM I think it is a good tool to have to be able to challenge the necessity of such activities in the name of efficiency! Notice how the customer/market driven approach can also help you identify efficiency opportunities?

The "B" column on the other hand indicates a more important problem: a part of the customer experience is not being addressed by any specific project activities. This is most likely not a good thing! You need to make sure that all parts of the customer experience is being addressed by your development project, otherwise you're not taking your end2end customer driven product responsibility seriously.

Hopefully you can see how this, in principle very simple model, can provide you with very valuable insights into you development project. A word of warning though - you'll find that it is not a simple task to map project activities to the customer experience. You will discover that it takes some work and a lot of careful argumentation to do correctly. This is where you might call in the consultants to help you, me for instance :-)

Let me know what we've missed in our work with the model. I'll be very interested in hearing about you real-world experiences with these challenges and how You are addressing them.

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