It’s Wednesday, and you’ve opened the same CAD file for the fifth time this week. A hole count goes up. A staircase needs seventeen steps instead of nineteen. A radius moves from forty-two millimetres to forty. None of it is new design. It’s confirmation that the new combination can actually be built, and then the drawing that says so.
You recognize the request before you’ve even opened the file. The type is familiar. There’s no confusion about what to do, but there’s real pressure, a salesperson or a customer is waiting on the other end. What’s left once the confusion is gone isn’t calm. It’s tedium. Monotonous, fiddly, small changes made by hand, one file at a time.
The confirmation problem.
That confirmation is the whole problem. The rules for what’s buildable are rarely written down. They exist as judgement, held by you. You know which combinations work in this particular workshop, with the tooling that’s actually in the machine and the tolerance chains that tend to give way at assembly. There’s documentation, somewhere across spreadsheets, CAD folders and email threads, but it assumes the reader already knows which version applies.
01. Potential solutions and their pros and cons.
That judgement could be transferred. A colleague could be trained, the rules could in principle be written down. In most companies, neither has happened. While the knowledge exists only in your head, it has to be applied again for every request, however trivial the change.
Training a second person raises the ceiling but keeps the structure. Two people can answer requests instead of one, and the ceiling moves accordingly. Every request still has to pass through someone who holds the rules in their head. Getting a colleague there is measured in months, not weeks. Your own speed follows the same pattern, experience cuts the minutes per request, but it doesn’t cut the number of requests that need your judgement call.
Copy old quotations
The easiest way to start addressing the bottleneck – quicker replies for requests than starting from scratch. It still requires the expertise and judgment of the engineer, and the workflow remains.
Hire or train a second engineer
Raises the ceiling — two people can now answer requests instead of one — but keeps the exact same structure. Every request still has to pass through someone who’s internalized the buildability rules, and getting a person to that point is measured in months, not weeks.
Make guides and checklists
A genuinely good instinct, worth doing regardless. Making guides and checklists can enable other people to do more of the work. The downside is human error still occurs when sales looks up information in a product sheet, and soon you will have a bunch of versions of the same guide spread among colleagues and customers.
Create spreadsheets and calculation tools
An evolution of guides and checklists, packaged into the tool that all companies have access too – Excel. Spreadsheets and forms can hold a lot of product logic, formulas and information so sales and customers can do more of the work. Restrictions, locked fields and colored areas are often used to steer the person using the form from making mistakes. Spreadsheets are widely used and can help more than product sheets or guides, but they are still prone to human error and versioning them is impossible with copies floating around.
Capture the rules in a system that applies them automatically
Instead of a person re-deriving “is this buildable?” from memory every time, the rules — valid dimensions, compatible options, tolerance limits — live in a system that checks any new combination against them instantly. Whoever’s asking gets the answer directly, without waiting on you.
02. Why growth makes it worse, not better.
It’s also why growth makes this worse instead of better. Every new salesperson generates more requests without adding capacity to answer them. Every new market does the same. The bottleneck isn’t the number of hours in engineering. It’s that one route exists from customer request to production file, and it runs through you.
That’s also why growth makes it worse instead of better: every new salesperson and every new market adds more traffic to the one route, without adding a second one.
Over time, noticing the tedium stops feeling like a complaint and starts feeling like a condition of the role. It’s what comes with being the person who knows the product best.
03. The cost that never shows up in a report.
The cost is real but doesn’t show up in any report. Time for product development, the part of the job that actually builds your expertise, shrinks. Frequent interruption makes sustained work hard regardless of the hours you technically have. Colleagues and sales aren’t a separate social friction, they’re part of the same mechanism. They wait because the knowledge isn’t stored anywhere else, not because you’re slow. That distinction is invisible to the person waiting, which is why the follow-up lands on you and not on the process.
We build this with DynaMaker, a platform for building the kind of visual, web-based configurator that does this — you define your product’s parametric rules once, and every valid configuration that comes through is one the system has already confirmed can be built, without you personally checking it.
You can also poke at a live example configurator here on our website.
04. Where the knowledge should live.
As long as this looks like a workload problem, no fix holds. It comes back next quarter, in the same shape, on the same desk.
Where the knowledge lives today isn’t the interesting part. Where it should, is.
Try It on Your Own Product Line
You don’t need to buy anything to see if this holds up — build a configurator for free and see whether it actually validates a real request the way you would.
