It is the annual technology review, and the agenda has eleven projects on it. Each one gets twelve minutes, each has a champion, and each has a return calculation that clears the hurdle. By the end of the afternoon every project has received something, the total matches last year’s number within a few percent, and the meeting is judged a success because nobody left angry.
That meeting allocated nothing. It ratified a distribution that already existed, and the reason it felt productive is that the hardest question was never asked out loud: which of these eleven would you fund if you could only fund three?
The eleven-project meeting is not a failure of analysis. Every calculation in it was probably sound. It is a failure of comparison, because a hurdle rate tells you whether a project is worth doing in isolation and never tells you which of eleven worthwhile things you should actually do with the people you have.
This article is about answering that question. It sits downstream of the decision about which product lines deserve resources at all, which is covered in which product lines deserve investment. Once that is settled, the money still has to be pointed somewhere specific, and that is where most technical budgets quietly lose their effect.
Where does the next R&D dollar actually go today?
In most industrial businesses it goes wherever last year’s dollar went, adjusted slightly. The distribution is inherited rather than chosen, and the annual review confirms it rather than setting it, which is why the shape of the portfolio barely changes from year to year.
Watch how the number gets built. Each line submits what it needs, the total comes in above what is available, and finance applies a percentage reduction across the board. Everybody loses the same proportion, which feels fair, and the relative allocation, the thing that actually determines what your product line looks like in five years, is exactly what it was before the exercise started.
Underneath that is a second inheritance nobody votes on. A large share of the engineering budget in most businesses is committed before the meeting begins: sustaining work, compliance updates, customer specials, cost reductions on existing products, and the long tail of change orders that arrive whether or not anyone planned them. In many plants that is well over half the capacity, and it is spoken about as though it were a fixed law of nature rather than the accumulated residue of past product decisions.
None of that is an argument against sustaining work, which pays for itself many times over and is usually the difference between a product line that ages gracefully and one that has to be replaced. The argument is only that it should be sized deliberately rather than allowed to take whatever it takes, because a category that expands to fill the available capacity is not a category anyone is managing.
It is worth measuring that share before anything else. Count the hours your technical people actually spent last year, sorted into sustaining work, incremental improvement on existing products, and genuinely new capability. Most operators are surprised by the result, and the surprise is usually in the same direction: the new-capability number is far smaller than the budget implied, because the budget was written in dollars and the work is done in hours.
There is a third inheritance hiding in how the number is expressed. Budgets are set in dollars and the work is done by particular people with particular skills, and those two things are not interchangeable. A funded program that needs a controls engineer you do not have is not funded, whatever the ledger says, and a business that hires slowly can carry a technical budget it is structurally unable to spend on the thing it intended.
Notice that none of these inheritances involves anyone making a bad decision. Each year’s allocation is a reasonable adjustment to the previous one, made by competent people under time pressure, and the cumulative result is a distribution that nobody chose and nobody would defend if it were proposed fresh.
The last inheritance is the hardest to see, because it looks like discipline. Projects that were funded years ago continue to be funded, not because anyone re-examined them, but because stopping something requires a decision and continuing it does not. A portfolio full of projects nobody would start today is the normal end state of an allocation process with no stopping rule, and it is entirely compatible with every individual project having cleared its hurdle rate when it began.
Why even spreading feels fair and produces nothing
Because a small amount of money applied to a large number of bets funds activity rather than outcomes. Each line gets enough to keep working and not enough to finish anything that changes its position, and the result is a portfolio of perpetual half-projects.
The mechanism is simple arithmetic about thresholds. Most technical work has a minimum size below which it produces nothing usable: a product that is almost ready does not ship, a process that is almost qualified cannot run, a material that is almost characterized cannot be specified. Funding at eighty percent of that threshold does not buy eighty percent of the result. It buys zero, and it does so quietly, over several years, while the reporting shows steady progress.
The threshold argument has a second half that is worth stating separately, because it is the part that makes even spreading actively expensive rather than merely ineffective. Half-funded work still consumes the scarcest thing you have, which is the attention of your best technical people. Five projects at forty percent funding occupy five sets of people who each carry the switching cost of an unfinished thing, and the cost of that fragmentation does not appear anywhere in the budget that created it.
The same threshold effect explains a pattern most operators recognize: the business that has been working on the same handful of promising developments for five years without shipping any of them. Nothing went wrong in any single year. Each year the available capacity was divided among all of them, each advanced a little, and none crossed the line where it becomes a product.
Even spreading is also the allocation that requires the least authority, which is the real reason it persists. Nobody has to be told their line is not the priority. Nobody defends a decision. The process is entirely reversible and completely defensible, and it produces a technical portfolio that looks like an organization chart rather than a strategy.
There is a version of this that is worse, because it looks like rigor. Some businesses rank projects by return on investment and fund down the list until the money runs out. The ranking is sound as far as it goes, and the projects with the most reliable return calculations are almost always the incremental ones, because their outcomes are close to what already exists and therefore easy to forecast. The bets that would change your position have the least predictable numbers, so a ranking by calculated return systematically defunds exactly the work that would matter most.
Watch for the milder version too, which is spreading across horizons rather than across lines. A portfolio where every project is due to deliver within eighteen months is a portfolio with no capability work in it at all, however concentrated it looks on paper. The spread has simply moved to a different axis, and the effect on your position five years out is the same.
There is one more failure worth naming, because it disguises itself as customer focus. A portfolio driven entirely by what customers are currently asking for will produce a steady stream of improvements to things customers already know they want, and nothing that changes what they could ask for. Customer demand is an excellent guide to maintenance work and a poor guide to capability, because customers describe the problem in terms of the solution they already have.
The practical test is to look at what your allocation would produce if every project succeeded exactly as planned. If the answer is a somewhat cheaper and somewhat improved version of the line you have today, the allocation is not wrong in its details. It is wrong in its shape, and no amount of better project selection inside that shape will fix it.
Funding at eighty percent of the threshold does not buy eighty percent of the result. It buys zero, quietly, over several years.
What horizon should an R&D dollar be judged on?
A longer one than your reporting cycle, and the gap between the two is the central problem in technical allocation. Money spent on capability pays back over years, while the review that governs it happens quarterly, so the work that fits the reporting window wins by default.
The method I use for this is the Decade Allocation, which judges an investment on what it produces over roughly a ten-year horizon rather than on what it returns inside the planning cycle. The practical effect is that it changes which question the calculation has to answer. Instead of asking what this project returns by next year, it asks what position this buys by the end of the decade and what it would cost to acquire that position later if you skip it now.
That second half matters more than it sounds. Most capability has a price that rises with delay. Process knowledge compounds through the products it touches; a supplier relationship or a material qualification that takes three years to build takes three years whenever you start it; and a competitor who begins now will be that much further along whenever you begin. The cost of waiting is rarely zero, and it almost never appears in the calculation that justified waiting.
The horizon question also changes who should be answering it. A project judged on a two-year payback can be evaluated by whoever owns the line, because the evidence arrives within their tenure and their measures. A capability judged over a decade cannot, because almost nobody in the chain will be in the same seat when it pays. That is not an argument against the horizon. It is an argument for the decision sitting with whoever is genuinely accountable for the business rather than for this year’s result, and for writing the reasoning down so the next person inherits the logic along with the commitment.
None of which means every project gets a ten-year justification. Cost reductions, sustaining work, and customer-driven improvements are judged on their own short horizons, and they should be, because that is genuinely what they are for. The horizon question applies to the portion of the budget meant to change your position rather than maintain it, and the first useful discipline is to name that portion explicitly rather than letting it be whatever is left over.
Be concrete about what counts as position-changing, or the category will absorb everything. A useful test is whether the work would change what a customer could say about you, rather than what your cost sheet says about you. Both kinds of work are necessary, and only one of them moves your position, so the boundary has to be drawn by someone who is not being asked to defend their own project.
The reserve also needs a name and an owner, or it will be raided in fragments rather than all at once. A week here for an escalation and two weeks there for a specification change is how a protected share disappears without any decision to spend it, and everyone involved can honestly say they never touched the reserve.
Set the split as a policy before the projects are discussed. A fixed share of technical capacity reserved for position-changing work, stated in hours rather than dollars, is one of the few allocation decisions that survives contact with a busy year. Without it, the reserve is the first thing consumed the moment a customer escalates, and the escalation always comes.
Why the returns arrive late and lumpy
Because capability accumulates quietly and then converts all at once. A material qualification, a process capability, or a design platform produces nothing measurable for a long time and then appears in several products in the same year, which makes the spending look wasteful right up until it does not.
The method I use for holding that line is Compound Patience, which says the returns on this kind of investment only materialize if the direction is held long enough for them to compound, and that switching direction resets the accumulation rather than redirecting it. The practical consequence is that the worst allocation pattern is not underfunding. It is funding well for two years, stopping in year three when the results are not visible, and starting something adjacent in year four.
That pattern is common and it is usually well intentioned. The two-year point is exactly when the spending has accumulated enough to be noticed and the output has not yet arrived, so the project is at its most vulnerable precisely when abandoning it wastes the most. The organization learns from each cancellation that technical bets do not pay, and the next allocation is spread even thinner, which guarantees the lesson repeats.
The same logic explains why acquiring a capability late is usually more expensive than building it early, which is the point that connects the two ideas. If the accumulation is what creates the position, then a competitor who started three years ago holds three years of accumulation that money cannot instantly replace. You can occasionally buy it, through an acquisition or a hire, and the price reflects exactly what it would have cost you in time.
Guard against it with evidence that moves earlier than revenue. Ask what should be observable at six months, at one year, and at two, and make those the checkpoints: a process running at a defined capability, a customer agreeing to trial, a material passing a specified test. Those are checkable, they arrive on a human timescale, and they let you hold a direction for the time it needs without flying blind.
Build the checkpoints into how the work is reported rather than into a separate governance layer. If the technical review already covers progress monthly, the checkpoint belongs there, phrased as the specific observable you named at funding. A checkpoint that lives in its own process gets skipped in a busy quarter, and skipping it is indistinguishable from passing it right up until the two-year decision arrives.
Direction is the thing being held, which is worth distinguishing from method. Holding a direction means continuing to build the same capability, and it is entirely compatible with changing how you go about it when the evidence says the current approach is not working. Confusing the two produces either a business that abandons capabilities every time a method fails, or one that persists with a failing method because it believes it is being patient.
The counterpart discipline is equally important. Patience applied to a bet whose early evidence is not arriving is not patience, it is drift, and the difference between the two is whether you wrote down in advance what you expected to see. Holding a direction because the checkpoints are being met is discipline. Holding it because nobody wants to admit the spending was wasted is something else, and the second is far more common in businesses that have recently been criticized for impatience.
How do you choose which bets get the money?
In a sequence, and the order matters because each step removes candidates the next step would otherwise waste time on. Five steps, starting from the lines that already passed the portfolio screen and ending with money attached to a small number of named bets.
- Start only with funded cells. A technical bet aimed at a product line you have decided to harvest is not an allocation question, it is a contradiction. Take the funded cells from the portfolio review and ignore everything else.
- Separate maintenance from position. Split every candidate into work that keeps the current position and work that widens it. Fund the maintenance floor as a cost of staying in business, and allocate deliberately only above that floor.
- Ask what each bet does to the named advantage. Take the sentence customers used to describe why they buy from you in that segment, and ask what this project does to it. A bet that does not touch that sentence is a bet on something other than your position.
- Size each bet at its threshold. Work out what it costs to reach a result you could actually judge, and treat that as the minimum. If the total exceeds what you have, cut the number of bets rather than the size of each.
- Write the stopping condition with the funding. Name what you expect to observe at six months, one year, and two, and what result would mean the bet is finished or dead.
Two details make the sequence work in practice. First, run it on capacity rather than on dollars, since hours are what actually constrain the work, and a plan that fits the budget but not the staffing will fail silently. Second, take the maintenance floor from evidence rather than from what people ask for: count what sustaining work actually consumed last year, which is almost always higher than the number anyone estimates, and set the floor against that.
One addition to the sequence is worth making explicit at step one. Check whether each candidate would still make sense if the product line it serves were cut in half or doubled. Bets that only work at exactly today’s shape of the business are more fragile than they look, and the ones that survive both directions are usually aimed at capability rather than at a specific product.
Step four is where most of the discipline lives, and it is the step organizations skip because it is the one that requires telling somebody no. The arithmetic is unforgiving: if you have the capacity for three real bets and eleven candidates, you either make three or you make none, and the eleven-way split will feel better for about eighteen months.
Publish the ranking with the reasoning, including for the bets that did not make the cut. A portfolio where people can see why they came fourth is one where coming fourth is survivable, and where the case for next year can be built on the specific thing that was missing rather than on lobbying.
Step five is what makes step four survivable. A no this year with a defined condition under which it becomes a yes is a very different conversation from a no with no explanation, and a portfolio where funding visibly moves when evidence arrives is one where people can accept being second in line.
How much should one bet get, and when do you stop?
Enough to produce evidence you could actually judge, and no more until that evidence arrives. Stopping is then governed by the checkpoints you set when the money was granted, not by how the quarter went, who is under pressure, or which champion is most persuasive in the room.
Sizing works backwards from the evidence rather than forwards from the budget. Name what would have to be observable in eighteen months for the bet to have earned its next round, then cost the path to that observation. That figure is the threshold, and anything below it funds activity instead of an answer. It is a more honest number than a percentage of revenue, because it is derived from the specific thing you are trying to learn.
Resist setting the amount by reference to what the line spent last year. Last year’s figure is the output of an allocation nobody designed, and using it as the anchor imports every inherited distribution described at the start of this article back into a process built to replace them.
Small businesses do this better than large ones more often than you would expect, because the concentration is forced on them. At the industrial tank liner manufacturer I owned, the technical effort went toward a floor liner product aimed at larger and more profitable jobs, rather than toward a broad program of improvements across everything the company made. There was no capacity to spread thinly, so the decision got made properly, and that constraint turned out to be an advantage.
There is a related trap in how the money is counted. A bet funded at its threshold but staffed with people who are also carrying their normal workload has not been funded at its threshold, and this is the most common way a concentrated plan quietly becomes a spread one. The test is whether somebody’s calendar changed, not whether a budget line exists.
Staging is how you keep concentration from becoming recklessness. Fund to the first checkpoint rather than to completion, and make the next tranche contingent on what that checkpoint shows. This is not the same as funding thinly. Each stage is fully funded for what it has to accomplish; what is conditional is whether there is another stage, and the conditions are written down in advance.
Staging also gives you a defensible answer to the board question that usually forces spreading, which is what happens if the concentrated bet fails. The honest answer is that you find out at the first checkpoint, for a defined fraction of the total, and reallocate. That is a materially better risk position than eleven simultaneous bets that each fail invisibly over four years, and it is worth saying in exactly those terms.
Watch what happens to the people when a stage ends, because that is what determines whether anyone will propose a bold bet next time. If the team on a stopped project is redeployed to good work, stopping is a normal portfolio event. If it is treated as a failure attached to individuals, every subsequent proposal will be engineered to be unstoppable, and you will get long, safe, unkillable programs instead of real bets.
Stopping deserves as much design as starting. The question at each checkpoint is not whether the team is working hard, which they usually are, but whether the evidence you named has appeared. When it has not, stop and reallocate to the next bet in the ranking, and say plainly that the bet did not work rather than describing it as a pause. A portfolio with real stopping decisions can afford bolder starting ones, which is the whole point of having the rule.
Fund to the first checkpoint, not to completion. Each stage is fully funded for what it has to accomplish. What is conditional is whether there is another stage.
Questions that come up every time
What percentage of revenue should we spend on R&D? The benchmark is the wrong instrument. Two businesses spending the same share of revenue can have completely different technical positions depending on how concentrated the spending is and what share of it is sustaining work. Measure your split between maintenance and position first, because that ratio tells you far more than the total does.
How do we justify a ten-year horizon to an owner or a board? By presenting the cost of the alternative. The useful framing is not that this project pays back slowly, but that the position it buys will cost substantially more to acquire in five years, if it is available at all. Pair that with the near-term checkpoints so the ask is not a decade of faith, but two years to a specific piece of evidence.
What if a customer demands a development we did not plan for? Fund it from the maintenance side of the split, not from the position-changing reserve, and recognize it as revenue-protecting work rather than growth work. The discipline is in refusing to let the reserve absorb it, because customer demands never stop arriving and the reserve exists precisely to be protected from them.
Does this apply to a business with two engineers? More so. With two engineers the entire question is which of them spends which quarter on what, and a decision to work on three things at once is a decision to finish none of them that year. The arithmetic of thresholds is harsher at small scale, not gentler.
Who should own the allocation decision? One person, with the technical leaders supplying evidence and the line owners supplying the customer sentences. A committee that requires consensus will spread the money, because spreading is the only allocation nobody has to object to, and the spreading will be attributed to rigor.
How do we handle a bet that is working but slower than planned? Check the evidence against the checkpoint rather than the date. Slower with the expected evidence appearing is a scheduling problem and usually worth continuing. On schedule with none of the expected evidence is the one to stop, and it is the one that gets continued, because the reporting looks healthy.
About the Stagnation Assassin
Todd Hagopian is a Fortune 500 transformation executive who has generated $3B in shareholder value across Berkshire Hathaway, Illinois Tool Works, Whirlpool, and a Fortune 1000 company, where he serves as Global VP of Product Strategy and Marketing. Known as The Stagnation Assassin, he is the author of two published books: The Unfair Advantage: Weaponizing the Hypomanic Toolbox and Stagnation Assassin: The Anti-Consultant Manifesto. His blog is published in 15+ languages and read by operators worldwide. Bring him to your stage via his speaking page or connect with him on LinkedIn.
If the same eleven projects appear on the agenda every year, the allocation is being made by the calendar rather than by anyone in the room. Request a free Decision Velocity Audit and I will measure how long a funding decision actually takes in your business, and where it stalls.
See also: What Should Happen in a Portfolio Review?, The Blunt Guide to Product Portfolio Strategy