Associate Director Optima Partners
Share this content

How much marketing technology is enough?

4th Mar 2014
Associate Director Optima Partners
Share this content

Laura McLellan at Gartner has written an interesting new report on ‘How the Presence of a Chief Marketing Technologist Impacts Marketing’. In it, she shows that the majority of large corporations have a chief marketing technologist, and that those that do: spend more on marketing, spend more of the marketing budget on digital marketing and also spend more of it on marketing innovation.

The chief marketing technologist has become a critical role as marketing becomes more and more technology-driven.

But there is a larger and more important question that McLellan doesn't ask;

Exactly how much technology does marketing need to optimise business value?

Just implementing more and more marketing technology obviously can’t be the answer. And there’s an even more important question too:

How do you implement marketing technology so that it catalyses business transformation?

Many technology projects don’t create value

The sad fact is that many implementations of marketing technology don’t create the business value expected of them, let alone catalyse marketing transformation. Just buying and implementing marketing technology without pulling all the other levers required to create business value and catalyse transformational change, is a recipe for expensive failure. The high failure rates of earlier technology-driven change projects like ERP, BPR, CRM and now marketing technologies like MRM, all illustrate the general principle…

OO + NT = EOO (
Old Organisation + New Technology = Expensive Old Organisation)

Technology alone is not enough

Data gathered directing marketing transformational change programmes in major corporations over the past 25 years suggests that technology is typically responsible for approx. 15% of the available value available to the business from a transformational change programme. Planning is worth a further 20%, processes 20%, measurement 20% and people the final 25%. The more all these levers are pulled in a coherent, integrated way the higher the business value a marketing technology programme will create and the higher the likelihood that it will transform the organisation.

Climbing the ROI hockey stick curve

Unfortunately, just implementing technology by itself won’t even produce the 15% of value potentially available from the technology. Transformation change project returns follow an approximate (field) hockey stick shaped curve. Piece-meal implementation, e.g. of just technology, creates a lot of costs but doesn’t pull enough of the other levers to generate any net value. It is only when more of the levers are pulled and more people are affected (research suggests approx. 40-50% of people) that the value starts to outweigh the costs and the net value start to climb the handle of the hockey stick.

There is enough research into project failure reasons, complementary capabilities and phase changes in transformation projects to validate all these points. And all of them point to the inexorable fact that…

OO + NT Really Does = EOO.

So back to my original question; Exactly how much technology does marketing need to optimise business value?

Graham Hill is a partner at Optima Partners.

Further reading:

Related content

Replies (9)

Please login or register to join the discussion.

Dr. Graham Hill
By Dr. Graham Hill
04th Mar 2014 10:34

In a previous life, I was interim Head of CRM at Toyota Financial Services in Germany. Toyota was and is an amazing place to work. As an employee you are quickly immersed in the brave new world of Hoshin Kanri Planning, A3 Reports and in particular, Lean Operations.

One of the most useful lessons I learned developing and implementing Lean CRM at Toyota is that you should only use the minimum amount of technology that is necessary to operate your business and support your intended growth over the next three years, and not one bit of technology more.

As CRM is a fast moving space, this minimalist approach to technology makes a lot of sense, for three reasons. Firstly, it greatly reduces your spend on technology. As a number of studies have shown, the choice of technology (and vendor) is not related to CRM project success, assuming it provides the minimal amount of enablement required to operate your business. Any spending over minimal enablement is pure waste.

Secondly, it avoids burdening staff with unproductive complexity. Only a minority of staff use the majority of the functionality of most CRM systems. In other words, most of the functionality is not used by most of the staff. This unused but paid for functionality represents huge waste in unused licence fees, wasted maintenance costs and unnecessary upgrade expense.

And finally, it increases your flexibility to adapt to changes in the CRM environment. Far better to opt for a cloud-based, modular, SaaS solution that you can adapt as and when circumstances dictate, than to burden yourself with an inflexible solution that you can’t adapt for love nor money.  

This can create some tough decisions. Having earlier implemented Unica’s (now IBM’s) Affinium solution, difficulties with Unica’s overly complicated tool, unethical approach to pricing and generally poor attitude towards Toyota resulted in it deciding to throw out Affinium in favour of a much simpler modular solution.

I can honestly say I learned more about managing business for mutual value in my four years at Toyota than I did in the other 20 years working with some of the biggest banks, insurers, telcos, airlines and the public sector combined. Only spending as little as is necessary on technology was one of the most valuable lessons I learned.

Graham Hill


Thanks (0)
By Henry Dean
04th Mar 2014 11:58

but does lean crm and the approaches by the likes of toyota mean there was a move away from the giant suites towards the best of breed solutions which are bolted on as and when they're needed? 

Thanks (0)
Dr. Graham Hill
By Dr. Graham Hill
04th Mar 2014 15:07

Hi Henry

Thanks for your question. It is a very interesting one.

In another life I was interim Head of Campaign Development for a joint venture between Chinese telecoms equipment manufacturer Huawei and a Dutch mobile telco. My job was to build a custom Campaign Management System/Marketing Resource Management module as part of a new business operating system Huawei was implementing at the telco. It isn’t often that a CRM professional gets the opportunity to architect, design, build and implement a brand new CMS/MRM solution from the ground up.

Rather than the traditional waterfall approach to software development used by most of the current vendors – which is slow, expensive and prone to over-engineered solutions that don’t match users’ requirements  – I adopted an approach which combined the best of agile development, empathetic service design and lean startup. This approach is characterized by:

Joint Development Team

A joint development team consisting of client users and technology developers, so that the developers understood first-hand what users wanted and users understood what technology could and couldn’t do cost effectively. All design, development, testing and implementation work was done by the joint development team. It didn’t always work harmoniously together, but it did always work.

Requirements Based on User Jobs-to-be-Done

A detailed requirements catalogue was developed based on user jobs-to-be-done and for critical functional jobs, on their desired outcomes. Developers observed how users did their jobs to develop a deep understanding of their work and jobs statements were used in place of the traditional, deeply flawed use cases. This allowed users to cut out all the extraneous and costly ‘wish-list’ requirements that plague traditional software development. It also allowed them to prioritise their jobs so that the developers could focus on solutions for the priority jobs first.

Minimum Usable Solution Development

Rather than develop the new CRM/MRM system as a whole, it was broken down into a set of highly granular modules and Minimum Usable Solutions identified for each module. Based on the Lean Startup idea of the ‘Minimal Viable Product’, each MUS provided the minimum of functionality for the user to do their job significantly better than their current tools. A roadmap for module development allowed additional functionality based on prioritized user jobs to be progressively added to each MUS as the solution was developed.

Step-Wise Development & Implementation

Each of the prioritized MUS’s were developed by a small team of developers. Development started with a paper wireframes which was signed-off by the users. The wireframes were turned into a bare-bones MUS by the developers within a short-time and reviewed, warts and all, with the users. Feedback was rigorously documented and the final MUS was developed prior to formal testing, handover and release. This fast cycle of iterative Design-Develop-Test-Decide was repeated as long as was necessary for users to sign-off the MUS. Having completed each MUS the next iteration of development could be started.

Beta MUS Piloting

As soon as each MUS was released in beta it was made available to the users to use to do their day jobs. Even though it was only a minimum usable solution it was still more effective than the tools they were using. Each iteration improved the MUSs and allowed users to create more value by using them. It also significantly reduced the training costs as the users had been closely involved in the design, had experienced each iteration and were able to act as ‘ambassadors’ when the final solution was released to the business as a whole.

The approach worked and the new CMS/MRM solution went from architecture to full implementation within 12 months. In fact, the approach worked much better than expected. When Huawei went to show the new business operating system to a different telco, the telco’s marketing team were amazed at how easy and intuitive the CRM/MRM module was to use. Almost as though it had been designed by fellow marketers. How right they were.

The CRM suites all promise to be best of breed, highly modular, completely integrated and that they can be rapidly deployed in as little as 90 days. Having implemented a few of them I find quite the opposite. They usually have one or two best of breed modules surrounded by a much larger number of basic modules, are often poorly integrated with each other and none of them can be successfully implemented in 90 days. Not if you want to create value for the business rather than just Expensive Old Organisation costs.

In practically all circumstances I can foresee I would rarely recommend to a client to implement a CRM suite unless, and it is a big unless, there was an overwhelmingly strong integration reason to do so. If all the rest of your organisation is running SAP, there is little sense to implement another CRM solution and to have to pay for all the integration costs. In most other circumstances a series of best-of-breed solutions is likely a better bet. That doesn't mean you shouldn't develop a proper requirements catalogue and go through a thorough vendor selection process though; you should. But whatever approach you take, the technology is only worth approx. 15% of the total value created. It isn’t the most important factor in creating value from CRM implementation, let alone in catalysing business transformation. 

Graham Hill


Thanks (0)
By Henry Dean
04th Mar 2014 15:23

when you buy a crm suite there is usually functionality that you may not yet be ready to use / wanting to use at that time. 

it sounds as if crm suites are the better option in the longer term but that you would have to accept that there is a lag and you may be paying for more functionality than you require for an amount of time. 

Thanks (0)
By rustynail
04th Mar 2014 15:32

"Piece-meal implementation, e.g. of just technology, creates a lot of costs but doesn’t pull enough of the other levers to generate any net value."

Suites are preferable.

Thanks (0)
Dr. Graham Hill
By Dr. Graham Hill
05th Mar 2014 06:58

Hi Henry

Thanks for your follow-up question.

I am not sure that is the right conclusion to draw. The research I saw suggested that 75% of users only use 25% of the functionality of most software. That means for these users - the vast majority - 75% of the functionality that you buy, that needs to be maintained and that needs to be upgraded, must be paid for even though it will never be used.

One of the key learnings from my work running CRM operations for Toyota, Huawei and other companies is that you should only buy the functionality you are going to use currently and in the near future. Anything else is expensive waste as it is unlikely to be ever used. That is why I use user jobs-to-be-done (used widely in product and service innovation) to define user requirements and not use cases. Use cases are deeply flawed as they focus on what users do, rather than what they are trying to do. That means they are limited by the current tools and technologies employed by the users. In contrast, user jobs-to-be-done focus on what users are trying to do, irrespective of the current tools and technologies. They are a much better foundation for a requirements specification.

Armed with a requirements specification created from a prioritised set of user jobs you can look at vendors' solutions to see how closely their technologies match the user jobs and how much unusable functionality they also contain. Your job is to either select a portfolio of best-of-breed solutions that closely match the user jobs, or to try to negotiate with the CRM suite vendor to only pay for the functionality you want. Having used both approaches in the past, the former is technically complicated but entirely possible, but the latter is practically impossible to negotiate. Even the buying power of a USD 40 Billion turnover banking group with thousands of potential users was insufficient to persuade a marketing technology vendor to only pay for the functionality the bank would use. The banking group was stuck with the choice of either going elsewhere or paying for a lot of functionality it simply wouldn't use. If a huge bank doesn't have the power to negotiate with vendors, you have no realistic chance of doing so. 

At the end of the day the $64,000 questions is, assuming you know what functionality you really need, are you willing to pay for the 75% of functionality that you don't need from a CRM suite, or would you prefer to pay to integrate best-of-breed solutions. The choice is entirely yours. Good luck.

Graham Hill


Thanks (0)
Dr. Graham Hill
By Dr. Graham Hill
05th Mar 2014 07:18

Hi Rustynail

Thanks for your comment.

The quote, "piece-meal implementation, e.g. of just technology, creates a lot of costs but doesn’t pull enough of the other levers to generate any net value" in no way favours CRM suites over best-of-breed solutions.

As a number of studies have shown, the choice of technology (and vendor) is not related to CRM project success, assuming the technology provides the minimal amount of enablement required to operate the business.

Although technology is an important lever, it is not the only one. It is in pulling all the other levers – understanding the customer journey, developing responsive processes, gathering insightful data, establishing the right roles & responsibilities, building a supportive working climate, developing organizational collaboration and managing them all for mutual value – that the other 85% of the available value is created.

Having worked extensively with both best-of-breed vendors and CRM suites, neither are even close to proficient at pulling these other levers. They see that as the job of their systems integrators or of the customer. Unfortunately, these are often poor at pulling all the levers together as well. Perhaps that is why large systems implementations have such a poor record at delivering the expected business benfits and appear with increasing frequency in the dock in the law courts.    

Graham Hill


Thanks (0)
Mike Boysen
By Mike Boysen
05th Mar 2014 13:08


First comment on your first of 3-in-1 blog post! You've stated this case a number of times; and I completely agree with it based on my experiences. The problem is that most marketers probably feel as though they... 

a) Are great planners; just ask them
b) Are great process designers; just ask them
c) Are great at measurement; just ask them about Net Promoter Score
d) Have great people; just ask them!

All they need now is technology. 

Perhaps you might make a series of posts that talk about what planning looks like, how process is derived from it, how and where measurement should take place (as opposed to where it does take place; if at all) and they type of people they should be looking for. Don't leave it to chance, show them how and convince another group owners and the c-suite that what we've been doing doesn't work.

You won't convince everyone, but you already know that you don't need to. The laggards will follow the success eventually.


Thanks (0)
By 70 Fathoms
10th Mar 2014 11:57

Hi Graham.

We (at 70 Fathoms) have a client who carried out a thorough selection process for CRM software for which we produced the user requirements specification, which as you suggest was clearly prioritised. From this they chose a Marketing Automation product that could be built without the 75% functionality which wouldn't be used. It also came without a data model and a seemingly confused supplier development team.

Luckily the client insisted that the requirements became a part of the contract (which a lot of software suppliers do not like) and when the whole project was cancelled after months of acrimony, wasted time and investment this became critical did the supplier could not deliver what was promised. I don't believe that the client did anything wrong or particularly badly, but they tried to produce a lean system exactly matched to the requirements and without excess technology.

Perhaps a more "out of the box" solution with the wasted 75% might have been more successful? But the user requirements specification is the most important document and worth a considerable investment to get it right.

Thanks (0)