allan kelly

I first heard about Naked Objects (the Naked Objects website is here) in a presentation at the SPA 2005 conference and have been intrigued since. I finally managed to find time to read the book (Naked Objects by Richard Pawson & Robert Matthews) and I can recommend it. Naked Objects brings a different approach to software architecture.

The book itself is different. Like Tom Peters Re-imagine! it is printed so it looks almost like a children’s book with lots of pictures and glossy pages. In particular I like the use of case studies – I think we in the software professions don’t make enough of case studies.

Both the Naked Objects philosophy and the Naked Objects framework are described. I’ve only skimmed the stuff on the framework, this takes the form of a tutorial section on the Java framework and seems to make extensive use of reflection so it might be difficult to port to some languages.

Still, the Naked Objects philosophy should be applicable in other languages. The approach won’t work for all domains: it won’t work where the application is of a highly scripted nature, where customers must use the software directly (e.g. a ATM/cash machine) or where there is a lot of data entry. Still, that leaves an awful lot of applications where it could work.

Naked Objects makes one very important assumption up front: it assumes the software user is not a dumb automaton but actually an engaged problem solver. This also implies you trust your staff (and if you don’t then why do you employ them?) and that they know the problem domain at least as well as the software – probably better. This allows developers to concentrate on functionality rather than interface or interaction design.

Basically, the idea is to expose objects directly. The objects have user meaningful methods with which the user interacts directly. So, if you want to book a Taxi in New York you put the New York object together with the Taxi object. In some ways it is taking Object Orientation to the extreme.

I’m not sure how this all fits with good software interaction design as described by Alan Cooper (The Inmates Are Running the Asylum) – I think in a domain where interaction design was key you probably won’t use this approach. However, where you can position your users as problem solvers the consistent interface pays off.

Once you start treating your users as problem solvers you assume that: they know best how to solve the problems, rather than try and think of everything that could happen and provide a way of dealing with it you provide the raw objects and let the users work out how to do something. And with that a large part of your work goes away, making you more productive; and because you are treating you users as intelligent beings they get more satisfaction from work and do a better job.

Overall I think the Naked Objects approach is very promising. It seems a particularly productive way of working. Everything I heard at SPA and in the book persuades me that this deserves more attention than it is getting.

A friend comes to visit me and tells me he is considering doing PhD research on the gap between corporations stated policy on corporate social responsibility and their actions.

Tony Blair looses a vote in the House of Commons by one vote.

And in Northern Ireland the Independent Monitoring Commission suggests that while IRA leadership is committed to peace and politics the members on the ground are still holding weapons and engaged in suspect activities. (Report in the Economists)

What have these things in common?

They show what happens when the top of an organization – the leaders and managers – gets separated from the bottom – the workers.

Such a situation isn’t automatically bad, it can be a good environment for innovation and risk taking. Neither do we want a situation were managers are standing over workers compelling them to do something

But at the same time it does show what happens when strategy and operations become devoiced. Strategy may be the “helicopter view” but often it is the “expected helicopter view” – how do we know what is happening rather than what we want to be happening?

It is very easy for leaders to say “We will do X” but for the workers on the ground to ignore the message. Perhaps they’ve heard X, Y and Z in recent years and have started filtering our management messages.

How can we expect our leaders to lead if they don’t know and understand what the issues people on the ground are up against? Nor do they know the solutions the people on the ground are implementing, or whether they are compatible with the espoused strategy.

Nowhere is this truer than in the realm of knowledge workers – and in the knowledge workers I know best, software developers. It is said that a developer makes a decision every 15 minutes. But is this decision compatible with the strategy? Does it move us towards our goal?

Of course the developer can’t stop and ask the managers view every time, they need to make a decision – they probably don’t realise they are making the decision a lot of time. To ensure the right decisions are made the two need to have a close dialogue.

This dialogue can only happen if both sides make space and time for it. All too often software developers don’t know they need it, or avoid it because they would rather be coding. And managers frequently fail to make the time for it – perhaps because they are busy making strategy. There need to be occasions were both sides can talk and explore these issues.

The need to bridge the gap between the two groups in an organization is never more acute than when change is happening. My examples above discussed companies trying to take their social responsibilities more seriously, politicians trying to change the law and society and a terrorist group changing its mode of operation.

I once worked for a company that decided it should be CMM level 2. They hired some consultants to write the process. They appointed some “change champions” who then rolled out the process, and they audited the whole thing to make sure it was what they wanted.

Trouble was, the processes didn’t fit the work people did. For starters it was a “one process fits all” approach. Someone once likened it to “pouring quick drying cement on the rails of progress.” It wasn’t too long before the company saw software development as a problem, people were to be cut and work offshored. And they quietly dropped CMM along the way.

I think its also fair to ask if this is simply a break down in communication with the top of the company failing to communicate to the bottom, or whether, it is actually possible for those at the top to impose their strategy and vision on others by merely repeating the message. Perhaps, in order to be part of a vision one must play a role in formulating it.

It all reminds me Harold MacMillan, British Prime Minister 1957-1963. Once asked why his Government hadn’t achieved everything he set out to achieve he said

“Events dear boy, events”

Do you ever find your living out the examples in the books you read? I think I am…

Arie De Gues says:

“The fact is that the word strategy has tends to be misused. It should not be a noun; you should not ‘have’ a strategy, in the sense of a document which the organization follows. Rather, strategy should be a verb: strategy is something you do, rather than something you have.” The Living Company

(Now there is a lot I could say here about how this discussion of nouns and verb links up with Patterns but I’ll leave that for another day.)

Another strategy thinker, Henry Mintzberg, also rejects the idea that strategy is a plan. In the The Rise and Fall of Strategic Planning he made the case that strategy is not a plan you draw up and execute. He cited the case of the Canadian military, one study showed that they produced plans when they had nothing else to do. When they had something to do, like fight a war, they just got on and did it.

“the organization either planned or it acted; otherwise the two seemed unrelated. When the milirary has nothing to do, it planned, almost as an end in itself. …
But when the Canadian military did have something to do (such as fight in Korea), it threw its plans aside and acted.” The Rise and Fall of Strategic Planning

To my mind much of software design is like strategy. (And by design I’m talking about the internal architecture stuff). Having an architectural design is a something you might want to do when you have time but your design will always evolve. Who was it that said

“No plan survives contact with the enemy”

(A quick Google search offers von Moltke or Heinz Guderian.)

What is important for both business strategy and software architecture is that the whole team know the direction, the objective and are fully on board. The planning, the designing, only serves as a learning exercise, what is important is what you actually do.

In the “plan as noun” world you can’t really get this. So often a few chosen ones – maybe just one – devises a plan/architecture and presents it to the others and say “Here it is, all we have to do now is make it”.

Everyone can have their own copy, they may even get to “sign off” on it so they can be help accountable for building it but this method has a number of faults

• Arie De Geus points out: those who aren’t involved in creating the plan will take longer over actioning the plan
• Mintzberg points out that way doesn’t instil motivation, after all, your building someone else’s grand design not your own
• Mintzberg also points out there may be errors in the execution of the plan, of course, if your designers are good enough they will have anticipated these and allowed for them, they plan will be fool proof, or at least allow enough time to fix it
• Most of all the environment and requirements made on the plan change

So for me, I believe strategy and architecture are much more about discussion, I want to hear debate when I am planning. I want to use the whiteboard, I want everyone to join in at the whiteboard. When we produce something I want it to be shared by all. And I want everyone involved, those who will produce the product and those who will authorise it and allocate resources.

Maybe I’m sounding like a broken record, I’ve said much of this before in my essay “An alternative view of planning” but I’m drawn to these ideas again because of where I am right now.

As I said a couple of weeks ago my project is currently “stood down” – I won’t go into detail, enough to say I still have a job and a role but not a lot is happening on the project.

One of the things I’ve been asked to do is to “set a vision” and “create a strategy”. Thing is I’m a team of one, there is nobody to discuss this with, only myself. And instead of white boarding with many I’m going to PowerPoint the whole thing.

This is lonely and depressing. I end up running over the same old ground. In a couple of weeks I’m supposed to present (PowerPoint) something to some folks who’ll decide if we get to move the project forward.

The thing is: I’m like the Canadian army, I have nothing to do so I’m planning.

Are software architectures copies of the organizations that create them?

Often this is true but is it always true? And more importantly is it a good thing?

In 1968 Melvin Conway wrote a paper that discussed this topic. It has since been passed down as developer folk law that.

“If you have 4 developers writing a compiler you will get a 4 pass compiler”

Or,

“If you have 4 developers writing a GUI based system you will have 3 ways of doing anything (mouse, menu and shortcut key) – only 3 because someone has to manage the others.”

There is even a pattern by Coplien and Harrison (Organizational Patterns of Agile Software Development) of this name that describes the situation in more detail.

Trouble is, things are just more complicated than that.

What if your company is bought? What is the relationship between architecture and organization then? Or, if your development is outsourced? What if you are geographically separate? What if you adopt Extreme Programming?

And, have things changed since 1968?

In an attempt to understand the “law” and answer some of these questions Lise Hvatum and myself facilitated a focus group discussion at EuroPLoP 2005. The resulting write up from both of us is now online at on my website.

So what do I think about Conway’s Law?

Well, I don’t think Conway’s Law is a law, in that much I agree with Kevlin Henney, it really describes a force. And the name of the force is Homomorphism.

I believe Homomorphism is a strong force, I believe it is always present, I believe it was stronger in the 1960’s but it is still strong and most importantly it is self-reinforcing. I also think its the default architecture for most organizations.

I agree with Neil Harrison, in the ABC case study the organization changed from one structure to another and the architecture followed, they stayed within “Conways Law.”

The big question for me is:

• Which comes first: Organizational structure or Architecture?

Conway was right when he said that the design that occurs first is seldom the best. Question is: how do you create a better one when the existing one is self-reinforcing?

More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology – they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.

All too often technology companies respect those with technical skills and ignore the need for management skills, they reward those who are technical more than those with good management ability.

When I think of the really good technical people I know, myself included, sooner or later they all come to the point where they realise that to solve technical problems requires them to work outside of the technical domain.

Time fly’s, I still feel young but when I realised this morning that this time 10 years ago I was working on a project for Railtrack I felt a bit older. That project taught me a lot about how not to run a project, it also lead to a lot of thinking over the years.

In the mid-1990’s the British Government set about privatising the railway system. At the time British Rail owned and ran everything to do with trains in Britain. It was too big to privatise in one go and the Government wanted to bring about competition on the railways so it was broken up into many smaller pieces.

A set of Train Operating Companies (TOCs) where established to run the trains, and one company, Railtrack, was given the track to run. The BBC have plenty of stories on what happened to Railtrack, for example this one, but none of these talk about APLAN.

To bring about this vision Railtrack needed a new timetabling system, the old one kind of worked, it was a MSDOS based computer system (PROTIM) and lots of paper. This didn’t matter much because the timetable didn’t change much, just twice yearly increments. But for the new world of competition something much bolder was needed… and so project Access Plan, APLAN for short, was born.

By the time I joined the project in September 1995 it had failed once already and had been passed to a second software development company – Sema. At its height there where about 120 people on the project. The odd thing was that few of these where programmers: at most 12 C/C++ developers, 2-3 Visual Basic developers and 4-6 database DBA’s / SQL developers. The rest of the team was business analysis, testers (system and user acceptance), architects (who didn’t code and came from a COBOL background) and managers: lots of managers.

The project was priced on time and materials so there was money to be made. I was a contractor working on an hourly rate (6 days a week), there was my agent (adding 20-25% for themselves) and then Sema, with their own staff living in hotels and working on a T&M basis plus the a mark-up on the contractors. Railtrack was paying the bill but they where still owned by the Government so it was really the tax payer paying.

Just to make sure we all got the job done to a suitable standard we worked to ISO-9000. We had think process manuals and even thicker requirements, architecture, specification, functional specification and test plan documents. Unit testing happen religiously but it wasn’t automated. (This was the project where I realised that ISO 9000 was evil.)

The project was a “success” – it shipped code, Railtrack used the system to produce a new timetable.

The project was a “failure” – very early on the most ambitious ideas about train companies bidding to run trains had been dropped. Towards the end of “phase 1” even more features where dropped and much of the final timetable was produced on paper.

Trouble was: who was going to tell the Prime Minister the system was a failure? Sure everyone at the code-face knew things weren’t going to work like people envisaged, even the first line management knew that. But the message was watered down as it got passed up the chain. If the CEO of Railtrack or John Major knew the true extent of the problems the privatisation couldn’t happen.

And if it didn’t happen when it was scheduled to happen well… everyone knew that Tony Blair would be Prime Minster in a matter of months so it might not happen at all. So the project was a classic Death March.

“Phase 2” was cancelled before it even got started. Yet with the bulk of the system in place Railtrack had to continue to use it. I even rejoined the project two years later to develop parts of it – but that is another story.

Of all the lessons I learnt on this project two stand out.

Lesson 1: Inside every large project is a small one struggling to get out

This project created its own size, more people required more people. It was T&M so there was an incentive to add people. We could have lost 80% of the people and achieved an awful lot more than 20% of the work.

Yes, 20%, 30% or even 40% would not have been what the Government wanted but that leads to lesson 2.

Lesson 2: Some projects shouldn’t be done

I often asked myself: what would I do to fix the project? By the time I was on the project it was already too late.

I often asked myself: how would I have run the project? I knew a lot of techniques to improve things, and I know a lot more now, but I don’t know any that could make this project a true success. The only conclusion I can give is: the project should never have been done in the first place.

Some projects are too big, too complex, too ambitious, too time constrained that they should not be attempted. As a supplier you should not accept such projects.

Of course there will always be someone, somewhere, who given enough money will attempt it but these are actually the worst people to attempt such a project. If the customer will not listen to advice and does not realise what they are getting into it is their own problem.

No, if someone comes to you with such a project you should try to persuade them of a better way: extend the time allowed, break the project into chunks, reduce scope. Infact, this is more than just a “should” it is your duty!

But if at the end of the day you can’t persuade them to accept an alternative don’t do the project: you don’t need the money that much and your staff will thank you for not making them do the project.

In ten years a lot of things have changed: Neither Sema or Railtrack exist any more, I’m not a contract programmer any more, our business models where not sustainable. Unfortunately death march projects still occur.

I’ve used some of the Christmas time to rush through to the end of my latest read – Good to Great by Jim Collins (Random House, 2001). I’ll admit upfront I wasn’t going to read this book but the senior management at my company have been reading it over the last year so I thought I should join in too!

Its easy to see why the book has been such a big seller. Its easy to read – short and a chatty style – and it makes you feel good, it suggests you do nice things in your company not nasty things.

Personally I don’t find it adds very much to the discussion that hasn’t been said already. Yes it introduces a few new metaphors (the Hedgehog concept and the Flywheel) but nothing you can’t find elsewhere really. In part this might be because the book is a “prequel” to Jim Collins and Jerry Porras’ Built to Last.

Yet I found the book reminded me more of another book, The The Living Company by Arie De Geus (1999). This should not be a surprise because De Geus discusses the similarities between Built to Last and Living Company so we should expect a few.

Unfortunately Good to Great lacks a good bibliography or further reading sections. This seems to be a common failing in many business blockbusters, they strip out the endless referencing that academics love and is necessary for hard research and journals to make it easier to read but at the same time you loose the context of where the book fits in or where to go next.

For example, Collins tells us that his Great Companies “confront the brutal facts” but doesn’t discuss how they do this or why they ignore them. Arie De Gues does, he explains why companies ignore known facts and what they can do about it – his solution is to “create future memories” by “planning as learning” and “scenario planning.”

(One could also refer to Pfeffer and Suttons Knowing-doing Gap on this subject but again Collins doesn’t.)

One more tiny example I have to put in so I can recommend a another good book: Collins mentions the importance of project post-mortems but that’s it. Norm Kerth’s Project Retrospectives goes into great detail on how to do this.

Why bang on about referencing? After all, references do make the book harder to read. Well, references add credibility for one. Second, I’m unhappy when an author seems to be claiming all the ideas for themselves – not that Collins does, but some other authors do. But perhaps the most important reason is so you can learn more about a particular issue.

Anyway, enough about referencing, what does this book say? The big themes are:

• No single event that creates a great company, not hiring a particular CEO, discovering a technology or launching a product. Its emerges over time.
• Get the right people, get shared values and the rest will come
• Confront the brutal facts: most companies fail to pick up on the important, life threatening or enhancing, facts and events.

Put all this together I found the book a pretty convincing argument for the argument that business strategy is more emergent than planned. Collins more or less says that most companies didn’t recognise their strategy until they were in the middle of it. Again, overtones here of Henry Mintzbergs’ The Rise and Fall of Strategic Planning but Collins doesn’t tell us this.

So if your looking for an easy read then this book is worth the money. If your looking for more depth then I recommend you read The Living Company . Among other thing both discuss:

• Getting the right people, and getting rid of the wrong ones
• Develop your people, they are there for the long term
• Quality discussions between people
• Recognising and acting on facts and events

In fact, one of Collins interviewees, at Kroger supermarkets, actually says “the company had a will to live.”

On Wednesday night I was out drinking with ACCU members in London. For those of you who don’t know the ACCU I’d better explain. It is an association of professional developers, for my money the members are among the best software engineers in the world. Great people, if you ever get the chance to hire an ACCU member then do so, they share a passion for software development, improvement and learning.

But, as I’ve said here before I am no longer a software engineer – I am a Product Manager. And I got my legged pulled a bit on Wednesday night for that!

Perhaps I should give up my ACCU membership and my association with so many engineers. Certainly I don’t find articles in the ACCU magazines as interesting as I did – too many curly braces! – my interests have changed.

Now there is no rule that Product Managers can’t associate themselves with such groups but there is no such thing as a free lunch, if I am to embrace my new role and identity I need to give up some stuff. Every time I associate myself with my old role I’m not embracing the new.

But actually, I am still a software developer, I’m still helping develop software, I’m just doing it differently.

I’ve always preferred the title Software Developer to Software Engineer. Two reasons really, firstly, I’ve always had my doubts about how much engineering really goes on when writing software. Secondly, and more relevant here, I’ve always been aware of the other stuff that goes on.

Developing software isn’t just about cutting-code. Its about customer requirements, their problems, packaging, delivery, marketing, solving problems and introducing change.

Now I’m a Product Manager I’m concerned with: My customers, their problems and what software can do to solve their problems (which means change.)

So I’m still developing software but I am at a different place in the food chain.

I’m not really that unusual, a lot of product managers have a engineering background – and a lot have an MBA so really I’m not unusual – I’m dangerously close to being typical!

In some ways my engineering background might be a disadvantage. If I don’t jettison some of the old identity – the bit that wants to engineer and change code – I risk focusing on the wrong things. It is so much easier to stay in the comfort zone of what I have done before, to hide behind the technical rather than focus on the customer and do new things.

Failing to focus on the customer is probably one of the oldest (the oldest?) failure modes there is – both in software and in business generally.

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.