Maybe you’ve considered having your development team build a custom martech tool. And why not? It could be a great opportunity to leave your mark on the company, add efficiencies and customizations, and expand your development team’s portfolio. Projects like this can pay off in a big way, but there are many things to think through first. Otherwise, a lot of money and time could be wasted—and careers damaged—as many technical or operations directors in mid-sized companies have learned.
As a marketing technologist who has worked with tech and mid-sized companies for years, I’ve worked with dev teams on a broad range of initiatives and projects. I’ve seen in-house martech projects succeed but have also watched some spiral into disaster. Whether you’re at a $9 million company looking for a new revenue stream or a multibillion-dollar enterprise hoping to create efficiencies, here are some key questions to ask before committing resources.
Will it support your business future?
The potential benefits should justify the time and cost of building, updating, and maintaining an internally developed solution. A good yardstick is whether the projected outcomes will support an existing process or product that is core to your business. The better it supports a critical component, the more valuable it can be.
For instance, you might have a great partnership with a lead channel that represents 40% of your income, so it might be worth it to the business to create automated process flows specific to this channel. However, if your proposed tool supports new revenue channels, processes, or departments, you’re in unproven territory (more about this below). Unlike small to mid-sized businesses, enterprise companies are better able to absorb the costs and risks of developing custom tools for newer processes or revenue channels.
One of our enterprise clients developed a strong content strategy supported by a custom automated content delivery solution that aligned strongly with its different product lines. The solution supported a long-running program with proven outcomes, could be used by teams across the organization, and was based on a simple content delivery method: When contacts signed up to receive content, the information they provided tailored the content displayed to them, which made for more accurate lead scoring.
Can you tie benefits or KPIs to the solution?
If your development project will support a significant company goal, objective, or process, you can make a good case for it based on its potential gains. You’ll know you’re on the right track if you can tie the potential solution to provable metrics, benefits, or KPIs, such as increased efficiencies.
I once worked for a fast-growing mid-sized lead generation company that still relied on a lot of manual processes. I managed the company’s direct-mail program, which relied on two team members to send over 12 million mailers a year. To manage and clean data, these employees manipulated filters using Excel spreadsheets, and the marketing department had to manually create reports through SQL scripts. Because the team handled millions of records manually, it was easy to make mistakes or spend valuable time troubleshooting IT and process issues.
Before building a solution, we gathered requirements for automating the entire process and for robust reporting to see if we could justify the development time. Because we were able to tie benefits to the number of working hours saved, cost savings from bulk data purchases, and decreased issue management—and because we could identify clear solution requirements—the project succeeded. Its gains far outweighed the costs of development and maintenance.
Are processes and needs likely to change?
If the issue you’re trying to solve has a chance of being short term—for example, you’re expanding your product or service to a new market or territory—third-party solutions are a better bet. They can be swapped and updated more quickly than an in-house system.
At one lead-generation company, the development team scoped a project for altering the internal lead-intake system to accommodate a new branch of industry leads (and thus a new revenue stream). The company started development without looking at potential changes to the industry and associated regulatory requirements. Ultimately, the new lead-generation category was deemed non-viable, and the project was abandoned.
Does your dev team have the skills?
Going into a development project with only junior level-developers or a lack of knowledgeable project management resources can make any software development project a nightmare. Make sure you know the expertise level of the team you’ll be working with. If you need to proceed regardless, ensure that you have the time and budget to hire, can make appropriate arrangements for developers and project managers, and you have mechanisms to transfer knowledge so that your project doesn’t fail when someone leaves the company.
In one case, I saw an automation solution get greenlighted without anyone considering who would be doing the work. When the project managers and junior-level developers were presented with a list of requirements and told to begin work, the team was overwhelmed. To fix the situation, a very expensive project management firm was brought in. The communication and technical issues were never resolved, and the project wasted money, hurt productivity, and led to a director being asked to leave the company.
Will it drive high enough volume?
To justify project costs, the answer to this question could be associated with considerable boosts to new content, leads, traffic, or revenue. If you’re looking for operational changes to handle just 200 leads a month, look for third-party solutions or workarounds. In general, smaller companies tend to fall into a trap here by spending on development in order to reach for additional revenue streams or areas of growth that aren’t proven.
While I was consulting for small real estate training agency, someone decided to create a community-based software solution to support communication between investors and facilitate deals. By the conclusion of the $1.5 million development project, the volume and demand for the communication channel just weren’t there. The company tried to repurpose the new tool, but it was ultimately dropped.
Can you test it with a paid service first?
If your development decision is based on a hypothesis or new process, it may make more sense to buy before you build. Check to see if you can use a turnkey solution to gauge the viability of your development idea before committing the budget and resources. Based on what happens, this option might also help you identify changes you should make to your original idea.
A small company I worked with wanted to implement a custom project management solution for its developers by building a simple tool that would tie into the company’s unique organizational structure. The resulting solution was clunky and ultimately didn’t work according to the specified requirements. This was because the concept hadn’t been used or tested first, so the vision of how the tool needed to function was unclear. By testing out different project management tools, and putting requirements around those tools, this company could have succeeded.
The idea of a company building its own solution is exciting and very rewarding when done with forethought and knowledge. Just make sure that before you start, you consider these questions to ensure that your company is in the right position to take the leap. If you’re thorough in your assessment and preparation, you can be confident in taking the first steps toward your development plans.
Happy developing—feel free to keep researching, or just get in touch with questions.