Avoid Falling Into The Customization Trap
5 mins read

Avoid Falling Into The Customization Trap

Murali is the Executive Director at an American multinational investment bank and financial services holding company.

getty

Have you ever needed a SaaS product that could be tailored to your needs? Did you get excited about how quickly you could deploy something that would have taken weeks or months in the past? With these products, small businesses can set up every department in a CRM system and have all their data in one place, but big firms may not be able to see the same success.

It’s hard to come back from such in-depth customization on such a large scale. Over time, you add more and more business processes and data. You customize it because it’s so easy to do—until it gets so complicated that a simple change takes more time than it’s worth.

Does this sound familiar to you? Before jumping into a new product and falling into the customization trap, here are six things to consider.

1. What’s Your Business?

Before you decide on a tool, you need to make sure it aligns with your business roadmap. Every company has a unique set of business processes and several lines of business that may not agree on a single, standardized process. When you bring more and more lines of business into a tool, you bridge the gap by customizing it a bit, and then the whole product shifts focus.

For example, you may try to bring HR and compliance into a CRM system with customer-focused data and processes for sales and marketing. This works for small businesses, but big firms have a lot of constraints to work within.

2. How Do Your Internal Applications Integrate?

There may be multiple applications involved in your processes, and only a few of them may work with your new tool. You have to keep your data in the applications that handle it rather than syncing everything to the new tool. These applications must also remain open to avoid creating a disjointed experience for end users.

This is easy for small businesses, but there’s a lot of opportunity for friction between engineering teams in big firms with different priorities. Before starting to implement a new tool, you must agree as one team how to integrate your applications.

3. Who Owns The Data?

When you move data into a new tool, you become responsible for maintaining that data and keeping it clean, on top of audit and compliance requirements.

Avoid bringing in data that has nothing to do with your new tool. For example, in a CRM tool, avoid bringing in data that doesn’t relate to a customer. On top of this, make sure to keep all your data in one place and avoid duplicating it, save for syncing it to a data warehouse for reporting purposes.

If you are sharing client data between two systems, only share the references and attributes that are specific to the domain or realm.

4. Who Drives The Solution?

You must streamline the process to bring in any add-on that complements your new tool. Add-ons, however, are only good if you can justify the return on investment for them and tie them to business results. You don’t need a Rolls Royce to make a delivery.

Too many add-ons make the overall cost of the tool higher. This jeopardizes the need for the tool. As a rule of thumb, let your product team decide its needs, then leave it to your tech partners to come up with the solution.

5. Is Your Business Willing To Wait?

We all know business waits for no one, but there are situations where your business is unique, and you need something out there quickly to capture the market.

We will inevitably need to customize, but there are effective ways to tackle these cases without creating technical debt by developing something you’ll need to remove or replace later. You can do this by creating components independent of other features and tools that you can turn off when they are later available as part of your main tool.

6. Do You Have An Architect?

Hiring or designating an architect is the most important investment you can make to keep your product in good health. I have seen many implementations where companies had either contracted or hired junior developers to configure their product. Everyone has their own style, and if kept unchecked, the proliferation of these disparate styles can severely hinder the scalability of your system in the future. You need an architect from the beginning who can set the benchmark on standards and best practices for everyone to follow.

Companies put years of research into developing SaaS products, and they iterate on these products continuously, adding features driven by customers’ needs. If you can take advantage of what’s out there and tweak it to align with your needs, you should do so. Creating your own product with extensive customization can be nice, but it may become obsolete after a few years.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?