What is your strategy for how much engineering resources you dedicate to custom work for large enterprise accounts vs core roadmap?

In general, I am not a proponent of building custom solutions for a single customer.  However, if there’s a large customer who wants something that will serve the broader customer base, then we’ll consider it and prioritize it accordingly.  Once you ship something, it’s out there in the wild forever (until you sunset it).  And it’s tough to sunset things since someone will end up using it and relying on it.  So, product managers need to be extremely prudent with their decisions about what makes it into the product.  And they need to be able to stand up and say no if the request being made is not right for the product, no matter how large or important the customer requesting the feature is.

In the case where a customer feature request doesn’t fit in line with our product direction, I’d suggest working closely with the account team and customer to really understand the problem they are aiming to solve to see if there are alternative approaches that can be used to meet the same need.

I usually ask myself a few questions when we are being asked to commit resources to 'tasks outside of the strategic product roadmap'. The primary aim is to not deviate from the core road map unless the short-term benefit (retaining the customer) is justified. 

1. Is this feature request bespoke only and doesn't require any product-level change? - If yes, offload it to the 'professional services team' and bill the customer directly for the work done. Usually larger enterprises prefer getting the one-off implementation done through a verified team rather than trying to go through the hassle of implementing them in-house. 
2. Do we need to enhance the core product to support this custom work? - If yes, does this help in repeat sale / add value to other customers? - If yes, get it into the product roadmap / implementation cycle.

If the answer to both questions is no, try to renegotiate with the customer - if even this fails and retaining the customer still takes priority, commit resources at the cost of the planned roadmap - we try to keep this lower than 10% of the overall effort in a release. During the early stages of the product, it may be as high as 25%, but we would want to minimise the bespoke work as the product matures. The amount of bespoke work being done is also one good proxy measure of the product market fit.  

This is a great question! In the 5 B2B enterprise SaaS organizations I have worked practiced no custom development! Although we may build specific features for target customers and in that case, each company has done this differently and all of the strategies have pros and cons. My favorite method is to have each product group or squad dedicate a portion of their roadmap to support revenue or Paid Monthly Active users.

In practice, this would look like making sure the capacity of the engineering group is planned to take care of SLO-bearing work first:

• Bugs

• Security vulnerabilities

• Availability bugs

Next, the remaining capacity would be allocated per the product manager's KPIs these product groups will be incentivized on different metrics but some of these can be:

1. % growth of paid account adoption - shipping features and issues that will drive paid adoption

2. New logo win rate - shipping features and issues that will close the gaps with competition

3. Reduce churn and contraction - shipping issues that target reasons accounts cancel

This is a big part of why I love working in the mid-market - we flat out refuse one off features for enterprise accounts. My roadmap is so much more scalable and predictable than when I was large enterprise focused it's a joy. 

Looking back, even when I was a large enterprise PM if I had it to do all over again I would just refuse custom work. It's almost never worth it. Sure, I get it, if it's a super minor feature you are just accelerating that's appicable to more than one customer for a $5M deal go for it. But "custom work" implies more of a one off. If you need to customize something for someone it's probably because you're not serving a broader use case well enough and should look there instead.