Ten years since Railtrack

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.

Websites are getting worse

Time was when the software was just in your PC. Now it is everywhere – and I’m not even talking about the embedded stuff that you don’t see – like the engine control system in modern cars. We see software everywhere – well not quite everywhere I believe there are many more opportunities to make it omnipresent.

We have lived with bad software interface design in video recorders and microwave ovens for years but as more or more companies add web sales channels we are increasingly confronted with bad web interface design.

Often these systems are commissioned and built for companies with no understanding of software development let alone interaction design. Worse still, it seems that many of these systems are built by companies who have little understanding of software development or interaction design.

The fact that you can do it isn’t enough, you need to be able to do it easily.

For example, late last year we decided to go skiing for New Year. When it comes to holidays I am a late booker – the idea of booking two months in advance – let alone six – is foreign to me.

Our first thoughts were for a package holiday, going to the website of any holiday company my first question was: what is available? But on those sites before you can ask what is available you have to specify country, resort, type of accommodation and dates.

Dates are a stupid idea for a package holiday because there are only one or two days during the week when you can start your holiday so why let you choose from everyday of the week?

These sites are just not well designed – a problem any reader of Alan Cooper (The Inmates Are Running the Asylum) would recognise. In fact I don’t think these sites have been designed at all. Nor do I believe that the software is owned by any product manager type person.

Nor do these sites make it easy to tell the owners about the problems you encounter, contact details are hidden away, telephone numbers lead to automated systems and when you do speak to a person they know nothing about the web site or who to pass comments onto.

The real problem is for the companies that own these sites: how many customers will abandon the purchase because of a poor site? How many customers will think the product they want is not available? And how many customers would be prepared to compromise and book if only the site would give them the option? Of course some sites go to the other extreme and give you too many options none of which is quite what you want.

Some of these companies will be betting their future on the web sales. No wonder package holiday companies are slowly dying, people want to book online but the website getting away.

Its not just holiday companies: the international telephone provider we use has one of the worst sites ever, you need a password (you can’t change it so I always forget it), and a PIN number (which I always forget too), the menus aren’t intuitive… I could go on. Actually I’m giving up on it won’t let me put a new credit card number in.

These sites exist in every where. The facts are simple: If your site is hard to use you will loose customers.

Yet in all this chaos there lies opportunity: an opportunity for some company to do it right and steal the market from the rest. And once you’ve got the site right then you can start to add features online which would not otherwise be possible – need a taxi to the airport for your flight? – book it at the same time as your holiday.

The world is plagued by bad websites and I see the problem getting worse before it gets better. Eventually a few category killers will emerge – like Amazon, Expedia and travel losses it who can do it right.

Maybe a good start would be a few more interaction designers and product managers on the case.

2006 arrives with Snow and Advertising in the US

I welcomed in the New Year with some skiing on Colorado – mainly in Beaver Creek but a little in Vail. Snow was great – I’ve never had so much powder in my life, in fact the main problem was probably too much snow.

Beaver Creek is only about a third the size of Vail, which is itself a lot smaller than the big French areas like Courchevel. One thing was for sure, Beaver Creek and Vail are not places to go if you are on a budget – but then few ski resorts are.

The US is long way to go for skiing – for me at least – but it is fun. If you feel like giving it a try then I’d happily recommend renting a Condo for a week – something like renting your own Chalet. We stayed at Beaver Creek West – not cheap but well worth the money.

One of the things that interests me about the US is: how is it similar to Europe and how is it different?

I’ve written a bit about this before – see 12 October, Productivity.

Well, another way the US differs from Europe is: branding and advertising. Ever looked at the names of businesses in the US? Many of them are “Best Sandwiches” or “Superior Skis”, maybe “Super Bar” – people aren’t modest in naming their businesses and they aren’t shy about telling you about them either.

Whether it is direct mail, advertising bill boards, posters or referrals American businesses like to get the message out that they are there. And they don’t stop at telling you once, after all you may forget, or it may not register the first time. Nor do they mind telling you that they are better than the competition.

Europe seems to be more reserved on this count. We sometimes want to hide our businesses, or we think that putting a single poster up is enough. And as for competition, we kind of hope that you don’t know about them either so why draw attention to them?

I can’t prove this comment in any great detail although I have seem some evidence recently in Buzzmarketing – a book I’ve only had a chance to browse not read – but I’ve observed this many times.

There is an exception though: the public sector. The Federal, State and Local Government don’t seem to get this message. Even when it is something important – like immigration procedures. They still work on the “we told you once, now its your responsibility” model.

In the US business knows: if you tell people you are there, and you make it easy to do business then you will get customers. US Government is a little bit ashamed that it exists at all and doesn’t see the need to be easy to do business with – for example, have you ever tried to fill in Green I-94 Visa Waiver form? Its almost impossible to get it right first time.

As I find them I’ll blog some more differences between the US and Europe, maybe we can get some insights. In the meantime if you have any of your own please add them, I’m interested to know what others thing.

Book review: Good to Great by Jim Collins

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.”

Product managers are software developers too!

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.

Time is the enemy

Companies often boast about their “flat hierarchy” (and yes that term is something of an oxymoron) but it seems a flat hierarchy is deemed to be a good thing – although the reasons why this is so seldom seemed be spelt out.

I think they are supposed to be good because they speed up decision-making – the idea is that are not so many middle managers to go through to get decision.

And they are good because it allows those at lower levels to have their voices heard. A flat hierarchy allows everybody talk about their ideas to others whether they are more senior less senior or just the same level as yourself.

Trouble is, without those intervening layers there is more work for those of the top to do.

Suppose we have nine workers and each reports to one of three managers. And suppose those three managers in turn report a one manager. Each middle manager can spend one quarter of his time with each worker and the remaining quarter with his manager. And the manager the top has a little bit of spare time for external activities. Now if we take out that middle layer the manager at the top has less than one ninth of his time with each employee.

Don’t get me wrong and not in favour of big hierarchies and middle managers necessarily, all I am saying is that no point in having a flat hierarchy if people hierarchy don’t actually have the time for conversations and discussions. You have to allow time.

So there may be one level between you and the decision-making but will you ever get his time to make the decision? And when you need a decision or conversation will you get the time when you needed it?

Of course managers, wherever they are in the hierarchy, face time pressures. Big decisions need to be made: strategies need to be invented, deadlines need to be set, projects need to be managed and customers need be entertained.

But what about people who report these managers? Of course there is always next week to talk to them – isn’t there? – External always seems a trump internal.

The hierarchy may be flat but if managers don’t have time it makes no difference whether your hierarchy is flat or deep.

In the first case I’m thinking of giving your people time to help them develop. I said it before and I’ll say it again:

“In my management philosophy the number-one job of all managers is to develop your people.”

But it goes beyond this.

How do manager know what skills, talents and experiences their staff have if they don’t spend time getting to know them?

So often the conversations that matter in the company are the ones that happen outside of meetings. But how will a manager know about these conversations if he spends all his time in meetings and talking to other managers?

On a technical project (yes, I am thinking specifically of software development) the people who do the work of often better positioned to see problems coming. Kind of an “engineers intuition” if you like. But if the manager is frugal with his time how will he ever have the time to talk these people and know about potential problems?

Also it is a matter of simple decency. People no matter where they are the company hierarchy, have a right to be listened to; they deserve to be listened to. And when they listen to they get a sense of fairness, their opinions have been heard and considered. They are more likely to buy in to the company strategy if they feel they have been listened to and treated fairly.

Often it is when the pressures are greatest that a manager needs spend most time with his people. For example, a manager introducing it change, or trying to win a big deal, or accelerate the process, really needs spend more time with his people understanding how it affects them. Unfortunately, it is just these times that managers often feel the need to be elsewhere.

Of course it is not only time starvation that creates a chasm between managers and workers. Separate cultures often develop with managers talking to managers and workers only speaking to workers. Over time managers don’t feel the need to attend meetings and discussions with workers and it becomes a vicious circle.

And the same is true for workers. I’ve lost count of the number of times somebody has told me “they don’t want that” – but who are they? And when you do asked them, they are often quite open to ideas. When communication breaks down people fall back on assumptions and stereotypes.

In short managers can get disconnected from those they manage. This is a bad thing for both sides.

So if you are manager please don’t this happen to you. Take some time out of your meetings and the decisions to talk to people and find out what’s going on and how they feel. After all these people are your most important asset – don’t they deserve some of your time?

And if you are worker? Well, I encourage you to keep asking for time, keep trying to engage with your management. Please don’t fall back on assumptions and stereotypes, keep asking questions.

The Inmates Are Running the Asylum by Alan Cooper

Time for another book recommendation. I’ve just finished reading The Inmates Are Running the Asylum by Alan Cooper. This is a passionate call the software to be more usable.

Cooper’s argument is: software is not designed for usability and as a result much software is difficult to use and unattractive – he calls this “Dancing Bearware” – people use it because they have no choice.

Well designed software on the another hand is a joy to use, is perceived as being more powerful (even when it has fewer features) and creates a customer loyalty. Consequently this is good business not just good software.

(When Coopers speaks of software design he is talking about usability and anaesthetics – the same way we mighttalk of furniture design – not software design as programmers think of it with URL charts and object diagrams.)

Not only does he advocate better software design but he gives a selection of tools to use for design. This is interesting because many of the tools described are equally applicable to the work of Product Managers, e.g. personas, scenarios, etc. So the book is actually very useful to Product Managers even without the design discussion. Having said that, every Product Manager should have an awareness of the need for good product design and should read this book for that reason alone.

Programmers too should read this book. On casual reading you could get the impression that he does not think much of programmers, but in truth he is simply pointing out that they are not the best people to design software interaction.

It is hard to disagree a Cooper – he makes a very strong case. Where I do have an issue is his suggestion that we engage in the long design process upfront. Of course he is advocating we design the usage of the software, which is quite different to the way we normally talk about big upfront design of software. Still I worry that the same problems occur when we engage in long design periods without actually producing anything.

It may also be difficult to reconcile his design period with the incremental delivery models found in Agile and Lean techniques. However I’m sure we can reconcile these points of view as long as we remember to keep things simple and avoid waste.

After reading this book I’m left wondering why every software development project doesn’t have its own designer. It makes good business sense: think iPod. Of all the companies I’ve worked for only one had a software designer – and he was cut in the first round of redundancies.

So if you are Software Developer this book is well worth the read. If you are Product Manager this book is a must read. And if you are Software Development Manager who can’t understand what all the fuss is about, or why your programmers can’t just develop the user interface as they go along, then buy this book now and read it tomorrow.

India running out of IT staff?

I’ve not said much about “offshoring” in this blog to date. In part that has been because while I broadly agree with the theory behind it most of my experience with it (e.g. call centres in India) has been very negative.

The other reason has been a deliberate decision to avoid a controversial subject. Controversial because those who read this blog with a business hat on see it differently from those who read it with a programmers flat-cap on.

However, a report in today’s FT caught my eye so its time to talk about this.

According to this report India will have a shortfall in skilled IT staff by 2010 of 500,000. This will come as a surprise to some but its something I’ve suspected would happen for a while. The report goes on to say that only a quarter of graduate engineers in India are actually employable by the industry – I wonder what the figure is in Europe and the US?

Add to this infrastructure problems (lack of office space, roads, power, airports) and suddenly the Indian IT sector doesn’t look that rosy.

So does this mean IT staff in the west can relax? Probably not, but there is no reason for panic.

Personally, I’ve never bought into the “India will take all our jobs” argument for a number of reasons…

  1. Not all jobs are suitable for offshoring: as rule of thumb, the closer you are to the customer the more difficult it is to offshore your work. Some banks pay IT staff a premium to sit next to traders on the dealing floor, if 50 meters makes that much difference think how much 5000 kilometres makes.
  2. Offshoring is not risk free: for a start you can’t see what your people are doing let alone look them in the eye. Then there are the external risks, for example, India nearly went to war with Pakistan a few years ago – and both are nuclear armed. Sure we had bombers on the streets of London this year but we’re talking an order of magnitude.
  3. Law of supply: India (plus China, etc.) may have a lot of people but how many of them can actually work in IT? And how many of them are really good? Over time the price of good people will increase making offshoring less attractive. Already Indian call-centres suffer from high staff turn over rates.
  4. Law of demand: if there is a vast movement of jobs from Europe to India we should expect to see prices in Europe fall, again this makes offshoring less attractive.
  5. There are only a few good programmers: It is widely accepted that the best programmers are few and far between. The best are 10 or even 20 times more productive than the average. This cuts both ways: if you want to employ the best can you afford to ignore those who live in Bangalore not Birmingham? And, if they are 10 times more productive then surely you can afford to pay them 10 times more irrespective of where they live?
  6. India needs developers too: As India develops its own demand for IT people will increase – Indian businesses need IT staff too – the faster we help India develop the faster demand will rise.
  7. There is more than enough work to go around: as my last point suggested this is not a zero-sum game. IT has a long way to run yet, there is a lot more software to be written, the more we write the more opportunities we see.
  8. IT is really about change: You might be able to write software in 5000 kilometres away but you can’t follow through on the corporate change programme from that distance. Introducing change has to be done locally. Western companies will increasingly look for IT staff who understand that IT is not the end but only a means to an end.

Does all this mean your job is safe? No
Does all this mean my job is safe? No

It does mean that as an industry there is plenty of work to go around.

Finally, and this should really be the first point: It is morally wrong to stop work going to India or elsewhere. To stop work moving would be like saying:

“We in the rich west are happy to send you aid for development, and when you are hit by an earthquake, famine or Tsunami. But, we want it to stay that way. We don’t want you becoming rich yourselves.”

In the long run it is in our interest to see India develop. They are a market too. And a prosperous India will be a safer India (no nuclear wars) and a more environmentally friendly India.

The Dog and Duck is closing

Opposite my house there are a few shops. Every few months one or other of these closes and every few months a new one opens. It keeps the place dynamic. The last one to open was an up-market flower shop since when my girlfriend has received noticeably more flowers!

Just before summer started one of the old shops was re-christened “The Dog and Duck”. For the few days between the name going up and the shop opened we wondered: How can you have another pub there? For those who don’t know, “Dog and Duck” is pretty common English pub name so it seemed there was to be a new pub.

Now my road already has 3 pubs it, with another 3 off to the side and a further 12 or so within five minutes walk – this is London after all. It all seemed a bit strange, and after all, there had been no planning permission requested for a pub.

When it finally opened the Dog and Duck turned out to be a … well, I still don’t know what it was/is selling. Some T-Shirts with the Union Flag or pictures of BritPop singers, some post-cards which would seem more at home in a design museum, and other stuff which to someone or other probably seemed “designer” or “fashionable” or even “stylist”. Personally, I just called it a BritTat shop.

Nothing it sold was actually useful, the shop may have be able to sell to tourists or Oasis fans but not on a secondary road in Acton.

The fact that I can’t tell you what it sold is half the problem. Its location is the other. Both conspired against it but the root problem was: Identity.

The shop didn’t have an Identity that could be communicated easily – look I just tried! How are people to find out about this shop? How are they to tell others?

Yes the name was very clever, and the contents where probably clever to somebody but they failed to communicate to anyone what the shop was. So its no great surprise it is closing down. (Actually, my money was on the Dog and Duck being a coffee shop, now that would have been clever.)

Businesses need identity as much as people do. They need to know what they are about. The employees need to know what the business is about. What do you say when someone says “What does your company do?”

This is more than just branding. It runs deeper. It is about the soul of the organization. I know a product company that is adding services to its line up. The intention is to help sell more products, and very conveniently services make good money so it all helps growth. But this company is a product company; its identity is as a firm that produces physical products which people buy not as a service organization.

It is not wrong for this company to add services but it needs to realise that it is changing its identity. How will its employees, its competitors and customers relate to it in future?

Identity can constrain people and organizations, it can stop them moving outside of their comfort zone but it also gives them a base, and operating system if you like, one that helps them navigate the world and make sense of it. Identity change can be a great opportunity for growth and learning but it is also risky.

So identity is good, please experiment with changing it, step outside the comfort zone, just make sure you don’t loose it in the process or you’ll end up like the Dog and Dock.

Learning to be a product manager

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.

%d bloggers like this: