How To Build Products Instead Of Custom Solutions

When you begin building a company, your goal is to create a product that satisfies an unmet customer need.

In the beginning, you’ll find a few prospective customers and build something to meet their needs. You’re not established yet — you’re just trying to get that initial revenue flowing and get product-market fit.

The good news is, those initial customers give you great feedback and are very involved and proactive in the product development process.

As you continue to grow, you’ll start landing more customers. And this is when you have to draw an important line. These new customers may all ask you for different things (specific enhancements, extra features, shorter deadlines) but unfortunately, you can’t do custom work for each one of them.

It just doesn’t scale.

What you can do is create a common product that will work for a large number of customers with minimal customization.

If all you do is build custom solutions for each and every customer, you’ll never be a leader in any market. And at that point, you’re no longer a product company, you’re a service company.

Here’s how to avoid that fate:

Ask your customer questions to come up with common features.

Practically every new customer is going to ask you for some custom features that work only for them.

It’s up to you to figure out what they really want — which isn’t always what they say they want. This is all about pattern recognition. Rather than creating a custom solution for each customer, try to find the commonality in all their requests.

Is there something you could build that would solve the underlying need for all of them?

Here is a simple example.

Say you’ve built an enterprise software product that has to integrate with the identity management/login system of a customer. But different customers use different systems from Salesforce, Google Suite, Microsoft, or their own homegrown system.

It’s not feasible for you to develop custom integrations for each system. So, instead, you build a generic SSO integration feature that uses standards-based technologies such as OpenID or SAML. Most of these customer systems comply with the standards, and then the integration can be completed.

A standardized solution may not give the customer everything they want, but it will get them 80% there. And, because you’re responding to a consistent pattern of customer requests, you can be fairly certain your solution will help a lot of other customers and some potential clients.

Don’t leave the customer hanging on the remaining 20%.

If your common product covers 80% of what the customer needs, that still doesn’t fully satisfy them. That leaves 20% of work that you can’t really do yourself without giving in and building custom solutions, but that work still has to be accomplished somehow.

There are generally three ways to do this.

1. You document clear instructions for how the customer can do it themselves.
2. If your company is large enough, you can create a customer solutions team that handles each incoming customer request.
3. You or the customer hires a third-party to complete the final 20%.

No matter which way you choose to handle custom inquiries, your core engineering team should not be the ones working on that last 20%. You need them focused on features to improve your core product.

Ruthlessly prioritize to utilize your resources efficiently.

The truth is, you’re going to get a lot of requests for custom work.

Part of this is driven by the age-old dynamic between sales and the product team. Salespeople are incentivized to get revenue for the company, and they’re always looking to close a deal. So, they come to the product team and tell them, “Hey, all we need is this little customization here or there, and we’ll close this customer.” And, of course, it’s hard to say no to that, but the product team has to push back on that and manage expectations.

There is a proper way to manage this and avoid tension between teams.

Make it clear your development team is building product features that will be available at a regular cadence with releases.

Everyone needs to know that a custom request won’t be completed immediately, and when it is built, it will be a common product-based solution that may still need some 20% additional custom work.

You may have to stand your ground here and help explain the long-term implications of constant customization on the health of the company as a whole. This is part of the tension between short-term and long-term strategy. Your CEO deals with it daily at the company level, while you do this at the product context.

It may be an uncomfortable conversation, but you have to be able to prioritize your resources to continue building your product into a market leader.

You can’t divert your core engineering team every single time you need to close a deal.

That’s how you slip into the role of a service company.

Here is an example of how this topic plays out in a real-world situation. Let’s say one of your customers asks you to send an email if your application goes down. Another one asks for a text. Another one asks for a message on Slack or their proprietary system. Since each of these requests would require a custom integration, what can you do?

By analyzing these requests, you can understand that there are two underlying needs every customer has. The first need is the ability of the system to understand when a certain event happens. It could be the application going down, the system being under high load, an outage, or a security issue. The second need is the ability to send a notification to an external system when that happens. That external system could be Slack, Twitter, email, or text servers.

So what you actually want to build is a generic event management and notification system that listens for certain events and sends notifications when they happen.

Some custom work is still needed (the 20%) to tell your product that the event happened, and there is also the work to build plugins to the different notification systems. Ideally, your solution team can build those plugins. But the system is not directly usable without the 20% work. So when your salesperson asks for an email notification, and you want to build this generic event and notification system that still needs the email plugin, they’re not going to be happy.

It’s up to you to manage this situation.

Find the balance between common features and custom work.

Your goal is to avoid unnecessary customization and focus on your core product. But it’s also important to be realistic, especially if you’re a small company.

Keep in mind, a prospective customer that presents a large deal or a very strategic customer may ask for a custom feature. You know that this work, while custom, is important for the company as a whole. In those situations, it may be necessary to build a specific solution for that client. Just keep in mind this should be the exception, not the norm.

Once you’ve scaled your business, you’ll look back and realize it never could have happened without that common product to sell to customers.

How To Build Products Instead Of Custom Solutions was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.