If you manage a B2B product serving large clients, the product manager must carefully handle special requests. The number of clients is small, but each one is unique and requires personalized attention. The product manager should be cautious and avoid implementing features that will be used by only one client.
However, requests from a client, especially larger ones, will always take priority in this scenario.

How to manage these special orders

So does that mean we should do everything the big clients demand?

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

1. Demands usually come in the form of solutions, and large clients can be quite decisive in describing the specific solution they want. It’s the product manager’s job to understand the underlying problem that led the client to request that specific solution. Pro tip: ask why the client needs that solution and how they plan to use it. This will provide many insights into the client’s problem.
2. You are managing a product, not custom software. If you implement every feature request from each client, you’ll end up building custom software for each client, or worse, a “Frankenstein product,” a collage of features that don’t fit together.

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

• Modularization: If you can build your product as modules that work together in different combinations to deliver different types of solutions, this allows your sales team to mix and match modules to meet your clients’ needs. Whenever a new feature request arrives, and you identify the underlying problem and decide to create a solution, you can create a separate module. You can even charge the client for developing this new module. Charging a client for the development of a new solution, even considering that this new solution may be offered to other clients, is a good way to test the real need of that client. If they are willing to pay for you to develop this solution, they really need it and trust you to build it. SAP is
  a good example of modular solutions.
• Advanced Configuration: This is another way to customize your product without looking like a “Frankenstein product.” For a certain client, feature X can be delivered from steps A, B, and C. For another client who doesn’t want feature X but needs feature Y, it can be delivered by the sequence of steps C and then step E, and for this client, you disable feature X. Depending on complexity, it’s also possible 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 allows developers to add business logic to most Salesforce system events, such as button clicks and record updates.
• Integration: Another common need for large companies is to have your product integrated with other products they already use. For example, let’s imagine your company provides e-commerce solutions. Your client has hired your e- commerce product and will have the entire product catalog and also customer data and their purchases in your e- commerce. This large client will certainly ask you to integrate your e-commerce solution with their ERP, so they can invoice customers and manage their inventory. This integration can be done in various ways: it can be entirely manual, through data re-entry; it can be through file exchange; or it can be using an API integration. The best solution is through an API because it provides a real-time and error-free solution for data integration between systems. Therefore, it is very important that your product has APIs with the necessary endpoints to connect with other systems.

These techniques will help you productize exceptions, to consider possible exceptions as part of your product. Exception requests are a big part of B2B SaaS products. If you approach these exception requests with a product mindset, using the techniques presented here, it will be easier to build a scalable product.

Technical Sales (or Sales Engineering)

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

Ideally, the team will use the techniques described earlier to handle special requests in a scalable way. Once the team starts using these techniques, the need to interact with clients for each request will likely persist or even increase. The sales team will ask the product manager to meet with the client and walk them through the available technical options.

The first step is to train the sales team. However, this will not be enough. The product manager will continue to be asked to participate in meetings to answer technical questions. To help with this issue, we should create a new role, the technical salesperson, also known as a sales engineer or pre-sales, someone with technical expertise who will engage in technical discussions with the client during the sales process.

Sometimes, this role, containing the word “sales,” is placed under sales leadership. It is a possibility, but it can lead to misaligned incentives. Under sales leadership, the incentive is the number of sales. So, if a sales engineer takes too long to design the solution and other requests are delayed, a new sales engineer is hired, increasing the workforce and, consequently, the cost of sales. An alternative is to place this position under product management leadership, so the focus is on empowering sales, which means providing the sales team with the necessary tools to make sales without the need for a sales engineer.

Professional services

Assuming everything goes well in the negotiation and the client decides to purchase your product, if there are customizations to be made, additional work is required, whether through modules, advanced configuration, and/or integration. Without proper management, these tasks often end up in the product development team’s backlog—an inefficient use of resources, as the team should focus on building features that benefit the majority of clients.

To address this issue, we should create a second role, called professional services. Someone in this role works on this type of project by configuring a new client using product customization techniques (modules, advanced configuration, and/or integration). They should be individuals with technical skills capable of performing the customization work necessary to set up the product for each new client.

Professional services can be performed by an in-house team of the company offering the product and/or by third parties. For example, to implement SAP, Salesforce, or Zendesk, you may choose to use their professional services or certified third-party services that have knowledge and experience in implementing and customizing the software. This work is usually charged as an installation fee.

Recommendation

Cultural change is not an easy task because it requires a change in behavior. Even in situations where everyone agrees rationally that a change is needed, habit often leads people back to their old ways. In this chapter, I’ve shared some techniques I’ve used to work on behavior change, but they are not the only ones. Feel free to create your own hacks based on the context in which you are experiencing your digital transformation journey.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
  • Chapter 1: The so-called digital transformation – Project and Product
  • Chapter 2: Uncertainty and digital transformation
  • Chapter 3: Types of company
  • Chapter 4: Type of company vs digital maturity
  • Chapter 5: Business models
  • Chapter 6: Agile, digital and product culture
• Part 2: Principles
  • Chapter 7: Deliver early and often – Measuring and managing the productivity – Case study: Dasa Group – Case study: Itaú Unibanco
  • Chapter 8: Focus on the problem – The Famous Product Discovery – Why the “business demands => IT implements” model does not work – Case study: Magazine Luiza
  • Chapter 9: Result delivery – Outsource or internal team? – Case study: Centauro
  • Chapter 10: Ecosystem mindset
• Part 3: Tools
  • Chapter 11: Product Vision – Product vision examples
  • Chapter 12: Product Strategy
  • Chapter 13: Team Structure – Structuring effective product development teams – Structural teams – Team structure spreadsheet – Downsizing and layoffs – CTO + CPO – Internationalization – Outsourced team – Tuckman model – Dependencies between teams – Should we have a dedicated innovation team? – Should we have a team dedicated to fixing bugs? – Business Units – Why Individual Bonuses Don’t Work in Product Teams – What makes a group of people behave like a team?
  • Chapter 14: What are OKRs and How to Get the Cadence Right – Perverse Metrics, Leading Metrics, and Lagging Metrics – From Vision to OKRs: Team, Initiatives, and the Metrics That Actually Matter – OKRs, Financial Bonuses, and How to Scale to Large Teams
  • Chapter 15: Measuring Digital and Product Maturity
  • Chapter 16: Hacks to help in the digital transformation journey – Hack #1: Start small – Hack 2: Alpha, beta, and go-live terminology – Hack 3: What is the problem? – Hack 4: Examples – Hack 5: Digital and business drops – Hack 6: Showcase – Hack 7: Productizing exceptions

Scale your customer research

In a world where AI levels the playing field, deep customer knowledge is the one asset your competitors can’t copy. ReveLumi was built exactly for that. Learn more at revelumi.com.

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Gyaco Podcasts

At Gyaco, we believe in the power of conversations to spark reflection and learning. That’s why we’ve created “Produto em Pauta” podcast, with new episodes every Thursday.

The main series is called Mentorias: coaching conversations with product professionals, built on the idea that one person’s questions are often the questions of many others. We explore concrete challenges and turn experience into practical insights you can apply in your own context.

Available on YouTube and Spotify. Recorded in Portuguese, with English subtitles on YouTube.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its users’ problems, and achieve the company’s objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products