FOLLOW

FOLLOW

SHARE

Why your Product is not a Project

And why a watermelon isn't a hammer !

29Jan

There is an extraordinary anomaly in the business world, which it seems very few are aware of, but which to anyone with a logical mind must surely seem rather strange. The fact is that whilst firms invest vast amounts in their sales and business development processes, they spend very little on their product management processes. To give that statement a little colour, a Gartner study recently showed that whilst $23 billion was invested in CRM tools for sales teams in 2014, 96% of product managers were left with MS Office as their main tool. Whilst some love, and some loathe, Microsoft’s software it is very clear that this was not designed to service the needs of the product manager, so this use is not by choice but simply the only option available.

Let’s take that situation and look at it from a different angle. What this, apparently, says is that firms would rather spend their money on teaching their sales teams to work more efficiently to sell average products, than spend that money on actually creating great products in the first place which sell themselves. Okay, so no product is actually going to sell itself, and the sales team will still need to earn their corn, but better products result in a much more pleasant experience for the sales teams too, as no one wants to bash their head against a wall trying to sell unattractive products.

The problem in the past was that there simply weren’t any tools available to make product management more efficient, which was a situation that I had also found myself in as a potential buyer in a global financial services organization, but over the past couple of years that situation has changed dramatically. The good news is that firms are increasingly aware that they need to improve this area of their business, and a 280 Group survey found that 60% of the firms that they spoke to had plans in place to address this challenge. That still leaves a fairly alarming 40% who have not realized their exposure yet though, and those firms would do well to focus their attention on this in the very near future.

However, as these firms, the ones who have recognized the problem at least, go into the market to look for a tool a quite surprising trend has appeared. The teams who are going out looking for a solution have started to muddle product and project management solutions – just two letters different, but an absolute world apart in terms of their capabilities. I should take this opportunity to apologize to those firms who I have been speaking to about this recently, as they are certainly not the only ones who have fallen into this trap, but their situations have really brought home to me how big this problem is. The blame may also fall at the feet of those of us who offer product management solutions, perhaps for only bringing them to market comparatively recently, and also possibly for not having marketed them broadly enough. However, the onus is squarely on our shoulders to explain why they differ so much from our project management relatives.

Perhaps it would be wise to spend a little time first expressing what the needs of the product manager generally are. To express this, I’m going to borrow from an article in Product Fuel’s blog, which I think sums things up well. Amongst the key items they highlight are:

- Prioritization : Using data to make decisions, short versus long term, and balancing needs

- Road Maps : Communicating the product roadmap, particularly to executives and colleagues

- PM Job : How to be a product manager, when you don’t actually have any experience

- Upward management : Managing expectations, delivery dates and strategy changes

- Decision making : How to make them with limited data, and storing input from others

These items are all absolutely critical, so having a tool which doesn’t address these needs well will defeat the object of the exercise. The aspects above relating to the effective use of data, combined with a transparency that allows the right people to have access to the right information at the right time, should be a relatively obvious need where the question is just around how best to achieve it.

However, the aspect that I would particularly like to draw out is the one relating to actually being a product manager. The recent 280 Group report showed that 56% of product managers thought that their own product management team skill levels were 'average' or worse. The same report also highlighted that 52% of product managers did not have a clear product management process to follow. Whilst that may surprise some people, it would appear to be an accurate assessment as, given the lack of investment made in product management tools until now, you can safely also assign a similarly low level of investment in product management training. The critical factor, though, is that you can actually maximize the capabilities of an under-trained, or under-experienced, product team through the use of a good product management tool, a clearly structured product management process, or better still a combination of both. Using these elements will not only provide a clear guide to your product managers of what you actually want them to do, but will also allow them to safely gain experience and build understanding of the role whilst in the job.

So, to go back to the question of why a project management tool shouldn’t be mistaken for a product management solution, there are a couple of very fundamental reasons that are highlighted by the above points:

Full Lifecycle

A project management tool, by definition, takes you from a point where you haven’t got something (or haven’t done something) to the point where you have. So, if that is building an extension on your house, creating a response to a regulatory need, or planning a wedding, the requirement is very much the same. There is something that you need to do, you plan how to do it, you carry it out against that plan, and then you tick the 'completed' box once you’ve done it. However, that is not how a product works, because the point at which the product actually starts to perform (or not) and hopefully generates some revenue lies beyond the launch. That is where the really interesting stuff happens, and when you see whether your projections were accurate, whether your client assumptions were correct, or if your return on investment timeline comes to fruition. To adopt a project management approach here would be comparable to saying that life isn’t interesting after birth, which I’m sure most of us would disagree with.

Comprehensive Evidence

The project manager has a process to follow, and so is naturally driven by dates or timelines. The critical path is all important, with the pressure being on ensuring that deadline slips are avoided, as that would impact the delivery date. Now, I’m not going to say that timelines are unimportant to the product manager, as many as under extreme pressure to hit a particular launch date. However, it is the balance of importance that I’m highlighting here. For the product manager, documentation and evidence is all important. So, whether that is the evidence backing up that the client in Switzerland really will buy a small cap technology fund, or that the legal department have signed off your prospectus document, or that your office head in Hong Kong is comfortable with the fee schedule quoted, or perhaps that you have considered all of the elements around client suitability that the regulator has recently enforced, you need to have it stored in a safe place that is easy to access. A good product management solution will provide your product managers with this capability by acting as a documentation repository, showing when changes have been made to each particular document, and recording who it was who made (or approved) these changes. A project management tool will be unlikely to get anywhere near capably meeting this need.

Consistent Process

Perhaps my bravest, and probably most controversial comment, would be that a project management tool cannot match a product management tool when it comes to process. Not when it comes to meeting the needs of the product manager at least. You may rightly pull me up on my earlier statements where I highlight the focus on timelines and delivery as the key attributes of a project management tool, and you would be right to do so. However, this is a highly important area where a cautious balance of flexibility and structure are needed to service a product manager’s needs. To prove this, it is important to remind ourselves of the earlier report where many product managers were shown to be under trained and lacking in clear processes.

So, imagine the world where several project management tools, and a couple of the academically created product management tools, approach this with a solution of extreme flexibility. What often happens there is that the 'blind lead the blind', as each (potentially inexperienced) user embraces the ongoing flexibility of the tool to create their own workflow, which works for them, but pays no heed whatsoever to the various approaches that their colleagues have taken. If something changes, a date moves, or you think of a new review point to undertake, you can simply change your workflow to suit your own situation. That may well work for a particular project, which is running relatively independently from other projects that may be underway, but for a product management team this inconsistency can be disastrous. The best product management solutions understand the practical considerations, which are critical to effectively managing a product team. So, they will allow the organization the extreme flexibility at the initial point where they are creating their workflows and processes thereby allowing them to meet their corporate needs, but then be able to become rigid and structured when rolled out for use by the wider group. That then ensures that the product team is working to a consistent model, can be assessed in a balanced manner by the management team, and provides the guidance that a team of mixed capabilities requires to be successful. The model must allow the good product managers to deliver to the best of their abilities, whilst also coaxing the less experienced down a clear path that will both help them to build their experience and also meet the needs of their company.

The product manager has one of the toughest roles in any organization and, ironically enough, is also the person at the very start of the process who generates all of your company’s revenue. They are tasked with generating the big new ideas, nurturing them into viable products, launching them into the market, and then critically responding to the ever changing landscape that their product needs to thrive in. In the past there had been a reasonable excuse for not providing them with tools which would help them to do their jobs, because these tools did not really exist. However, in the modern competitive world where they do now exist, it is absolutely essential that these individuals are not only given tools, but that they are given the right tools, ones which were specifically built for the job in hand. Otherwise we’re effectively using a watermelon to bash a nail into a plank of wood – it might work to some extent, but there are definitely better ways of doing it!

Comments

comments powered byDisqus
Communication small

Read next:

Shouting the Innovation Message (Finally)

i