How to deal with B2B sales-driven feature requests

The Go-to-Market Complexity framework that helps Product Managers deal with Sales requests and drive scalability in the long-term.

One of the advantages of not reading too many product books is that you can form your own opinions, led by hard and difficult career learnings.

These days if you throw a stone in the waters of product world, you can hear the words “empowered”, “Marty Cagan”, “product-led”, “experimentation" but not has been written about the real world complexity of how Product Managers can deal with B2B product management, and specifically Sales who for sure have client’s best interest in mind.

In this world, you may not have thousands of client insights, you may not be able to run experiments and you do not dictate what gets built.

The D2C game: Getting direct feedback from end users at scale

At Booking.com, I realized there was higher emphasis on shipping and letting the experiment success metrics dictate the success of the feature. Product teams were allowed to decide their experiments for the year, and as long as they statistically significantly increased the primary metric, you were allowed to roll it out 100%.

At Gojek (which is now part of GoTo Group afte Gojek’s merger with Tokopedia), it was not as crazy experiment driven as Booking.com. Gojek had solid grounds in User Research and Research teams used to get some of the best actional research I have seen in all companies I have worked for. So much so that, all of our Product Demos and Senior Stakeholder meetings were debating over user insights to justify the product plan and the roadmap. We used to run experiments, but they were backed with research and insights.

However, in these two companies, the advantage was i) millions of monthly users that can help you validate ideas quickly ii) small incremental cost for experimenting as the infrastructure was quite kickass. Both of these are quite true for most of the modern D2C companies, which invest early into data, experimentation and insights.

However, my experience with B2B or B2B2C companies has been different.

If you know a friend in your network who could benefit from learning about B2B Product Management and how to strive, consider sharing this post:

The B2B(2C) is a different animal

My first major product role was in a financial service business owned by biggest family run business in India. Aside from the fact that most of the product building was regulated, we were also building or embedding our capabilities into the client’s platform (B2B). End users were all interacting with client’s interfaces and so we had no direct connect with them.

We wanted to do B2B at scale.

Hence, lot of investment went into building our platforms that allows our clients to onboard users and serve them. However, as a Product Manager, I was highly dependent for my client’s to optimize user flows for best onboarding and conversion.

The critical role of Sales and Partnerships in B2B(2C)

In pure B2B(2C), you’re not directly attracting end users but clients who are willing to pay for your service or product. Whether you end up getting the end users as a result of the deal is a matter of business model.

For big brands with gigantic market shares, attracting clients is more of inbound or your own choice of who you want to partner with, but for brands with smaller shares distribution is an active challenge, daily.

To make it simple to understand in B2B2C context, Apple initially partnered with Goldman Sachs and Mastercard to launch Apple Pay Later, its own buy now, pay later (BNPL) service to end users, in 2023. However, Apple has now decided to discontinue its in-house BNPL service and instead partner with third-party providers, including Affirm, to offer BNPL options through Apple Pay starting later this year.

In above example, Mastercard is also B2B2C, as its core business model involves partnering with financial institutions and businesses (Apple in this case) to issue cards and process payments, which are then used by consumers (C).

For high value high market share brands (Mastercard), B2B is more about partnerships that bring strategic leverage and scale. As a Product Manager in such brands, you want to prioritize your own metrics (As I was optimizing for Increase in Bookings, as primary metric at Booking.com too) and with my partnerships team I was looking to work with businesses that help me make that metric better. Such brands have choice, influence and leverage in such deals. Also, the product development in such brands comes with scale of clients, so you can test markets, understand client needs and build something that many clients want or need. These are partnership-driven B2B2C brands.

However, if you were a niche/local/mid-size brand, still looking for winning market share, then B2B game can become much more about Sales and is more competitive. As a Product Manager in such companies, you will be often surrounded by requests from Sales for features, timelines and client expectations. These are more Sales-driven B2B2C brands.

Let us dive into role of a Product Manager in B2B(2C) companies that are looking to grow market share through a (majority) sales-driven culture. We are excluding partnership-driven high value brands from below.

Product vs. Sales is a wrong argument in Sales-driven B2B(2C) cultures

Sales-led is bit of a dangerous and looked-down term these days, when the world of internet is surrounded by everything becoming product-led.

But, the truth is none of the companies in this niche/mid-size B2B2C can be purely 100% product-led or 100% sales-led until they find their positioning, scale of clients and more.

The balance is more important. You don’t want the company to become 100% sales-led in the long-term because the product will suffer multiple wounds (from different client specific requests) and will be so hard to scale with fast go-to-market. Also, you don’t want to become 100% product-driven too early, until you spend enough time in the market and understand what kind of clients and verticals are willing to pay for your product, what does standardization look like etc.

The right argument is to understand the pros and cons of being sales-led too much and over a long-term horizon. I have often heard Product folks saying “but the business wants this and this is not what product recommends”, but Product doesn’t exclude business.

Product is part of business. And it is the expected from Product Managers to coach Sales the benefits of learning from new paying clients and disadvantages of doing too many custom requests.

Product needs to learn the language of business, and specially of Sales.

So, this is an advice for Product Managers who are in majorly Sales-driven organizations and partially product driven (or trying to be).

So, here’s a framework Product Managers can use in B2B environments driven by Sales

So here’s what I have learnt.

Product Managers in Sales-driven B2B2C strive to build a culture where the capabilities can scale across multiple clients. They want:

1. Able to measure and improve features as many clients give feedback (Driven by Data and Insights)

2. Empowered culture of building products (Act on feedback)

3. Faster go-to-market with clients (Repeatable success)

However, in such an organization it is important to know what Sales is driven by. They want revenues. Good big revenues.

Sales is not incentivized to bring in empowered culture of product teams (doesn’t excite them) or to be driven by data and insights across huge set of clients (exceptions do exist).

However, I would anchor on one bet that matters to both Product folks and Sales folks.

Faster go-to-market, or in simpler terms how soon can one client go live after another. This also makes clients happy no doubt. They want your product and service, and they got it in quick enough. This could also be a competitive advantage besides all other strategic elements of positioning and value propositions.

But Product Managers have not found a way to measure this, track this and show the value of it to Sales. I called it the GTM Tracker.

The Go-To-Market Complexity Tracker

Start measuring the time it takes for clients to go live i .e “time to go live”

Client 1: 2 months

Client 2: 14 days (0.5 Months)

Client 3: 1 day (0.03 Months)

Client 4: 6 months

And then score each client to “product complexity” out of 10.

Client 1: 6.25/10

Client 2: 3/10

Client 3: 1/10

Client 4: 9/10

Time to go live = From the day Sales qualified the client to be interested or hot lead till they went live (first order/first production interaction)

Product Complexity = List down all capabilities of your product and then rate each capability for every client. Let us do this for a CRM software and Sales wants you to provide some features standard, and some others modified, and some are completely new.

Let us say your CRM has standard 8 features. If a client wants those 8 features as it is without any modifications, the product complexity is 0. However, if a client wants some of those features modified, and some to be completely rebuilt, then add a Ýes for those.

Then, you can decide how much you want to penalize the modification or new capability requests. I generally like to give a 0 weightage for clients needing existing features (since this is what we want more), give 1 weightage to modifications and penalize 2x any new capability requests.

Note that you should do this exercise together with Sales, and not alone as Product Manager. For each client requests, map it and find product complexity so both sides are actively aware what is being sold.

Here’s how a sample Go-To Market Complexity Tracker looks like:

So what is the product complexity in this case?

---

Product Leadership Basics is the first live course on offer from Productify.

As an annual paid subscriber, you get free access to this course and one new course every quarter in future.

You will have 4 key takeaways from this course:

1. Understand best practices to create a product strategy

2. Explore recommended ways to hire and nurture talent

3. Compare frameworks and methods for an effective product roadmap execution

4. Get tips on driving business success as a product leader

You will also learn live with other participants, discuss frameworks and case studies.

Date: 3 August,2024 (Saturday)
Time: 9AM to 11AM EST/ 1PM to 3PM GMT / 4:30PM to 6:30 PM IST

Use the CODE PRODUCTIFYNOW at checkout to get 62% off on the ticket price. Valid till 30 July’24. Register:

If someone in your network could benefit from this course, please feel free to share this post and help them get access:

---

In above example, the product complexity is 6.25.

Now for this client, track time it took to take it live.

When you do this for multiple clients, you may end up with a graph that looks like this:

Of-course, this example assumes that time to go live goes up because product complexity is high (cause and effect).

Let us look at three scenarios now:

1. It is indeed true that client go lives become more itme consuming if clients want special features

2. You ended up with a graph where the correlation is weak. Some go lives take time even with standard product features

3. The correlation is absolutely absent. Client go live time has nothing to do with product complexity.

How should you as a product manager handle these three scenarios to your advantage?

The aim is to convince sales that as long as they keep on bringing non-standard product requests, the time to go live goes high, platform costs go high, product debt accumulates and it just becomes worse for the business over the long-term.

Scenario 1: Strong correlation between product complexity and time to go live

This is the ideal scenario for making your case. You can:

1. Show the clear trend that as product complexity increases, time to go live increases significantly.

2. Quantify the opportunity cost of longer implementation times - e.g. "For every month of delay in going live, we lose $X in potential revenue."

3. Highlight specific examples where standard implementations went live much faster.

4. Set goals with sales to reduce average product complexity scores over time.

5. Propose a tiered pricing model that charges premiums for customizations to incentivize standard implementations.

Scenario 2: Weak correlation

Even with a weak correlation, you can still make a case:

1. Acknowledge that other factors besides product complexity impact time to go live.

2. Focus on the outlier cases where high complexity clearly led to delays.

3. Dig into the reasons for delays on low complexity deals - there may be process improvements needed.

4. Propose tracking additional metrics like engineering effort or support tickets to show hidden costs of customization.

5. Suggest a pilot program to streamline standard implementations and prove the potential.

Scenario 3: No correlation

This is the toughest scenario, but you can still take action:

1. Admit the data doesn't show a clear link between complexity and time to go live.

2. Shift focus to other metrics that may show the impact of customization - e.g. engineering capacity, product quality, customer satisfaction.

3. Conduct customer interviews to understand the qualitative impact of customization vs. standardization.

4. Propose a more detailed study to uncover hidden factors impacting implementation timelines.

5. Reframe the discussion around product strategy and long-term scalability rather than short-term metrics.

In all cases, the key is to:

• Acknowledge sales' perspective and revenue goals

• Use data to make your points objectively

• Focus on long-term business impact

• Propose concrete next steps and experiments

• Keep the dialogue open and collaborative

The key of this framework is to drive sales towards thinking in product capabilities and scalability in tandem with client requests, and if they they start doing that, they can sell better in a way that delivery of product and service is faster.

Or worse, if they do not, then you can always show your GTM complexity tracker to show how future client delivery will become slower, with increasing delivery costs (it also helps drive P&L conversations), increasing product and tech debt.

The GTM complexity tracker also helps you prioritize better. When conflicting client requests come up, you can do mapping and then ask for decision making on which feature drives scale and execution, and which ones deviate you from that.

Lastly, do not be afraid of Sales requests about clients needs even if they’re not standard.

Product Managers often find themselves at the crossroads of client requests and standardized offerings. While it's tempting to stick to the roadmap and dismiss unique client requests, this approach might lead to missed opportunities.

Here's why PMs should be open to these requests and how they can leverage them for broader product development:

The Value of Listening to Sales

1. Market Insights: Sales teams are on the front lines, interacting directly with clients. They often have valuable insights into emerging market trends and unmet needs.

2. Competitive Edge: Client-specific requests might reveal gaps in your product that competitors are exploiting or areas where you can differentiate.

3. Revenue Opportunities: Being open to custom requests can lead to securing high-value clients or entering new markets.

From Specific Request to Universal Capability

1. Analyze the Core Need

Look beyond the specific request to understand the underlying problem the client is trying to solve. This core need might be shared by other clients or industries.

2. Evaluate Scalability

Assess whether the requested feature or capability could be generalized to benefit a broader user base. Consider how it might be adapted for different use cases or industries.

3. Conduct Market Research

Use the client request as a starting point for broader market research. Are other clients facing similar challenges? Is this an emerging trend in the industry?

4. Prototype and Test

Develop a prototype or MVP (Minimum Viable Product) based on the client request. Use this to test with other clients or in similar verticals to gauge wider interest and applicability.

5. Modularize the Solution

Design the solution in a modular way that allows for customization while maintaining a core functionality that can be widely applied.