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 14^th 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 14^th 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.

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 Appery.io. 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?

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.

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?

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"

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

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.