More on special requests

In my previous article about special requests, I explained that the way you deal with special requests depends a lot on your product and your client base. If you have a B2B product focused on bigger customers, the product manager “must pay full attention to special requests. There are few customers, but all of them are special and demand customized attention. The product manager must be careful and not implement features that will be used by only one customer. However, requests from one customer, especially the bigger ones, will always be a priority in this scenario.”

How to manage these special requests

So this means that the product manager should do everything that big customers demand?

The short answer is NO! You are still managing a product so two important aspects of product management still apply:

• Demand normally comes in the shape of solutions, and big customers can be quite incisive describing the solution they want. It’s the product manager’s job to understand what’s the underlying problem that made the customer request that specific solution. A quick tip: ask why the customer need that solution and what she will do as soon as she gets that solution. This will give you lots of insights into the customer’s problem.
• You are managing a product, not a tailor-made software. If you implement each and every feature request from customers, you’ll be building a tailor-made software for each customer or, what’s even worse, a “Frankenstein software” product.

The longer answer is no, but you’ll still have to manage the special requests. There some techniques that can help you deal with these special requests:

• modularization: if you are able to build your product as modules that work together in different combinations to deliver different types of solutions, this will enable your sales team to mix and match the modules to fit the needs of your customers. And whenever a new feature request comes, and you figure out the underlying problem and decide to build a solution for that problem, you can build as a separate module. You can even charge this customer for the development of this new module. Charging a customer for the development of a new solution, even considering that this new solution can be offered to other customers, is a good way to test the real need of this customer. If he is willing to pay you to deliver this solution, he really needs this solution and trusts you to build it. SAP is a good example of modular solutions.
• advanced configuration: another way to customize your product without making look like a “Frankenstein software” product is through advanced configuration. For instance, for a certain customer, feature X can be delivered as the sequence of step A, step B, and step C. For another customer, that doesn’t want feature X, but need feature Y, it can be delivered by the sequence of step C, then step E, and you turn off feature X for this customer. Depending on the complexity, it is possible also to deliver this advanced configuration through programming languages. Some examples are, again SAP, with its ABAP (Advanced Business Application Programming) and Salesforce with Apex, which enables developers to add business logic to most Salesforce system events, including button clicks, related record updates, and Visualforce pages.
• integration: another common need from big companies is to have your product integrated with other products they already use. For instance, let’s imagine your company provides e-commerce solutions. Your customer hired your e-commerce product and they will have all of their product catalog, and also data on customer and their purchases in your e-commerce product. This big customer will certainly ask you to integrate your e-commerce solution into their ERP, so they can invoice customers and manage their inventory. This integration can be done in many ways, completely manual through re-typing of data, through file exchange or using an API integration. The best solution is through API, since it provides an error-free and real-time solution for the data integration between systems. For this reason it is very important that your product has APIs with the needed endpoints to connect with other systems.

Technical Sales (or Sales Engineering)

New special requests come up during the sales process. Each of these special requests will take time from the product manager as well as the product development team. The team needs to understand the special request, the underlying problem and design solution options that can be used with other customers. This will take time from the product manager and the team.

At a certain point, the team will use the above-described techniques to cope with the special requests in a scalable way. As soon as the team starts to use these techniques, the need to interact with customers for each request will probably persist or even increase. The sales team will ask the product manager to have meetings with the customer and help them show the customer what are the technical options available in order to address the request.

The first step is to train the sales team. However, this won’t be enough. The product manager will continue to be asked to join meetings to answer technical questions. To help with this issue, we should create a new role, the technical sales, also known as sales engineer, someone with a technical background who will engage in technical discussions with the customer during the sales process.

Sometimes this role, since it has the sales word in it, is placed under the sales leadership. It’s a possibility but can lead to misalignment of incentives. Under sales leadership, the incentive is the number of sales. So if a tech seller is taking too long to design the solution, and other requests get delayed, a new tech seller is hired, increasing headcount and, consequently, the cost of selling. An alternative is to place this position under product management leadership so the focus is on sales enablement, i.e., provide the sales team with the needed tools to conduct sales without the need for a tech seller.

Professional Services

Supposing everything goes well with the negotiation and the customer decides to buy your product, if there are customizations to be made, additional work is required, no matter if it will be through modules, through advanced configuration, and/or through integration, This work may end up falling into the product development team backlog, which is not ideal, since this work is specific to address a certain customer request, while the product development team should be working on things that could be used by the majority of customers.

To help with this issue, we should create a second role, called professional services. A person with this role works on this type of projects. Setting up a new customer using the customization techniques from the product (modules, advanced configuration and/or integration). It should be people with technical skills able to do the customization work needed to set up the new company. Professional services can be done by a team within the company that offers the product and/or by third parties. For instance, to implement SAP, Salesforce or Zendesk you can choose to use professional services from them or from certified third parties that have knowledge and experience implementing and customizing their software in many customers. This work is normally billed as setup fee.

Summing up

Dealing with special requests may be a need in your market, especially if you are in the B2B space with bigger customers. It is possible to build a product that fits these special requests without building a “Frankenstein software” product. In order to do that, the product manager and product development team should use one or more of the known techniques to deal with special requests, modularization, advanced configuration, and integration. Having these techniques in place won’t probably be enough since the sales team will still need help in order to present the options to the customer and, after the sale, to implement it. Then enters two new roles, that should be close to product management: technical sales — or sales engineer — and professional services, which could be internal, could be done by third parties or both.

Lean Product Secrets

The Lean Product Secrets brings together the hands-on experience of three successful digital products enthusiastic. Get to know their secrets for idealizing and evolving products, and their combined experience on Design Thinking, Lean StartUp, and Product Lifecycle Management.

The thing is, two of these E-Books are in the way to their printed edition, so they won’t stay available as E-Books on LeanPub for much longer. For this reason, we decided to create a special bundle price to let you keep a copy of these E-Books.

We will keep updating the E-Books until they are officially released. This way you will have early access to their official first edition releases:

https://leanpub.com/b/leanproductsecrets

Enjoy!