When a product manager can generate a customer-specific CAD feature before lunch, engineering speed stops being the obvious bottleneck. The harder constraint becomes deciding which customer request deserves to enter the product, who can approve that decision, and whether the company can support what it ships.
Consider Kojo, an illustrative composite of hardware founders I have watched make this kind of call. At 11:18 on a Tuesday in Accra, he stood beside a product manager named Efua, staring at a working custom feature on her laptop. A customer had asked for a geometry change that morning. The engineering team had expected to place it behind two urgent manufacturing fixes.
Efua had described the required behavior to an AI-assisted CAD tool, tested the generated feature against the customer’s sample model, and corrected one faulty assumption. Before lunch, the result looked ready for an engineering review.
On Monday, Kojo’s problem had been a six-week CAD queue. On Tuesday, that queue appeared to have vanished.
The relief lasted about nine minutes.
A faster build created a harder commitment
The customer wanted the feature included in a pilot scheduled to begin soon. If Kojo said no, the customer could choose another supplier. If he said yes, the team would introduce customer-specific geometry into a product they were still trying to standardize.
The generated feature also carried an assumption about how the part would be manufactured. It worked on the sample model. Nobody in the room could yet say whether it would behave correctly across the other configurations already in use.
That distinction matters. A model can look complete while hiding a manufacturing decision that nobody consciously made. I wrote about that risk in what happens when finished CAD hides the wrong manufacturing assumption.
Kojo had to choose before the customer’s review call that afternoon. There was no comfortable option. Rejecting the request could cost the pilot. Accepting it could leave a small team maintaining a branch of the product whose commercial value had never been tested.
For years, the queue had protected him from this decision. Engineering capacity provided a credible reason to defer. Once the feature could be produced in a morning, that protection disappeared.
Speed had exposed the real question: who had the right to turn a customer request into a product obligation?
The queue had been doing product strategy badly
Teams often treat a long engineering queue as an execution problem. Sometimes it is also a hidden prioritization system.
Only requests important enough to survive several weeks of waiting reach the top. Weak ideas expire. Salespeople stop asking. Customers find workarounds. Founders gain time to reconsider a promise made during an enthusiastic call.
That system is slow and arbitrary, but it filters demand.
AI-assisted product tools can remove the delay without replacing the filter. A product manager can produce a credible feature quickly, yet the team still needs answers to less visible questions:
Who requested it, and what decision will that customer make if it exists?
Does the feature belong in the core product, a paid custom engagement, or a prototype that expires after the pilot?
Who owns testing when generated geometry touches manufacturing assumptions?
What will the team stop supporting if this request becomes permanent?
These questions feel procedural until runway is short. Then each one becomes a capital allocation decision. A morning spent generating a feature may be cheap. Two years of compatibility, documentation, support, and customer expectation are not.
The right metric moved downstream
Kojo’s first impulse was to measure the breakthrough in hours saved. That number was real, but incomplete.
The more useful measure was the time from request to evidence. Could the generated feature help the customer make a buying decision? Could it reveal whether the requested geometry solved the actual problem? Could the team test demand before treating the output as maintained product?
This changes how I would use faster CAD generation in a small company. I would shorten the distance to a customer decision, while keeping the distance to a permanent product commitment deliberately longer.
Kojo and Efua could show the generated behavior in the afternoon review. They could label it as a pilot implementation, document the manufacturing assumption, and ask the customer to confirm the operational constraint behind the request. Engineering would still review it before release. The customer would still have to demonstrate that the feature affected the purchase.
That approach protects the company from confusing production speed with validated demand. Sipho learned to judge customer meetings by the decisions they produced. The same standard applies here. A fast demo has value when it moves a real decision.
Wednesday’s queue looked different
By Wednesday morning, Kojo no longer had one CAD queue. He had three smaller ones.
One queue held experiments that product managers could generate and test with customers. Another held features awaiting engineering and manufacturing review. The final queue held requests that had earned a place on the maintained roadmap.
Efua’s feature sat in the first queue, with its assumption written beside it. The pilot was still possible. So was rejection.
That unresolved status was useful. The team had gained speed without pretending certainty.
The next time a product tool removes six weeks of work, I would resist celebrating for a moment. I would write down the decision that the delay used to postpone, name the person who now owns it, and define the evidence required before a generated feature becomes part of the product.
By lunch, Kojo’s CAD queue was shorter. His list of product decisions was finally visible.
Comments
No comments yet.