For the last five years, I’ve talked to countless business and technical decision makers at well over a thousand marketing solution providers and agencies. I’ve learned a lot. The passion and enthusiasm people have to move the industry forward continues to be inspiring. But one avoidable mistake I see a lot of companies make is to think that the complete internal soup-to-nuts execution and maintenance of their product roadmap, forever, is the only ticket to success. These companies don’t realize that there is a way to accelerate the roadmap and get to market faster, by separating valuable effort on unique IP from much of the table stakes data infrastructure work that’s already been solved by many other companies. 

They use what I call the “Not Invented Here” objection. Understandable, but occasionally misguided.

In my line of work, I also talk to many investors, private equity folks, or M&A-minded executives, and I’ve had a front row seat to understanding what does – and might not – go into an investment or acquisition-of-IP decision.  For the vast majority of MADTech companies, to ideate, develop and launch new products and capabilities requires a substantial investment of time and resources on recognized and repeated data infrastructure challenges. These are the challenges –  ingesting, unifying and activating customer data – that are difficult AND important, but really don’t add much value to your business. 

The end result is significant cost, time and risk to deliver products to market.  Companies tend to prefer to take a DIY approach to building their businesses, yet don’t always take into account the ways in which that approach may slow success, not to mention being on the hook to manage, operate, and update all the components they built on their own.

These decisions have real-world implications. Three I know about personally that come to mind:

• A company overestimated the enterprise value created by table stakes data infrastructure work and underestimated how much time it will take their engineering team to complete that work. Their senior engineers balked at spending so much time on “keeping the lights on” (KLO) tasks, as well as retiring tech debt, and ultimately two of them left the company. 
• Another company missed ‘where the puck needed to be’ with their product roadmap. They were solving for the problem as it existed a year before launch and failed to course correct or speed up.  They were forced to compete as a ‘me-too’ product instead of the intended market leadership role their unique IP was intended to deliver.
• One company looking to exit couldn’t get agreement between what they thought they were worth and what two potential acquirers were willing to pay. The main reason?  Too much focus on their DIY back-end and not enough on their unique IP.  Acquirers were looking for best-in-class IP to deliver recurring customer growth and retention, built on top of a scaleable, repeatable, and configurable foundation.

Evaluating Do-it-Yourself vs. Do-it-Together

Broadly speaking, a DIY vs DIT comparison exercise should factor in the upfront costs, namely:

• Acquisition costs of licensing the software or IP
• Management and maintenance
• Internal and external support
• Training
• Downtime
• Monthly or yearly subscription fees
  

Then you get into indirect costs:

• Risks associated with wrong-fit hires or right-fit hires who leave prematurely
• Switching cost risk if you begin to DIY but realize that was an inefficient approach
• Necessary course corrections to the roadmap that slow time to market
• Time spent on retiring technical debt or KLO work that slows down time to market

Lastly, you should look at opportunity costs. What is the cost to your organization to:

• Bringing offerings to market 6/12/18 months slower?
• Having to monitor and manage all the software in your offering (who’s on pager duty!)
• Be on the hook for fixes and upgrades?

For MADTech providers, once you’ve made the decision on DIT, you’ll look for a partner that can help you across three important dimensions:

Gaining access to a virtual ‘answer key’ of documentation around processes that have already been solved for : accelerating development time on things that aren’t that interesting to work on, don’t create enterprise value, and won’t excite your talented engineers. All of which ultimately keeps you from getting to other roadmap items in less time.

Ability to move quickly in a low-code environment: you’ll gain speed with your engineers being able to do the work more efficiently.  You’ll create much more repeatability; so much so that it becomes a new accelerator for your business. A low code foundation allows you to plug your IP right in, ingest data and get going.  A low code foundation also eliminates having to build things from scratch, and it means you can now better meet the aggressive timeframes your sales team promises to new customers.

A wide variety of pre-built integrations with data and activation partners: these are in most cases completely table stakes efforts requiring staff to monitor / operate and yet starting from scratch here can add needless cycles to development efforts. Not to mention the trouble and struggles some data partners and activation partners inevitably throw your way.

By working with partners to deliver on the table stakes efforts around your marketing data product roadmap, you can get to market faster, with less cost, time and challenges.  That’s a winning formula.  I’d be interested to hear your thoughts and experiences. Send me a message here to get the conversation going.