In class we have discussed the tension between customization and standardization at Opower and I want here to provide a framework to help decision making when this issue arises in any tech company.
This topic also strikes a chord as I attended countless meetings on that topic as a software engineer and later as a project manager. This issue can be quite emotional and create a lot of stress in an organization, as it illustrates fundamentally conflicting interests between engineering and sales. R&D engineers are usually long-term focused, like to stick to the plan and want elegant and coherent solutions (saying “no” to requested features that don’t fit well in the architecture and would hinder further product evolutions). Sales reps want to close sales as soon as possible and satisfy their customers (saying “yes” to whatever features).
There is no single answer to choosing customization over standardization, as the arbitrage depends on the larger context of the firm and the industry. Here are a few factors a product manager should think about when making these calls:
- Stage of the company: Before a company reaches product-market fit, it should definitely lean towards customization. Indeed the goal is there to experiment and thus to give different flavors of the product to different customers to speed up learning. The prototype / MVP will most likely not be the final product, and engineers will develop in ‘quick and dirty’ mode and not build for the future. After the company reaches PMF the equilibrium has to shift to greater standardization to enable scaling, more efficient operations, and long-term viability (it’s easier to maintain one version than several).
- Market structure: The size and number of customers are crucial factors when setting the cursor between customization and standardization. B2C calls for standard products most of the time, unless the profitability of one customer is high enough to justify the effort of customizing the product (one non-tech example is construction: materials are standard but the house is most often customized to fit individual needs). B2B calls for more customization, especially in markets where all competitors fight for a small set of very large customers. Unless the product is a commodity and price is the only thing that matters, large business customers will look for features that solve their exact needs and thus will put pressure on sales to deliver them.
- Competitors: Markets where competitors are more aggressive and nimble will call for greater customization as there is a need to beat the competitor’s features to win the contract. Fast moving industries, such as the one Opower is in, call for flexible developments and changes to the roadmap. Creating a product that is too standardized and inflexible there would hinder the company’s ability to pivot and adapt to market shifts of competitor’s moves.
- Technology: Depending on the technology used, customizations can create more or less technical debt. In situations where you can choose which technology to use to develop your product, the ability to easily customize the product should be a prime factor (especially if the other criteria above are met). Fast technology evolutions might also deter the engineering team to choose product standardization in the first place (eg. if you know you will have to rewrite the code next year to use cloud computing, you might not want to create a very standard architecture).
- Human resources: Decisions a product manager makes often have a strong impact on the morale of sales and engineering teams. How they work, what motivates them, and what skills they have should all be factored in when making these decisions. A decision to break the existing architecture, as in Opower’s case, can make the developers very angry if they don’t understand the rationale.
Once I had to develop a feature at a client’s request (basically making public a hidden metric in the software) and I knew the client really did not need it (there were better ways to accomplish the same goal), that it would backfire in terms of future developments (now we would need to maintain this metric), and that it would create a bad precedent (other clients would also ask for it). It created a lot of tensions with the product manager and with the sales team, as I thought they were responsible for not educating the customer enough and saying “yes” to anything. - Is this request really a customization?: Often customization requests from one customer can be valuable to other customers as well. Before treating this feature as a one-time thing and creating a new branch on the roadmap, the PM should assess if the feature should not become part of the standard version. Often such discussions happen long after the development, when other clients request the same feature. I would rather advocate for a proactive attitude where the PM would push other sales rep to question other customers on the value of the new feature. If there is a lot of buy-in, the benefit is double: the engineering team can build it in a way that is more sustainable and easier to modify/maintain, and it would boost moral (this new development has a large impact).
