Friday, August 9, 2013

The principle of Simplicity - or "Occams Razor" and metaphysical technology

Warning: again a slightly philosophical blog post!

“Entia non sunt multiplicanda praeter necessitatem” is a latin quote referring to a principle called “Occam’s Razor”. It’s English translation sounds: “Entities should not be multiplied unnecessarily” or in even simpler words: “keep it simple”.

William of Occam was a 14th century logician and Franciscan friar who developed this fundamental principle of simplicity and used it, among many things, to justify that “God’s existence cannot be deduced by reason alone” – not a very popular saying with the Church at the time!

The principle has since the 14th century proven its strength in many contexts by eliminating metaphysical concepts that cannot be either mathematically proven or empirically observed. The reason for bringing this up is that I believe PM's has an obligation to always try to cut away “metaphysical technology”. Which is technology that is not really needed to solve the basic challenge. You can use this “principle of simplicity” to choose between alternatives that reaches the same objective and select the one with the least amount of "metaphysical technology".

However, this means that a fundamental understanding of the challenge is needed before you can develop the correct – i.e. the simplest – solution to the challenge. This often means that "the principle of simplicity" is not the easiest path to a solution. You will in many cases experience that making things fundamentally simple requires a lot of upfront analysis and understanding of the real underlying problem. But I think most of us can agree that is never a bad thing.

Finally a word of caution: you cannot regard the “principle of simplicity” as a natural law. The principle is only to be used as a guiding light. There was another wise man (H.L.Mencken) who once said something like: “For every complex problem, there is an answer that is clear, simple – and wrong” … so be careful to use the “principle of simplicity” with caution. Again this means make sure you have understood the challenge your trying to address - for instance by always analyzing product decisions from the customer experience perspective ... but then you'll have to read the rest of my blog :-)

Here is a very interesting but somewhat philosophical explanation of Occam’s Razor – that inspired me to this blog post.

Monday, June 10, 2013

Die Product Spec - your time is over! 5 steps to Agile

I have hinted at this several times already and I think you all know that I'm a strong believer in the iterative approach to development - especially if you iterate together with your users/customers.

Now is the time to look at what that means for the specifications we're responsible for as PMs.

"Classical" PM wisdom tells us that the Product Manager is the owner of the "PRD" (Product Requirement Document) which is a, sometimes very large and detailed, Word document describing all the functionality and features of the new product.

Thanks to Tom Fishburne
The process to develop this document takes the PM around the organization to gather, validate, prioritize and document requirements from all stakeholders. All very good ...

The big problem with this process and the resulting document is that it is based on "Waterfall" thinking. A thinking that was developed in the 50ties (yes - the fifties ... 1956 to be exact) and abandoned soon after formulation and have ever since been used as the prototype example of how *not* to do specifications. Especially software specifications.

Why is it then that most organizations tend to continue to base almost all their development efforts on this model (and the associated "Stage Gate" model)?

Because it is easy! Waterfall is a simple and intuitively understandable process that makes followup straightforward: "This is what all stakeholders said we needed, this is exactly what we developed, so all is good?" No! - a less polite person might refer to this line of thinking as a "CYA process" ... (see my post on KPI's)

But real PM's are brave people always ready to break new ground to pave the way towards a future that is much better suited for their customers and products. Right?

I have therefore tried to outline an alternative and very simple process to get you started on the Agile path towards this magnificent future:

1. Create an Initial Use Case.
This involves a description of the user experience you want to provide in terms the/a user will immediately understand.

2. Create a first interactive prototype.
With limited functionality but with a clear user interface to enable testing of the user experience you've described. I've found Powerpoint to be a tool you can use but there are of course a wide range of other tools out there to help you depending on what type of product you're trying to develop. A physical item? - try a 3D printing service. A mobile app? - try app platforms as for instance A website? - try Drupal or Wordpress, etc. etc.

3. Test it with real customers.
Perform structured user testing with detailed collection of data. There are many methodologies to do this without affecting the outcome. It is important that you get as honest and direct feedback from the users as possible.

4. Iterate 3.&4. or even pivot as needed!

5. "Raise" prototype to first product.
The first product release is the first version of the product that contains exactly enough functionality to convince first customers to pay for it - also referred to as the "Minimum viable Prototype", MVP. Remember not to give it away for free - non-paying customers are not customers, and they have a tendency to focus your attention on the wrong things. Basically if you cannot even get one of your identified early adopters to pay for what you're planning then it is probably not worth as much as you thought.

Sounds simple? Actually it is, and it is a much more fun way to develop solutions than to spend endless hours perfecting a document that will not even get you to the solution your users need!

Remember it is developing with users ("Co-creation" is the buzzword these days) and the interactive prototypes and focused effort to get to Minimum Viable Product as fast as possible that must be at the center of this process.

Let me know what you think? What am I missing out?

Wednesday, May 29, 2013

New layout - hope you like it?

One of my readers made me aware that he found it challenging to read this blog - not because of the content but because of the layout and text size.

Obviously I don't wan't that to stand in the way for the content so I changed the layout to this which is hopefully less painful to read.

Do let me know if you have issues with this layout as well.

Wednesday, May 8, 2013

Why it really doesnt matter where PM is organized ..

Let me begin by contradicting my own point. Of course it matters who your boss is and how your boss supports your work and all the usual politics involved in "managing upwards", but that is not the same as saying that the organizational "anchoring" of PM is important.

My point is simply that real PMs are obssesed with doing what is right for the product. Period. Nothing else really matters.

The discussion usually revolves around whether PM is a

- Sales/Marketing function or a

- Development/Production function.

... or, as most consultants prefers to say: "Function XX is so critical to the company that there must be a VP of XX that reports directly to the CEO" (substitute XX with any function in the company, such as "Product Management").

As a PM consultant I obviously believe the last point to be true :-). I strongly believe PM really is critical to the company, but as a former VP of XX I also realize that no competent CEO would want *all* functions in the company reporting directly to her, especially not the smaller functions such as PM always is by nature.

My conclusion is that there is no one answer to correctly organizing PM.

However one interesting guiding principle that I want to share with you today is to organize PM in a part of the organization where they do not logically belong. That is, if you have PM's with a technical background, let them report to Marketing and likewise if you have PM's with a commercial background let them report to development. This means that the way you're organized will support the cross-functional knowledge sharing, or rather "knowledge challenging" that is so fundamental to all PM work.

(Thanks to the Cranky PM and Scott Sehlhorst for making me aware of these aspects).

This often means that PM's will move around in the organization as the company evolves and changes and it will not be easy to be the PM - but hey, that's why we want to be PM's :-)

... in conclusion:

1. It doesn't really matter where PM is organized. A real PM is robust enough to handle almost any organization.
2. So you might as well support cross-functional knowledge-sharing by placing PM where it does not logically belong.

What do you think? How are you organized?

Monday, April 15, 2013

The difference between Product Marketing and Management

In the name of optimization I've seen organizations combining Product Marketing and Product Management in the same team, even in the same roles and hence the same persons. Or I've seen organizations with no market oriented PM function (yes, the really do exist) but "just" a Product Marketing function.

In most cases this will not work.

These ineffective organizations probably originates from a basic misunderstanding about the fundamental difference between the two functions.

"Classical" PM thinking (to the extent such a thing exist at all!) almost always refers to PM as a Marketing function. I tend to agree with that if it means that PM's are take their starting point in the Market. But I do not agree if it is taken to mean that Product Marketing and Product Management is the same thing.

Let me therefore try a very simple definition:

Product Marketing is about Communication. A one-way outbound function whose, very important, role it is to explain to the market and customers what the company can offer - Product Communication.

Product Management is about Dialogue. A two-way interactive function whose, equally important, role it is to gather information about the market needs as the basis for product definition and vice-versa to test products and offerings with customers - Product Creation.

Do you see the difference? It is very rare you can find one person who can equally well perform both roles (remember we're not all Steve Jobs) and combining them in the same organization simply does not scale well and creates unfortunate conflicts. Product Marketing is just one of many inputs the real PM needs to design the best possible product. but Product Marketing should be the best and most effective way of communication the final product to market and customers.

As always I encourage comments, especially based on your real-life experiences from your own companies. Let me know what you think.

Thanks to Marty Cagan for inspiration from his fabulous book: "Inspired" ... see under "must reads"

Tuesday, April 2, 2013

I admit it, I jumped on a new fad ... PM's should be Growth Hackers

Just stumbled across a new term (or at least new to me): "Growth Hacking" (TechCrunch definition).

It was coined sometime in 2010 by Sean Ellis, founder of Qualaroo and describes a person that is:

1. passionate about combining hard facts from critical growth metrics (and mind you, only the critical ones as opposed to "vanity metrics") with

2. creativity to develop new ways of attracting customers and finally

3. using curiosity to keep asking "why isn't this working?" or "why is this working?".

All based on a true and fundamental fascination with users and customers, and why they became your customers, combined with deep technical understanding.

In other words "Growth Hacking" is a mindset, a mentality: "I don't wan't to fail, we need to find out what works" ( thx Jason Brady).

The term thus describes what in my mind is the characteristics of a truly powerful, market driven Product Manager ... only "Growth Hacker" sounds way more cool :-)

What do you think? Are you a"Growth Hacker" (Andrew Chen's definition)? ... I think I am. I'll update my LinkedIn profile and see what happens :-)

Thursday, March 7, 2013

KPIs and Quantum Mechanics - the lurking "KPI Darkness" of reality

I heard a joke the other day about the Management Consultant who is caught red-handed cheating on his wife with a beautiful, younger model. He claims that he wasn't cheating, he was just "Benchmarking" as the basis for a LEAN optimization of his marriage.

The interesting thing with benchmarking and the inevitable associated KPI's is that they tend to create a oversimplified but very convincing picture of the, or a, "reality".

That's a scary perspective. As an Engineer I have to belive there is only one Reality (although with many dimensions), but that our perceptions of this reality is different from person to person. Our perceptions on the other hand we can and do influence, for instance by the different ways of measuring resulting in KPI's.

In Quantum Mechanics it has been proven mathematically that you can only measure one thing at a time and that the object you're measuring immidiately takes on the form you're measuring when you're measuring. In other words, you get what you're looking for! The most commonly used example is Light. When you're measuring light as a wave you get the results as if light is a wave (which in reality it is). But when you're measuring light as a particle, it also behaves exactly as expected for a particle (which in reality it is). But how can light be both a wave and a particle?

Well, one school of thought states that Reality consists of all possible outcomes at any given time (who said it was simple to comprehend?). But as soon as you decide on one, by measuring, reality effectively "collapses" to the one you're measuring and all the other dimensions dissappear. So light cannot be wave and particle at the same time when you're measuring, but until then it is both wave and particle - clear as mud, right? But please remember that Quantum (QT) Mechanics is one of the most succesful theories ever made there is therefore a very strong likelihood that it actually describes the real world.

If you're still with me here :-) my point is, that you get what you measure and the remaining parts of Reality disappears from your horizon. So any set of KPI's will always create an oversimplified and hence severely limited view of Reality. KPI's must therefore be used with great care and must never substitute critical thinking (refer to my previous post on the subject). In the business world you cannot allow yourself to accept that the "rest of reality" just disappears as in QT. Chances are that it is still lurking somewhere in the "KPI darkness" and jump up when you least of all expect it. Obviously at a very inconvenient time :-)

I promise my next post will be very "hands-on" again. I plan on taking a look at competences and capabilities, for your company that is. For yourself, the Product Manager, is for a later post. Stay tuned and thanks for bearing with me. As always, I'm looking forward to your comments.

Monday, February 18, 2013

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.

Tuesday, January 29, 2013

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.

Tuesday, January 15, 2013

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:

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.

Friday, January 11, 2013

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