I’m back in the USA for a few days attending some seminars on product management. They very good and highly recommended – check out the website links, http://www.pragmaticmarketing.com/ and http://www.productmarketing.com/productmarketing/.

As I have said before his blog I have been trying to get to grips with product management and what is it product managers do for while so the seminars most useful. About half material in the seminar is like an MBA refresher course – specifically my marketing modules. The other half is really what do product managers do? And how do they do it?

So to save you the suspense I’ll summarise the answer… product managers identify what customers needs and get it delivered.

But there are one or two twists…

First is, it is not what one customers says it is what a set of customers say – that is what the market says not what an individual customer want.

Second twist: it isn’t the features the customers ask for that we should build but a solution to their problem. So we have to look beyond the mere feature request to a deeper level to the problem that they are encountering and then we need to build the solution.

So if a customer asks for the colour to be changed you have to ask: why? If the answer is simply that this customer doesn’t like the colour then probably it is insignificant.

But if you find that many customers are asking for the change and when you look into it you find it is because you’re product appeals the colour blind users then there is a legitimate reason to change the colour – there is a problem to solve.

But to properly solve the problem you have to make sure you change the colour in such a way that colour blind users can use the software. There is no point changing from one colour to another if it doesn’t improve situation.

Picking up another theme of this blog, nothing I have heard here contradicts what I’ve written about Lean Thinking. In fact I think to ideas are completely complimentary.

• Lean thinking says: reduce waste – specifically don’t do work that you don’t need too, and when you do solve the problem solve it completely, no half measures.
• Product management says: only do the work that directly benefits the customer, work that we have qualified and will help the customer. And when you do it solve the problem completely there’s no point in only solving half the customers problem.

So seems to me that both sides are saying the same thing don’t do work that nobody wants. That may seem pretty obvious but it seems pretty difficult to actually do.

John Maynard Keynes, the economist once said:

“The ideas of economists and political philosophers, both when they are right and when they are wrong, are more powerful than is commonly understood. Indeed the world is ruled by little else. Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist.”

Ideas can seem small. They can seem weightless. How many ideas fit on the head of a pin?

But Keynes was right. Consider Karl Marx, his ideas where hatched during the middle of the nineteenth century but led 60 years later to the Russian revolution, and from there to the cold war that only ended in the 1990’s. Millions still live with his ideas in China, Loas, Korea, Cuba and elsewhere.

That is a powerful idea.

Maybe if Marx hadn’t had these ideas someone else would, but mankind had gone several thousand years before he came up with the ideas. Maybe it would have been another thousand years before someone had the ideas. Still, apply the Jackson Pollock test, it was Marx who had these ideas when he had them.

Something similar happens to ideas in companies.

Often it takes time for a new idea to work its way into the system, people need time to think about the idea, see if it makes sense to them and try the idea. Sometimes the people who embrace the new ideas aren’t in a position to do anything with them only in time as these people move into positions of influence can they do something with a new idea. And sometimes it takes time for people to see the applicability of an idea, only over time as they now view the world with the new idea in their head does it start to make sense of them.

So as with Marx there may be a the gap between the idea and affect.

Ideas can often seem very abstract and they can be difficult for people to grasp. This is where stories role to play. By embedding an idea in a story that tells how it changed people, and what was done, the idea is less abstract and people have an example to better understand the idea. This can help in internalising the idea and seeing work can be applied in an organization.

Still it can take time for an idea to have an affect. We can speed up the work of an idea if we support it but we can also smother it. I suppose a I have been guilty once or twice of having a great idea, or at least an idea I thought was great, and by being over enthusiastic about the idea I have made people sick of the idea.

Another thing that can slow down theory adoption of an idea is the need to change some of our existing ideas. If we are to embrace a new idea we often have to give up something else – if I want to embrace the idea of a red car I need to get rid of my idea of a blue car.

And so back to Keynes who also said

“The difficulty lies not so much in developing new ideas as in escaping from old ones.”

Look at the difficulty some countries have had in getting rid of Marx’s ideas.

I spent a couple of years working in California, in Silicon Valley itself to be exact. Unfortunately instead of getting .com boom I got .com bust, still it was a very interesting experience.

One of the differences I found between London and California was the existence of Product Managers. I’m not saying product managers didn’t exist in London but they were few and far between, whereas in California they were plentiful. These are the people actually charged with ensuring the product develops in the right ways and they seem to be intrinsic to high-tech companies.

(As I’ve noted before product managers exist outside of the software arena but these are often marketing rules concerned with branding, advertising and image.)

Of course back in London we had Business Analysts who performed some of the same role but the two are very different beasts – product managers are much more outward looking and business analysts are normally inward looking. Of course some of this is the difference between a product company and the bespoke development organisation.

As I’ve noted here before this is the year when I became Product Manager. Last week somebody asked me an interesting question: “what is it product managers do?”

So I waived my hands a bit and I said something about understanding the customer, understanding customers needs, customer problems and what they are looking for a product.

And the product manager needs to talk to the technical people who developed the product so they can understand what is possible, what new technologies are coming, and how the product might be able to meet customers needs.

In a way that product manager is a translator, translating what the developers say to the customers and translating what the customers say to the developers. But there’s more to it than this.

There’s an element of creativity, seeing beyond the customers immediate concern to what could be, and imagining how the different technologies can be put together to create something new.

There is also the question of product strategy, where is the product going? What will look like in a years time? What about the competition? Is there even a competitor?

Then there’s the question of marketing: so-called inbound marketing (finding out what the market wants) and outbound marketing (presenting the product to market). The marketing and strategy questions are very closely related.

And you can throw in here something about product vision too.

Of course all this these be aligned with company strategy, so you might well get involved with setting the comely strategy to. Normally the product strategy will support the corporate strategy, if product strategy and corporate strategy are different there will be problems.

Then there’s the question of project management. In some organisations that product manager might be quite close to the project management, in fact they may do themselves. The product I look after has a small development team so I get involved in a lot of project management decisions. On bigger teams than maybe for a project manager and a product manager.

However I’ve also seen situations where there is a product manager, a project manager a software development manager and maybe a technical lead too. When this happens you have too many cooks. It is often said that the best software development teams a small but there is no point in having three or four software developers and another four or five managers.

But I digress….

In many ways the product manager is a product champion. In this part of the reason why think a product manager’s role is essential. The product without a champion is unlikely to move forward and advance. Of course there should be room from more than one champion, the more people who are enthusiastic about the product the better.

So being a product manager is a mix of all these things and probably a few more.

Unfortunately that is rather longer answer than some I would like – I’d like to have a more succinct answer to the question. So I need to keep thinking about this and see if I can come up with a nice short answer.

The naming of patterns can be a tricky business. There are all sorts of rules of thumb, one can use, for example: favour and nouns over verbs, tell the reader what to build and describe what you get rather than what you do.

My first proper pattern, Encapsulate Context, didn’t follow these rules. In fact, there was a lot of debate over the pattern name, if I remember rightly. I originally called it a Program State, then during the writing it became Encapsulate Exclusion Context, and when it was workshop at EuroPLoP the group felt the name Encapsulate Context was best. So it became Encapsulate Context.

Well a while back, I rrealised the name Encapsulate Context broke a good many of the rules of thumb, but I felt that it was too widely known to change.

Earlier this year, I submitted the pattern to the editors of the forthcoming patterns book Pattern Languages Of Program Design (Volume 5). The pattern was anonymously peer reviewed by two other writers, and in the best tradition of anonymous review one of these thought the name was fine, and the other one wanted a radical change.

The one who wants a change wanted the name changed on the grounds they it confuse Smalltalk programmers. Since the pattern is aimed at C++ and Java programmers this wasn’t a big concern of mine. And again, I felt the naming Encapsulate Context, had a certain history.

( The book, by the way, probably won’t appear until early in the New Year but you can pre-order it already Pattern Languages of Program Design 5.)

So when the book appears the pattern will be Encapsulate Context but since then, the name been on my mind more and more. Finally I decided to change it.

There is now a new version on my web site using the new name. Well, I say, a new version. Apart from changing the name, i.e. adding a single d, there isn’t really any change.

Moral of the story? Embrace change, don’t let the past, confine you.

Encapsulate Context is dead, long live Encapsulated Context!

I’ve raced through my latest book, sign of a good book, an interesting read, and most of all, a sign of large print!

This month’s book has been Lean Solutions by Womack and Jones (2005), two of the original authors of The Machine That Changed the World (Womack, Jones & Roos, 1991).

In some ways, Lean Solutions is an update of the earlier book for the start of the 21st century. It updates the ideas with some good examples from outside Toyota. I particular like the Tesco example, and the study of the sports shoes.

Did you know that training-shoes (sneakers) need to be ordered 5 months in advance? Or that Nike alone produces more sample shoes than the fourth largest manufacturer? (And that was before Adidas bought Reebok, so I guess it’s more shoes in the third largest manufacturer now.) It all because the industry is not lean.

Order have to be made so far in advance so they can be sent to Asia for manufacture. They have to manufacture enough to ship a large container to the US or Europe. And that transport takes time. That needs to be divided into smaller loads and distributed. There are delays and buffer stocks at every stage.

So, not only is there a lot of surplus in the system but the company isn’t very responsive and customers often find items out of stock. In fact, it puts the whole economics of lowest-cost manufacturing into doubt – and all that implies for offshore production.

The book focuses on customer rather than manufacturing. The authors identify the main customer problem today: lack of time. So it is fitting that several of their studies are drawn from service industries such as medical care and car maintenance.

But the authors go beyond lean thinking and case studies. They envisage a world where lean is the norm, they discuss how the world could be and how all our lives could be improved. The author’s set an agenda that you massive change the way the world works.

If you know a bit about lean this will teach you a lot more. If you know about lean from older books this will update you. And if you want to be lean this will give you some good examples and stories to tell.

Continuing on the theme of innovation, there is another common technique used by companies to produce innovation. Often it used to develop somebody’s innovative idea and is sometimes used to generate innovative ideas as well. This is the skunkworks model – or to give it a less jazzy title: separate your imaginative team.

In this model, the team that is to produce the innovative product is separated from the main organisation. The people involved a ring fenced, they may work at a separate location, they are removed from the day-to-day life of the company, and in particular, the politics and blocks on innovation that exist normally. Sometimes these teams are kept secret.

This technique has been documented in countless stories, indeed, Lockheed Martin have trademarked the term skunkworks. If you want to know more about this method you could read Coplien and Harrison’s Skunkworks pattern and in their book, Organizational Patterns of Agile Software Development, 2005.

(I have also discussed the technique in pattern form, Separate Imaginative Teams.)

Hamel and Prahalad also noticed this technique in their Harvard Business Review article, Corporate Imagination and Expeditionary Marketing – May-June 1991.

There is something macho about this technique: the image of a bunch of brave souls going off to design and create a new product, cut off from the Corporation, free from the politics and infighting. And sure it does work, companies do create new products this way, however, this technique also has a downside.

This technique may create a new product, it may bring about an innovation, it may get you out of a hole right now, but it does little to make the overall organisation more innovative. In fact, it may detract from the overall company’s innovative ability.

To start with the innovative people are separated from the rest of company so none of their expertise or experience is directly accessible by the rest of the company. Neither do they form role-models for other people in the company. Many times, the new product development is invisible to rest of the company – they just get on with their regular work.

And when the product is produced in must somehow be folded back into the company. The rest of the company may not understand the new product. Indeed it might be quite different from the company’s main products. Therefore there is a learning curve, while the new product becomes part of the stable.

The people who have created the new product also need to be folded back into the company. But while they have been outside the mainstream, they may have got used to a different way of working, a freer environment, a lack of politics or structure. To these people re-entering the corporate fall might be difficult. Indeed it might be easier to leave the company altogether.

Meanwhile, the people who remained with the company working on the old products are not working on the shiny new thing, they may become resentful of those working on the new product – especially if the skunkworks team are seen to be given privileges or better resources.

And there’s not forget one the points made by Arie de Geus which I noted a few days ago: it is not just the taking of decisions that takes time but the acting on them too. The people outside of the company have made all sorts of decisions, and when they returned to the company they expect those others to act on them – there will inevitably be a delay. Indeed, there may be a repeat of the learning curve.

Perhaps, one of the most famous examples of this approach was Xerox’s Palo Alto Research Centre – or PARC for short. Xerox set up a research centre on the other side of the country, stuffed it brilliant people and gave him plenty of money. The project succeeded, it invented most of the features we find in the modern PC.

But the project also failed, the team was so far removed from the main Xerox Corporation and the company could not usefully exploit their innovations. Still the researchers found a way, and many of them left Xeroxto found successful start-up companies in Silicon Valley, for example Adobe and 3Com.

So, on balance, I am not a fan of the skunkworks approach to innovation. If you want your company to be innovative you have two embed, within the company, and within the values.

There is a lot of hot air spoken about innovation. Indeed, there is probably more talk about innovation than there is actual innovation itself.

I started to get all excited about innovation on Friday, when one of my managers said:

“Allan, do you know anything we can do to improve innovation?”

Of course there is one obvious answer: 20% personal projects, its the 3M example – and now Google. Just about everyone seems to have heard this example so I’ll be brief in my comments: at 3M engineers are encouraged to spend about 20% (figure varies depending on who you read and which company it is) on “personal projects.” Some of these projects eventually make it to full products, like Post-it pads and Google News.

But are there other things you can do?

I was excited so I went home and started looking through some of my textbooks and journal archives, my question: just what do you do to produce innovation?

On the one hand innovation is just an extension of problem-solving, which is itself an example of learning. So doing innovation is firmly within the knowledge and learning agenda I keep banging on about. But on the other hand, innovation is so specific it is a subject in its own right.

Regular readers of this Blog will know I don’t have much time for “big brains”: I don’t believe that the CEO, CTO and a few managers can sit in the boardroom for six hours and come out with a new product. Most innovation is bottom-up.

Nor do I believe you can schedule innovation: Ever seen a project plan with a date pencilled in for innovation? No, you can’t timetable it.

So, how do you do it?

Looking at my books I find advice like: improve you ability to learn, trust your employees, organize your business structures to promote innovation, value innovation, align your HR policies (reward innovation and risk taking), don’t punish failure, and so on. These are all big, macro solutions, they may be necessary but they are not sufficient, you need something else.

You can set your business environment up to encourage innovation with these ideas, you can show people it is valued, but what do you do?

This is where the 20% personal project comes in. It is something you could do today. It is easy to see how you could get a new idea out of it – whether that is a product or process innovation.

A few months ago I was able to speak to someone who works at Google and they described how this works.

Engineers need to spend 20% of their time on a personal project. But many of them don’t know what to do, so most of them are open to suggestions. Meanwhile, the product managers have the opposite problem. They are identifying things the company could do, but without a prototype or proof of concept they can’t get any official resources.

So the product managers look around and find engineers who need projects. They then have to interest the engineers in working on their idea. If the project goes well they can then go official and ask for full project status.

(By the way, read my lips: No project managers!)

The trouble with this example, the 20% example, is the one everybody cites. It seems. When asked: “how do you do innovation?” People reply with a 20% example. What is actually happening is that this example is getting in the way of other ideas and examples of how you do innovation!

So, dear readers, the challenge for you:

what does your company do to encourage innovation?

I need your ideas and experiences.

In my last entry I wrote about The Living Company, there’s a lot I could say about this book that you’re better off going to it read yourself. It isn’t my intention to give you a review or abstract in this book buyer would like to share a few thoughts.

While these thoughts concern the role of the individual in the corporation at its most basic level it poses the question: Why do we work?

At one level it is an easy question to answer: we need to pay for our food, clothes, housing, etc. But there is a deeper level to this question and one that concerns the relationship between the individual and the company. We could rephrase this question as, what do I hope to get out of this job? With the emphasis on, I.

For de Geus and his Living Company profits are only a means to an end. Similarly, wages are only a means to an end. In working for a company, and in employing an individual, the two enter into a pact. The corporation promises to give the individual opportunities to further themselves and to grow as a human being, and the individual undertakes to help the company continue in his quest for survival.

De Geus explores this argument in depth. While he accepts that one size does not fit all and that in different firms things need to be done differently he is an advocate of the recruit early, retained the life human resource philosophy. Of course, this has its problems and he does discuss some, but these are discussed from the corporate side

I was left wondering what of the individual who does not get hired by such an enlightened company, is such a person condemned to work for “inferior” companies from the rest of their working life? I suppose I’m thinking of myself when I ask this question, when I graduated from university jobs were thin on the ground and I considered myself lucky to get a job with a 12 month fixed term.

And what of the individual who is unfortunately laid off from the corporation? And particularly when this occurs, halfway through one’s careers, how are they to return to an enlightened employment?

De Geus does consider the need for companies to periodically let people go. For him this occurs, not when a company needs to downsize, but when an individual can no longer grow. Of course, sometimes in a downsizing company there may no longer be the opportunities for individuals to grow. At this point de Geus actually starts to sound like Jack Welch.

Welch (Headline Book Publishing, 2001) also advocates a human resource policy based on individual development, of course, being Welch, he is a lot more hard-nosed about it and relates the policy directly to the bottom line of the company. He also advocates a pro-active policy of dismissing people who are considered to be in the bottom 10%.

This is all tough stuff, and maybe, just maybe, the idea that the company can no longer offer an individual opportunities grow and it is therefore best they leave the company, well maybe, this is just the sugar coating that managers can tell themselves so they can sleep at night, when the newly ex-employee is wondering where his next wage comes from.

Don’t get me wrong. I think these authors are making a good point, and I am very attracted to the idea that it is through work that we grow and improve as individuals, but I also see a potential for self-deception.

Interestingly, these ideas of growth and, shall we say, weeding out, sitting well with my blog entry of 12 October 2005 – Productivity & IT – US trumps Europe. Maybe this is just a simple case of statistics, if the company is to be above average. In needs to remove those below average and encourage those above-average.

And what of me on a personal level? As I’ve written here before, I am now a Product Manager, a recent change, and one that is giving me room for. Looking back on it and not sure many of the companies I have worked for have really offered growth opportunities.

There is a chapter in book one of Douglas Adam’s is Hitchhiker’s Guide to the Galaxy, where he describes the evolution of Vogons. I can’t recall the exact words, but he says something like

“evolution took one look at the Vogons and decided they weren’t worth bothering with, so the Vogon’s decided evolution was worth bothering with just on with it.”

I sometimes feel like that about my career! Some of those large, enlightened companies, took one look at me and decided they didn’t have a career for me, so I just got on with it myself.

Actually, I don’t think I’m alone in this scenario, I think many of those who entered the labour force during the late 1980s and 90s encountered the same situation. I like to think things have changed now but I don’t know.

Still for me, the wage is important, but so is the growth. And as I get older, the relative importance of growth increases.

Sitting on planes is boring, one of few advantages is that gives you a chance to read, and so it is that idea to read yet another book. This time the book is “The Living Company” by Arie de Geus – 1997, Nicholas Bealey Publishing.

This is a very good book, as one might expect from the title its thesis is that companies resemble living organisms. As a living thing the primary objective of the company is not to make profit but to survive. Profit therefore is not an end in itself but merely a means to an end, for without profit there firm cannot survive.

Arie de Geus is the author of a well-known Harvard business review article entitled “Planning As Learning” – if you have not read this it is well worth the $6.

As one might expect this book expands on this theme, the important point about planning is not produce a schedule that allow individuals to consider possible scenarios so that their thinking goes beyond a mere projection of the past.

Continuing on from this he argues that everyone affected by a decision should be involved in the making of the decision. On the face of this might appear to slow down decision-making process that is not the case. Because making a decision is only half the story, what is the key is made in the acting upon by involving more people in the decision-making process we ensure that action happens sooner.

It was only as I came towards the end of this book of the obvious occur to me. As regular readers of this blog will know I write Patterns, the originator of patterns, Christopher Alexander, calls on us to create patterns that live, in the same way Arie de Geus callers are those to create companies that live. To my mind there are obvious parallels here and further validate the use of patent theory when considering the business domain. Hopefully I’ll explore these parallels further in future patterns that are.

I’m in the USA this week – part business part pleasure – so its a good time to think about some of the differences between the US and Europe and the UK specifically. On this occasion I’m given food for though by a study from the London School of Economics Centre for Economic performance on growth in the USA and Europe.

The full report is available from the Office of National Statistics for free, and it has been reported in the FT (10 October 2005) – I’m sure it has been reported elsewhere too. I’ve only had time to read the FT story but I’ll try and read the full report in the next few days.

The report is interesting because it looked at the difference in productivity growth between Europe and the USA in the last ten years. It appears that the USA is increasing productivity faster than Europe. But the really interesting thing is: US companies in Europe are increasing productivity inline with the US rather than Europe. This implies it is management practices not local culture that is having an effect.

It goes on to attribute this to two reasons. First US companies make better use of IT. This might come as a shock, after all, US and European companies have access to the same IT resources – we can all buy the same Sun servers and SAP software – so it can’t be the IT itself it must be the way you use it.

(Actually, there is another shock here, there has been some doubt in the past that IT has actually delivered increased productivity at all but we’ll leave that for another day – take a look at material by Erik Brynjolfsson and others if this interests you.)

The second reason is something quite different: HR practises. Seems US companies promote their best workers faster than European companies and get rid of under-performers faster too. In effect they are rewarding the performers and filtering out the also-rans.

I can relate these ideas to what I’ve seen in US and European companies. So, where does this leave us?

Well the good news is there is gold in IT. The bad news is you can’t just “add IT” and make your problems go away, you need active management too.

If this comes as a surprise to you then good. Think about it. If this doesn’t come as a surprise to you then good, you now have the evidence.

Either way we have to ask: what are we going to do about it?