Translating from Operator to Engineer
The first time I ran a Customer Advocacy Group, I walked out of the room with 13 pages of notes, half a dozen screenshots of whiteboards, and a vague sense of either inspiration or dread. Hard to say which.
Some of the feedback was gold.
Some was noise.
Some was a guy named Kenny who spent fifteen minutes explaining why we should “get rid of all the safety crap and save some cost!”
The real work started after the customers traveled home.
That’s when I had to figure out what any of it meant. More importantly, what was our team supposed to do with it?
If you’ve ever been there, standing between a pile of customer feedback and a team waiting for the next spec, this post is for you.
Start With the Patterns
Let’s say your team just wrapped a CAG session for the DirtBeast 4300. You had six solid users in the room. Operators, fleet managers, even someone who swears by a competitor’s machine. Great start.
Now your notes are full of quotes like:
“I have learned to do an extra squirt of grease on the lifter arm every shift at lunch. Just trying to make that bearing last a little longer, ya know.”
“We’re losing time every day on pre-op.”
“It works, but you’ve got to know how to treat it or it’ll bite you.”
You could chase each of those comments individually. Or you could ask, What are they really telling me?
In this case, the theme seems to be: the customers need a machine that lets the operator focus on operating.
Nobody said “reduce operators’ maintenance burden.” That’s PM-speak. But that’s the actual need hiding underneath the frustration. The job here is to find the underlying need, not just the symptoms of missing it.
Translate, Not Transcribe
One big mistake that is easy for brands to make is to treat every customer feedback like it is the new sacred text. Write down exactly what was said. You repeat it verbatim. You drop it into the spec doc with quotes around it and call it insight. React to it like a message from on-high… until a different customer has different feedback.
But just like in the example above, building a spec isn’t about repeating what was said. And it definitely doesn’t put equal weight on every customer interaction. Good spec building is about interpreting the stories you have heard from customers in a way that lets your team take action to solve needs.
If someone says: “When I’ve got a full load and I’m on an incline, the back end floats and I get nervous.”
You don’t spec that as: “Add counter-weight to change machine balance.”
You translate it.
You write:
“Maintain ground contact under full load (8 tons rock in front bucket). Machine must be able to perform without loss of performance up to a 12-degree incline (front or rear), and 10-degree cross slope (either side).”
That is a spec that the Customer Advocacy Group can understand and agree to while also being something engineering can design. Something QA can test. Something a dealer can train on.
Your job is to build the bridge to turn what they said into a need we can solve for them.
When Feedback Conflicts
This part is always fun.
One user says, “It needs more steel in the chassis. Make it tougher.”
Another says, “It’s already too heavy to trailer without a CDL. Cut the weight.”
They might both be right. They might also both be wrong.
Welcome to product management.
In these cases, the best move is to go back to the use case by asking for more stories from those users. Who’s hauling it? What does making it ‘tougher’ solve? Is there a split in how it’s being used — small utility contractors vs. big DOT fleets?
There may be a way to satiate both customers with a modular spec or option. There might also be a way to make the chassis tougher and also lighter.
Sometimes you will just have to make the call. “For this program we are building for X, not Y,” and being clear about that early. These are the important discoveries that will eventually lead you to a good spec and a winning product.
You won’t make everyone happy. That shouldn’t be the goal. The goal should be to make the target market segment happy (and do it at a profit).
Beware of the Customer-Suggested Solution
One of my all-time favorite pieces of feedback came from an operator who said, straight-faced, “You need to get rid of all the safety crap and save some cost. Then you could still give me the higher output!”
It got a good laugh (and still gets quoted from time to time). But at first none of us could believe what Kenny was saying.
So, we asked more questions to figure out where Kenny was coming from. As the conversation progressed we realized that Kenny didn’t mind the safety features while he was operating. Really, we discovered that Kenny and a few others probably put too much faith into our sensor system when it was running correctly. That led to bad habits that caused problems when they had to do maintenance. Kenny said he would rather have no system at all instead of a system that he couldn’t rely on 100% of the time.
The problem wasn’t a failure with our system. The problem was a need to circumvent the system. Our spec quickly got the addition of needing all interlocks to be operable even in maintenance mode.
Customers will often present you with a solution when what you need is their problem. Your job is to listen past the suggestions and make sure you find the real root-cause of their needs. That’s what goes in the spec.
Not Every Need will Make the Cut
This one’s hard, especially when a comment comes from a big customer or someone influential inside your company.
But here’s the truth: not every piece of feedback should make it into the new model.
Sometimes a request is a corner-case that just isn’t going to apply to enough customers to justify the costs. Sometimes the existing product will do exactly as needed, if the operator gets trained better. Sometimes the customer is putting the machine in the wrong application and expecting a miracle.
You always want to acknowledge feedback and look for the best way to translate it to give a message to the right person in your company. But many times that translation is not going into the product spec. Instead, your translation might be to the sales team to encourage the customer to purchase a different model within the product line. Or it might be to talk to the dealer about doing more training.
Never ignore the customer’s feedback. But also never accept an update without thinking through how it will affect the rest of the program. It’s about saying yes to the right things, and backing those decisions with clarity.
What the Spec Should Look Like at the End
So you listened closely, grouped your insights, translated them into real needs, and written clear, testable outcomes. Then your spec should become a set of open challenges for the engineering team to solve. If you walk away that looks more like a Weights and Dimensions sheet, you’re doing it wrong.
It should never say:
“Make chassis tougher”
“Add counterweight”
“Use elimination of safety interlocks as cost savings”
It should say:
“Chassis not to yield when machine corer hits tree at 3mph or slower”
“Maintain ground contact under full load (8 tons rock in front bucket). Machine must be able to perform without loss of performance up to a 12-degree incline (front or rear), and 10-degree cross slope (either side).”
“All locomotive interlocks to be operable even in maintenance mode.”
Sometimes it is tedious. Every time it takes longer than forwarding the competitors brochure.
But it’s worth it because this is how you go from feedback to functionality — without guessing, overbuilding, or building the wrong thing fast.
Need help turning your feedback pile into something the shop floor can use?
At iron echos, we help teams translate field input into clear, buildable specs.
Reach out to iron echos if you’re ready to stop guessing and start building what actually matters.