The feature factory is usually described as a discipline problem. Teams say yes too often. Product managers are not senior enough to push back. The intake process is too loose, the prioritisation model too soft, and the fix is somewhere in a better scoring framework.
But that description is not accurate.
Most companies that end up building whatever their customers ask for did not get there through weakness but through competence. They were responsive and commercially disciplined. The bill arrives years later, when the roadmap belongs to someone else and nobody can point to the moment it was handed over.
UBench is a useful case precisely because it was never a company in trouble. Twenty years in the automotive claims market, profitable, working with the largest leasing and insurance players in Europe.
Manuel Medinger, who joined as CEO in 2022, puts the starting condition bluntly.
"We were too busy to change. And that is always a very bad excuse, because being too busy is basically setting priorities."
What follows are the mechanisms that moved UBench out of that position.
Reactive requests are a symptom of an absent roadmap
Hiring a more senior product manager does not fix the feature factory, because the requests are not the problem, they are a symptom of it.
"If there's a void of your own product roadmap and your strong product vision, you're getting a lot of reactive requests."
Consider what happens in a quarterly meeting with an enterprise client when there is nothing to show them. They will bring their own agenda, their own solution, sized to their workflow, framed as urgent.
This changes what the fix looks like. A better process for saying no does not help when there is nothing to say yes to. Reactive work does not get pushed out. It gets crowded out, by a roadmap of your own that is worth defending.
Which is why UBench's first move was organisational rather than procedural. A vision does not appear from nowhere, it needs people whose job it is to have one.
"A strong product vision requires a strong product team. So we said we actually need to build the team."
The purple button
Here is the simplest change in the whole story, and the easiest to copy.
Customer one wants a red button. Customer two wants a blue button. The reactive organisation builds a red button and a blue button. Each request was reasonable, each shipped, each client was satisfied. The cost arrives two years later, when the company is maintaining a dozen versions of its own product.
The alternative is a question. Should this be a purple button?
"We should have had probably a discussion about shouldn't it be a purple button, and then discuss again with the client rather than letting them lead with the solution."
Going one step back, to what they were actually trying to do, and then returning to them with something that serves them and everyone else at the same time.
Manuel says his product managers now do this to him constantly. Don't think in solutions, go back to the problem. It is now engraved in the team, and it is what let them stop building things they should never have built in the first place.
There is a simple way to test whether the reflex exists in an organisation. When a request arrives, does anyone ask what problem it solves before someone asks how long it will take?
Saying no is a capacity decision
Most B2B companies stall here, because "stop taking custom requests" sounds like a policy nobody can afford to enforce. UBench never enforced it as one. They treated it as a number.
Manuel is direct about the moment that tests it. At some point a request arrives that you would previously have built, and refusing it means leaving revenue on the table with no alternative to replace it. There is no process that removes that moment. What a process does is make it a decision the company has already agreed to, rather than one taken under pressure in a client meeting.
The mechanism he would recommend to someone starting today has a few moving parts.
- Segment the clients. For example: for this client you still do custom work. For that one, you no longer do.
- Fix a percentage of engineering capacity to the product roadmap. Change requests from each customer segment are then timeboxed against what is left.
- Move the percentage over time. The custom share should fall quarter by quarter, and someone should be monitoring that number.
And then the part that is easy to miss:
"Be a bit forgiving if that process hasn't been followed up a hundred percent. But over time, you should make sure that these metrics are being kept."
The approach is firm about the direction and forgiving about compliance. The first year is when a single exception turns into the new default, and a rule enforced too rigidly gets abandoned the first time a big client pushes hard. Watching the number rather than policing the process is what kept it alive.
In a B2B business where a handful of customers carry a significant share of the portfolio, you cannot be too rogue about the decision. The threshold is not there to let you ignore your largest clients. It is there so that when you do accommodate them, it is a choice with a visible cost rather than a reflex.
The 90 day plan that took 360 days
The transformation roadmap was built for 90 days. It became, roughly, a 360 day one.
"If you run or if you walk or if you crouch, it almost doesn't matter as long as you start, because you will accelerate."
The roadmap was never meant to be executed line by line. Two years on, the leadership team still pulls the slides back up to check the direction against what has actually been done.
The deadline's real function was to force a commitment: every member of the leadership team had to name their own initiatives, in front of each other, and own them. That is the thing that cannot be delegated, and it tends to be the best available predictor of whether a transformation is still alive twelve months later.
Writing the plan down mattered even though nobody started living it immediately. An unwritten plan gets quietly ignored by whoever disagrees with it; a written one gets challenged instead. That friction is worth having, because objections raised in the open can be answered, while silent non-compliance only surfaces months later.
Then comes the part that gets left out of most transformation stories. Not all of the early steps work. That is not the change failing, it is what the first months look like.
What turns it around is a loop rather than a plan. Small things ship. The organisation sees the direction is producing something. Clients start saying the new approach was right, which is far more persuasive internally than any leadership presentation.
That feedback gives the whole company energy to keep going, and the pace picks up from there.
What a CEO has to do differently
Transformations are usually described as top down, which is only half true. The executive team cannot run the change, but nobody else can create the conditions for it. Two of Manuel's choices are worth naming.
- Taking accountability. In front of his own leadership team, he named the things he knew he was not doing well, what he owned, and what he would do about it. It is the least costly and most effective thing a leader can do, and only a few do it because being the first in the room to name your own gaps is rarely comfortable.
- Handing over ownership. He told a member of his team that the responsibility was now theirs: it was their space to own, and the lead was theirs to take, even where he had a view of his own.
Holding back an opinion you obviously have takes real discipline. It is also the only way a leadership team learns to carry a decision rather than ratify one.
"I should own, but I should not take the room."
Mindset cannot be trained, which is why it comes first
"Mindset is much more important than skillset, because skills you can typically train. But the mindset of being willing to change..."
Skills can be hired, taught, tested. Willingness to change cannot be, and without it nothing else lands.
This is also why the change has to start at the top. Nobody below the executive team can authorise people to stop firefighting long enough to think, and that permission only counts when it shows up in the calendar: hours taken back from a quarter that still has targets attached to it. The team is being asked to hold the current pace and redesign how they work at the same time. That trade has to be made visible and carried at senior level, or everyone will assume the day job still comes first.
Manuel's own rule for the decisions themselves is simpler: the cost of not taking a decision is higher than the cost of taking a less than perfect one.
The full conversation with Manuel is available on the dualoop YouTube channel. The detail of how the engagement itself ran is covered in our UBench case study.
If any of this sounds like your organisation, let’s chat!
