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.