What is a/the Product?

I've struggled for a long time, and continue to struggle, with a meaningful definition of "The Product" that is both actionable, precise and tells the dual-nature of the Product Management work (representing both internal production/development/operations and external sales/marketing).

On a brief walk today I came up with this definition that might work:

"A Product is a representation of the resources a company controls using a terminology the customer understands"

This means that:

1. It must be possible to breakdown the Product into a well defined and unambiguous set of resources in a company, otherwise the Product cannot be delivered!

2. The Product must be representable in a way that provides unambiguous value to one or more customers, otherwise the Product cannot be sold!

Right?

This is actionable in the sense that it enables the Product Manager to understand, or to have to understand, exactly what resources will be required to deliver the Product to the defined customers (see the End2End model for support in that work) ... And it makes it clear that unless the PM is able to clearly demonstrate to the defined customers exactly how the Product provides value to them then it will fail.

.. not an easy task, but represents well the challenge coming from the original definition of Product Management: bridging the gap between company resources and customer needs.

Let me know what you think - comments are more than welcome.

The affectionate "kiss of death" for an entrepreneur!

If you ever had an idea that you were considering turning into a company I'm sure you have been met with feedback along the lines of:

"What a great idea! I'm sure there will be tons of people who would want your idea."

You leave the conversation feeling confirmed that you're on to something, that you're on track to success, that the rest of the world is eagerly awaiting the outcome, alas, sadly no!

This is just about the worst feedback you can get as an entrepreneur. Unless the person providing the feedback is able to be very specific about who "people" actually are or, even better, is willing to spend their own money, then the feedback is worse than useless - it is downright dangerous.

Leading entrepreneurs on is very easy. They have typically not read Karl Popper's empirical falsification (Wikipedia on Karl Popper) that demands the you always search for observations that will prove you wrong, not observations that will prove you right. As humans we tend to search feedback that confirms our beliefs, not the opposite - just look at religion.

So if you take that kind of kind, well-meaning, affectionate feedback at face value you can easily end up wasting a lot of time (if you're unlucky also a lot of money) on a venture that nobody *actually* cares about.

So what I try to do myself is be direct, very honest, almost brutal in my feedback on new ideas. Honestly, that's not easy because I tend to become very excited about new ideas, especially ideas presented by competent people with "fire in their eyes". And mind you, this enthusiasm for new ideas is a fundamental prerequisite for being the deeply naive and positive person needed to engage with the uncertain roller coaster of a startup.

Just promise me that you seek strong mentorship before fully embarking on the thrilling startup voyage.

.. but not any mentor - a brutally honest one.

Let me know if I can help you with some brutal feedback. I'm still learning how to do it right and would love to train on you.

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"