Blog article
See all stories »

Why your Product is not a Project

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 organisation, 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 maximise 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 organisation 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 are 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 organisation and, ironically enough, is also the person at the very start of the process which 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: (11)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 07 January, 2016, 10:55Be the first to give this comment the thumbs up 0 likes

As a sales, marketing and product management professional in B2B tech:

  1. CRM has reached its current state of presence and revenues after having been around for over 20 years.
  2. Besides, CRM never really helped sales people sell more / better. It gained traction because it helped CROs to keep a better track of whether their sales people were selling more / better.
  3. The hierarchy in product is somewhat flat compared to sales. While the CPO title has started becoming visible of late, especially in startups, it's really just an upgrade of the product manager title. Ergo, product management software lacks the positioning hook that CRM enjoys.

That said, with the proliferation of product management software products in the recent past, we can expect greater adoption of this genre of technology in the next 10-15 years. 

A Finextra member
A Finextra member 07 January, 2016, 18:48Be the first to give this comment the thumbs up 0 likes

Thanks for the comments, and you raise some interesting points. I certainly can't argue with your first one, albeit the invested figure of $23bn into CRM (at an annual increase of 14%) is still something that I find staggering, particularly when compared against the almost total lack of investment in product tools.

I'll leave it to the guys from etc to fully argue versus your second comment though. I think the evolution of the traditional CRM system has been pretty extraordinary, and it is a long way from the old "have you hit your targets" tracker that it used to be. You just have to look at the vast range of add-ons that are now available to assist in intelligence sharing, the sale itself, contractual processing, and post-sale support. I would recommend a visit to your nearest Salesforce world tour event (if you haven't already been) in order to fully understand where their journey has taken them - it certainly surprised me !

Looking at your third point I would suggest, though, that the hierarchy aspect is pretty important. We have been working with product teams in financial services, tech, manufacturing and pharma, which has shown us that the vast majority have at least three levels of hierarchy. (ie Product Manager, Line Manager, Head of Product etc). The top person in this tree also needs to be heavily involved in the strategic discussions at Board / Exec Committee level, so being able to report on the progress of the product team at any point is essential, as is the ability to accurately allocate budget to the best possible initiatives. Given that the regulator is now interested in how you went about creating your products and the considerations made regarding client suitability, your management team has a much stronger motivation to dig into the detail of their offerings. All of which makes information transparency across the vertical team, and also out across several horizontals, extremely important.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 08 January, 2016, 08:28Be the first to give this comment the thumbs up 0 likes

I've helped create CPQ, CEM, DAM and many other CRM addon products, so I know how they help the salesperson. However my comment was targeted exclusively at CRM, not addons. Wonder if the SFDC guys know this but the key GTM theme for many of these addon product vendors is to go to existing CRM users and tell them, "sorry if you thought you'd get this functionality from your CRM, actually you need our addon product for that".

Well, if there are so many levels in the product management hierarchy and compliance requirements in your target market, that would surely help accelerate the pace of adoption of a product management software. Best wishes!

João Bohner
João Bohner - Independent Consultant - Carapicuiba 08 January, 2016, 13:29Be the first to give this comment the thumbs up 0 likes

Great article to clarify what is a "Product" and what is a "Project"!

As I'm developing an Architecture for Infrastructure "Enterprise Information Governance" for banks, it caught my attention.

Although it is very clear what "Product" means, a question mark appeared in my head.

I explain and would like @Bill and @Ketharaman give us feedback about the subject:

A shoe manufacturer has the shoes as its "Products". He can innovate their "Products" creating new kinds of footwear, improving ergonomics, etc.

The same applies to a car manufacturer, where its "Products" are cars.

This also applies to services and utilities providers, where its "Products" are Water, Energy, Communications, etc.

How about the Banks?

The "Product" of banks is the money?
But the money is NOT owned by the Bank! Money is the property of the clients who trust the Bank to take care of their money!

How "Products" behave in the Bank's arena?

Antecipated thanks for your comments.

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 08 January, 2016, 16:061 like 1 like

@JoãoBohner: TY for the A2A. In the context of Banking, "product" means Checking Account, Mortgage, Certificate of Deposit, Mutual Fund, Credit Default Swap, Collateralized Debt Obligation, etc. A car has various specs. viz. engine capacity, ABS, 4WD, boot capacity, etc. Likewise, a banking product has various specs. viz. Tenor, Interest Rate, Maturity Date, etc. Hope this answers your question. 

João Bohner
João Bohner - Independent Consultant - Carapicuiba 08 January, 2016, 17:26Be the first to give this comment the thumbs up 0 likes


By chance, these, would not be "lines of business" instead of "products"?

What do you think @Bill?


Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 08 January, 2016, 17:35Be the first to give this comment the thumbs up 0 likes


Surely not. The corresponding LOBs or SBUs - with some overlaps between them - would be:

  • Retail Banking: Checking Account, Mortgage, Mutual Fund, Certificate of Deposit, Mutual Fund
  • Corporate Banking: Checking Account
  • Investment Banking: Credit Default Swap, Collateralized Debt Obligation.
A Finextra member
A Finextra member 08 January, 2016, 17:41Be the first to give this comment the thumbs up 0 likes

@JoãoBohner we spent a very long time discussing what was a product versus solution versus service at a financial services company were I worked. Eventually our answer was simple, if slightly flippant, in that our "products" were whatever we wanted to sell to clients.

Our clients would probably view what we called "products" as "services" in their minds.

The important aspect was for us to decide how we thought our offerings would be packaged up. So, would Global Custody as a product suffice, or would a full Asset Servicing package be better that would potentially incorporate Transfer Agency and Fund Accounting as well etc. How would that look as a service, were there economies of scale, and could we make our pricing more attractive for a broader range of services within a packaged product.

I think that it could well be argued that you need a "line of business" in order to produce and offer any particular product (particularly those that would be considered a "service" by the client, rather than a tangible thing).

Hope that makes sense and agree with @Ketharaman regarding the type of things that Banks would be likely to identify as products.

João Bohner
João Bohner - Independent Consultant - Carapicuiba 08 January, 2016, 17:51Be the first to give this comment the thumbs up 0 likes


Ok, Ketharaman,
these are "Strategic Business Units" or "Line-of-Business", but NOT "Products" as defined by @Bill in his article.


THIS definition is very important for my underlying Architecture.

What's your definition on that?


Thanks again!

João Bohner
João Bohner - Independent Consultant - Carapicuiba 08 January, 2016, 18:09Be the first to give this comment the thumbs up 0 likes

Yes @Bill,

As the "Product", money, is not owned by the Bank but by the customer, the Bank "Products" are "Offerings" (may be services) on how to best manage customers assets. And THAT make quite a difference among other industries' "Products".

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 12 January, 2016, 12:071 like 1 like

I thought CRM has gotten well past its initial adoption challenges by now. But, per this Gartner blog post, it looks like I was too optimistic: 

CRM efforts still fail for most companies

Now hiring