Start With the Use Case

A customer can come into a technical conversation knowing that they need a speaker or a microphone without necessarily knowing what specifications should drive the selection. I see this fairly often in acoustics. They know the product they want to build, but they have not always translated the way the product will be used into clear component requirements yet.

That is usually where I start. Not with the datasheet, and not by immediately sending three parts that look close on paper. I first try to understand the use case well enough that the specifications start making sense.

The specification usually comes after the use case

For acoustic components, the environment matters a lot. Where will the product be used? Is it indoors or outdoors? Is the environment quiet, or will there be a lot of background noise? Who is the end user? How close will the person be to the speaker or microphone? What is the product expected to sound like or hear?

Those questions are simple, but they change the direction of the conversation. A customer may not know the exact SPL target, sensitivity, frequency response or other value they need. That does not mean they do not know their product. It just means we need to help connect the intended experience to something measurable.

One thing I do is ask what would be the closest product or use case they can compare it with. That gives us a reference point. We may already have internal experience or values from similar applications, and that can help the team guide the customer toward a more realistic starting point.

I am trying to understand the product before I recommend the part

For me, this is the difference between component selling and technical selling. If I only look at the specifications that were sent to me, I may find something that matches those numbers. But if the numbers were not defined from the real use case, I can still end up recommending the wrong component.

So I try to understand what the customer is building, where they are in development, how the product will be used and what the end customer should experience. Once I have that, I can involve the right people internally and we can narrow the selection with much more confidence.

This is also why the conversation looks different depending on the type of project. In my current role, where I am focused on acoustic components, I spend a lot of time on the use environment and the application. In my previous role in engineering consulting, the questions were different. I was more focused on the development itself: what is the customer’s timeline, where are they in the project, what capabilities do they already have internally and where could an external engineering team help?

The principle is the same even if the questions change. Before proposing the solution, understand the situation around it.

Sometimes the right answer is that we are not the right answer

I also think technical conversations become more useful when you are comfortable recognizing when something is outside your company’s wheelhouse. I always try to help the customer as much as I can, but that does not mean forcing every conversation into something we sell.

If we can help directly, I keep asking questions and work with the team to move the customer toward the right solution. If we cannot, I will often think about whether I know someone in the community who can help instead.

That might mean a warm introduction by email, LinkedIn or sometimes even text. I would rather help the customer get to the right person than try to keep a conversation that is not really ours.

The timeline is part of the technical conversation too

Another thing I pay attention to is where the customer wants to go and how quickly they want to get there. Sometimes the technical solution may be possible, but the timeline creates another challenge. If I think the schedule sounds difficult, I will ask more questions rather than just say yes.

A component decision does not happen in isolation. There may be samples to evaluate, mechanical integration to update, testing to complete, purchasing lead times to consider and several people involved in the decision. Understanding the customer’s development stage helps set expectations around what can realistically happen next.

What I take from this

I do not think the best technical customer conversations start with proving how much you know about the product you sell. They start with understanding what the customer is trying to achieve.

Sometimes the customer arrives with very detailed requirements. Sometimes they arrive with a product concept and a much less defined idea of the component they need. Both are normal.

My role is to ask enough questions to help translate the application into something the engineering team can work with. And if the answer is outside what we can do, I still want the customer to leave the conversation closer to a solution than when they entered it.

One last thought

A datasheet can tell you whether a component meets a specification. It cannot tell you whether the specification was the right one in the first place.

That is why, for me, the most useful place to start is usually much simpler: How is the product actually going to be used?