Such a small, powerful, and, sometimes, frightening word. It's a word most of us hate to hear and that we don't say enough. “No," however, can be our sanity and productivity savior in our personal and professional lives when used well.
In our businesses, “No” can free up resources to pursue longer-term growth. Requests for product customization (a.k.a. one-off-work), for example, is a significant resource drain for product development teams. In fact, reducing custom development requests is the largest challenge for companies that are migrating from customized solutions to more standardized products.
Customization is often promised by well-meaning sales or account management teams that don’t fully understand a more scalable product strategy. However, if your development team is spending all of its time on custom requests, it will never have the time to make your scalable products successful.
“Simplicity boils down to two steps:
Identify the essential. Eliminate the rest.”
– Leo Babauta, Zen Habits
That leaves a lot of CEOs asking: “What can I do to reduce the amount of customized work my product development team is doing?”
I’d argue that the smartest strategy would be to correctly identify customer needs before developing new products (read our COO’s blog about how to do this), and then deliver on what gives 80% of your customers, 80% of what they need. But even when we’ve identified the product features that meet the largest customer need, we still might find ourselves with customization requests, again, typically coming from well-meaning staff who do not embrace the new scalable product strategy.
One of our clients has solved the problem of customized development requests, and they did so in less than nine months. Here’s their story.
Case Study: Reducing Customization
After decades of success selling services that were often heavily customized, our client decided they needed to build more scalable, technology-based products to effectively compete in a changing market. They did not have new investment dollars to fund building more scalable products, so they diverted their existing product development teams away from customized work toward building the more scalable products.
The shift started, first, with the CEO and the Head of Sales, announcing the strategy change at the annual sales kick-off. Knowing that they could not flip a switch and completely stop custom work for clients, they also created a way for the sales and account management team to request an exception on behalf of a client. This came in the form of a “help desk ticket” that was first reviewed by the product team and ultimately decided upon by the Head of Sales and the CEO, if necessary.
When completing this customized work request ticket, the submitter had to outline a super simple business case:
Once our client started implementing this process, many requests that may have been fulfilled before were automatically dismissed because of a lack of a positive ROI. It’s a lot easier to assess the value of a customization when it is spelled out in front of you in black and white.
The big help, especially for sales team engagement, was that it wasn’t the product development team saying, "no,” rather it was the leadership team, including the Head of Sales, saying “no.”
Additionally, the executive team and sales leadership could turn to the salesperson and say, “go look for something more profitable.” Even if the immediate request was denied, the door was open for a viable solution.
Our client started with a goal of no more than 25% of total product development teams’ effort being spent on client custom projects. In January of this year, they were at about 40%. In the last three months, the average was about 15-20%. That is a 50% decline!
Saying "no" to clients isn't always easy, which is why putting a process together to build the case for "no" is essential. We like our client's strategy to reduce customization because it allows for thoughtful consideration of the impact on the company's scalability and revenue goals.
What other strategies have you tried to reduce custom development requests? And how successful would you say they were? What do you think of this approach?