How to Own Your Roadmap: A Framework for Managing Custom Work

Never judge a book by its cover. Never judge a technology company based solely on the amount of custom work they do.

The latter saying isn’t likely to get its own chapter in the next Silicon Valley best-selling book on software development, but I believe it’s well worth exploring. I say this as a recovering, stubborn SaaS purist. Years ago, I considered everything that wasn’t beautifully architected, infinitely scalable SaaS suitable for all customers out of the box to be flawed. Custom work was always a symptom of a deeper problem somewhere in the organization. I personally know scores of product managers and engineers who stood with me, some with even more rigid standards. Custom work traumatized us with decimated roadmaps and countless detours away from idealized versions of our software.

As my vantage point has changed, I’ve seen custom work have strategic value when used appropriately. The trick, like in so many places in life, is balance and finding the right one for your organization. So I’ve backed off my rigid stance in favor of a more pragmatic view.

But backing off the stance didn’t make me any less judgmental. Any time the topic of superlatives comes up within my friend group, I consistently win “most judgy”. I’m not proud of it, but I’m also not going to pretend they’re wrong. I have a lot of takes…what can I say? It’s tempting, especially for someone with my predilections, to judge that book by its cover. My personal and work-life modes aren’t identical, but I 100% have been guilty of the exact judgment in that opening line.

So today, I want to talk about how it’s totally ok to judge a technology company on a single concept related to custom work…just not the binary “Damn, this company lost their way building so many things custom”. I propose that it’s actually the ratio of custom work to that beautifully architected, infinitely scalable stuff, and how a company manages it, that matters. Do they know how much Custom work they truly do? Do they understand the opportunity costs and the impact on teams and development practices? Do they have any ability to control it? Judge away once you have that context! This is not a redemption arc. Clearly we’re gonna keep judging!

Core and Custom Work, Formally Defined

Let’s define Core product development work as:

Deliverables that advance your company strategy, align with your mission, and whose scope and timelines emerge organically from healthy product practice.

Let’s define Custom product development work as:

Deliverables and implementation work whose scope or timeline is driven by a minority stakeholder/customer interest rather than by healthy product practice.

Examples:

1. Customer A wants to accelerate Feature X in the roadmap from the end of next quarter to the end of this quarter in exchange for a renewal + $250k in additional subscription modules. ⇒ Custom
2. Customer B provides formal feedback on Feature Y to the product team. The team determines it’s valuable globally and slots it into an upcoming plan based on how it ranks in the backlog. ⇒ Core
3. Customer C threatens to churn if Feature Z does not contain an integration specific to their business. ⇒ Custom
4. Customers D, E, F, and G pull members of the product development team, the people allocated to build software, into performing the implementation. ⇒ Custom

The implementation piece is a commonly overlooked one and I intentionally put that work in Custom. The engineer who drops what they’re doing to run data migrations or execute scripts in a client environment is doing work unique to a customer, whether or not anyone wants to book it that way. We’ll talk about how FDEs fit in later.

Necessary infrastructure, usability, reliability, performance, supportability, hardening, maintenance, bugs, tech debt, and all the things your marketing team likely isn’t running campaigns around absolutely DO fit into one of the above buckets and is most often considered Core. If your product development team does work outside of those two buckets, it may be worth tracking, but we’re only concerned here with the ratio of these two to each other.

Any time I enter a new engagement, whether it’s been as a full-time employee or as a consultant, I overlay their strategy against their approach to execution. I want to see if the high level concepts discussed in board rooms and strategic planning sessions are ACTUALLY distilled into executable backlog items for product development teams. Talk is cheap. While backlogs are often referred to as tactical artifacts, they’re the actions you take, hopefully backing up the talk. Embedded within that process is exploring the amount of Custom versus Core work their product development teams execute.

Know Your Numbers

Most of us, especially those in B2B and B2B2C, have seen or participated in companies that consider Examples 1 and 3 standard operating procedure. Passing on revenue and customers is a luxury only the healthiest of businesses can afford. While those examples illustrated the obvious situations where Custom work shows up, not all Custom items get introduced in the form of a massive contract or a sternly worded letter from a disgruntled customer exec to a tech company CEO. A lot of operators have felt the death by a thousand cuts from pernicious, continued patterns of behavior where customers control so many small pieces of the roadmap that available cycles and budget to build exciting new things get strangled even without the big, signed-contract-driven headliners that usually suck all the oxygen out of the product planning room.

A few posts back with respect to goals, we talked about how if you don’t stand for something, you can fall for anything. This is no different. Every organization should know their current ratio of Core to Custom work denominated by effort and/or cost. From there, you set a target for it in order to manage against it.

Look at your backlog. Take the union of that and any support or implementation queues that might also exist where developers show up as assignees. Tag all the items as either Core or Custom. I recommend using story-point-like effort units to simplify all the items into a common effort point currency, but you could use $s spent or person-days. The unit is somewhat arbitrary as long as it’s applied consistently. Total up the Core and Custom items and express that as a ratio.

I have spent most of my career with B2B and B2B2C companies between $5m and $500m in revenue and would say most sit in the 40:60 to 70:30 range. I’ve observed that the more Services-heavy your full company org chart is, the more your product development work has a Custom lean to it.

There may be a temptation to look at an implementation queue or backlog and say “Looks emptier than last cycle. The 70% Custom run rate we’ve been at for 2 years is over. Our actual baseline is 40% if we start today.” Don’t do that. Unless you made structural changes to your business, Custom work WILL find a way. Include a Custom work buffer for…reality.

Much like how nine out of ten drivers think they’re better than average, a near-universal truth is that everyone thinks they’re much higher in Core than they actually are if you really dig into the numbers.

Don’t build roadmaps without knowing your numbers. You can, but it’s like trying to get or remain healthy based solely on vibes. Sure, spot checks in the mirror and your general assessment of your body’s willingness to seize the day over time are mildly useful data points, but they’re often misleading, noisy signals. Freestyle things long enough and you’re likely to find trouble. At a minimum, why not see a doctor and get bloodwork? Then get dialed in by understanding your dietary needs and maybe leverage a couple of the hundreds of scales, monitors, and wearables on the market today. Establishing steady Core vs Custom numbers is one of many tools for getting your product strategy fit.

On FDEs

Since forward-deployed engineers are all the rage these days, it’s worth a quick note on how they fit into this model. Palantir made the term more of a household name, but the idea of embedding an engineer inside a customer environment to make a vendor’s products actually work has existed for a long time. Before I moved to product management, I was a “technical consultant” deployed to customer sites for months at a time to deliver our products and services while collecting feedback. It was a great job and I learned a lot. Forgive me for not matching the enthusiasm tech media brings to this glamorous and revolutionary concept today.

That said, fitting FDEs into the model is simple. You have two clean options. Carve them out as a segment of engineers sitting outside product development work entirely, in which case their effort doesn’t count toward either side of the ratio, or fold them in and run a larger Custom allocation. Remember, it’s owning your ratio that matters, not the specific amounts.

Rebalancing

Once you know your current ratio, get a shared understanding across your organization of what your optimal mix is. For some, that ratio is 100:0 Core:Custom. In my experience, most companies target somewhere between 90:10 and 80:20, solid distances from the ratios they initially discover they’re living. And most designate the 10 to 20 points of Custom work to use as a wedge to go deeper with large, strategic customers, the kind with asymmetric upside, whether that shows up as outsized contract value, follow-on opportunities, or exposure to accounts and segments you couldn’t otherwise crack. When the mix is working, it feels like walking two well-trained dogs. You set the pace, both keep it, and neither one drags you down the block.

So what happens when you do find your numbers and you realize that you’re well below your Core target? Generally, what I’ve seen is that companies with low Core numbers have quietly hardened their processes around this reality. I see a lot of teams throwing up their hands and saying, “Well it’s kind of always been this way. I don’t like it but it’s just part of working at XYZ.” The hardening takes different forms, whether it’s a sales team with extra license to sell more “creative” deals, a CEO who pushes unhealthy deals through on sheer will or board pressure, a finance forecasting model that needs services revenue to bail out the subscription side of the business, a product team afraid to take risks, or a customer success team getting beat up so badly over base-product gaps that signing up for custom work becomes the pain release valve.

If reversing course were easy, this wouldn’t be an issue at so many organizations. The calcified processes and behavior require way more than a well-constructed argument in a PowerPoint. This is where having experienced leaders and great collaborators comes into play because generally, change requires sacrifice, often in the form of temporarily lowering targets and/or taking on more pain and risk. A classic one step back, two steps forward motion.

In most cases, the absolute wrong thing to do is to turn 180 degrees and decide that a 50:50 company today can be 90:10 tomorrow. It’s the roadmap version of trying to get fit by losing 12 lbs in a week. Unless you’re a nimble startup, where radical change is part of the playbook, too many things will break. I advocate for something much more boring, mechanical, and simple. Build a mini Core vs Custom roadmap where the only item you’re charting is this exact ratio. A 50:50 to 90:10 transformation could look something like this:

If you’re at 50:50 today, first get your teams and leadership to acknowledge the facts on the ground. From there, identify the first level you can jump to next quarter that creates friction, but doesn’t put critical targets, people, deals, etc. at real risk. Maybe that’s a modest 55:45 target. After you prove the world didn’t end with that change, bump that to 60:40 the following quarter. If a big conference or milestone is looming, the kind that encourages a path of least resistance and a slide back into old habits, maybe you let 60:40 ride for consecutive quarters. Then bump it up. And again. If team sizes expand and you suddenly find the capacity to do more in absolute terms, decide whether to book the increased Core output from the expansion alone or press the transformation further.

There’s one more critically important caveat to making this work. You MUST get buy-in across all stakeholders that, once a plan for a given time period is set, Core work is sacred and its allocation cannot shrink inside that period. Sure, be agile by swapping items around. It’s fine if you end up increasing Core work at the expense of the Custom buffer you built into your numbers, but never draw down against Core. People will immediately lose confidence in this process if you do. You might ask, “But this is what always happens. We set a plan and then it gets blown up three weeks into the quarter. Why bother?” Implicit in that question is an acknowledgement that your actual Core:Custom ratio is not what you believe it is. Backtest your numbers. The data might be lumpy, but it won’t lie. Allow a big Custom buffer to dampen volatility if it has you concerned.

Reserved Judgment

Custom work is not the automatic red flag many of us were trained to treat it as. Used appropriately, it can unlock big things within a company strategy, but only if you’re willing to track it, forecast it, and defend whatever ratio you land on. There’s no correct number and no universal recipe, and every company finds its own equilibrium. So no, I haven’t stopped judging technology companies, and I’m not asking you to either. Just judge the ratio, not the cover.