NeuEon Insights / Business & IT Strategy, Technology Selection & Program Management

Core v. Custom: How To Protect Your Product and Accommodate Customer-Specific Requests

At NeuEon, there’s no more rewarding work for us than solving a product development problem that we encounter time and time again. A major challenge for many product development organizations is how to manage custom software requests from clients. We find that many teams have trouble balancing these custom requests with the core product that they’re aiming to build. You may have a great team and an established roadmap, but your sales group could be selling features or custom work that you simply don’t do, or won’t get to on the roadmap for some time. Since landing new business can often depend on providing these types of customizations, what’s the best way to proceed?

The Balancing Act

The folks at 37 Signals ( recommend “starting with no” until you get the same request a few thousand times before you decide to build a new feature. Not a bad approach, and a good way to prove the importance of certain requests. But for many companies, especially those with a smaller roster of high value clients, neglecting customer requests could lose you business, and only building what you need to build could spell another kind of disaster—one where competitors leapfrog you and gain greater market share. Most organizations that are building specialized products will want to adopt a strategy to protect your core product while still accommodating customer-specific requests.

The Problem With Yes

If you answer yes to every custom feature request, you’ll likely end up with a product development team that’s being pulled in too many directions. Worst of all, you’ll also suffer from “feature bloat” in which your product becomes so packed with features, and claims to do everything for everyone, that in reality it ends up doing nothing for no one. Beware of the temptation to add just one more feature in order to land just one more client—you’ll end up with a product development team that’s too bogged down by custom requests to focus on core components. Building customizations can overwhelm even the best development teams, increase product delays and detract from the development of your core product—which can put your entire business at risk. More customizations lead to more delays, and soon you’re missing deadlines and disappointing customers.

A Tale of Two Teams

If you’ve found yourself in this situation, we recommend establishing two separate teams: a core product development team and a custom features team. These teams don’t have to be co-located, or even in-house, but by structuring your approach this way you’ll be in a better position to serve your customers. Allow your product owner or CTO to define the core components and expose the critical functions of the core product through a set of web services. The core team should be high-functioning, believe in and defend the overall vision, and be vigilant about adhering to the product roadmap. On the flip side, the custom features team should be allowed to write and maintain custom software to meet specific customer needs. Some custom requests may even flow through to the core group, but these would likely be features that are only widely used by customers. You’ll need to establish the ground rules of how this will happen.

Establishing separate teams will help strengthen your core product and enable greater speed to market since your core team will no longer be weighed down by custom demands. The best part? You can begin monetizing your custom services and may even find that your customers request improvements that you need anyway…and are willing to pay for them. If you’re a company that’s focused on building specialized products, it’s important for the health of your business to find an effective way to balance both your core product and custom requests. By separating these responsibilities into two teams, you’ll keep your core components strong while still satisfying the needs of your ever-important customers.

This article originally appeared in the December 13, 2016 issue of VentureFizz. For more technology trends and insight, visit the NeuEon blog.