I have spent much of my career working with technology that can do impressive things. When you work with enterprise software, security solutions, infrastructure, and newer artificial intelligence applications, it is easy to get caught up in what a product is capable of doing. I understand the excitement. I still get excited when I see someone build something genuinely clever.
Over time, though, I have become much more interested in the problem than the product.
That probably comes from spending years in go-to-market roles and seeing what happens when a product leaves the environment where it was created and meets an actual customer. Inside a company, everyone may understand why a solution is exciting. Outside that company, nobody is obligated to care.
The customer has a different question: What problem does this solve for me?
If we cannot answer that clearly, I have learned that everything gets harder from there.
An Impressive Product Is Not Automatically a Useful Product
There is sometimes an assumption in technology that a better product should naturally be easier to sell. I wish it worked that way.
I have seen products with impressive capabilities struggle to gain traction because the connection between those capabilities and the customer’s actual needs was unclear. I have also watched comparatively simple solutions succeed because they addressed a problem customers already understood and wanted to fix.
That experience changed the questions I ask.
Instead of immediately asking what a product can do, I want to know who is dealing with the problem. How often does it happen? What does it cost them? What are they doing about it today? Is the problem irritating, or is it important enough that somebody will spend money and organizational energy fixing it?
That last question matters more than people sometimes realize.
A business can acknowledge that a problem exists without considering it a priority. Those are two very different things.
Customers Already Have a Way of Doing Things
One of the lessons that took me some time to fully appreciate is that a new product is rarely competing against nothing.
The customer probably has an existing process. It may be inefficient. It may involve spreadsheets, manual work, older software, or several people doing things that could theoretically be automated. From the outside, replacing that process can seem obvious.
From inside the customer’s organization, it may not be obvious at all.
The existing process is familiar. People know how it works. Budgets have already been allocated around it. Employees have responsibilities tied to it. Other systems may depend on it.
Introducing something new creates its own costs and risks.
That means the question is not simply, “Is our solution better?”
The harder question is, “Is it sufficiently better that someone is willing to change what they are already doing?”
I think about that distinction frequently in go-to-market work.
The Problem Usually Looks Different From the Customer’s Side
There is another complication. Companies sometimes describe a customer’s problem in language that makes sense internally but does not resemble the way the customer actually talks about it.
I have been guilty of this too.
When you spend enough time around a particular technology, you develop a vocabulary around it. Certain concepts become obvious. You start assuming other people think about the issue using the same categories.
Then you get into a customer conversation and realize they don’t.
Maybe they aren’t thinking about artificial intelligence at all. They are thinking about why a process takes three days instead of three hours. Maybe they aren’t looking for a new security platform. They are worried about visibility, risk, staffing, or explaining something to leadership.
Those differences matter.
If I am talking about my product while the person across the table is thinking about an entirely different problem, are we really having the same conversation?
That is one reason I have learned to listen longer before deciding what the solution should be.
There Is a Tradeoff Between Listening and Leading
I don’t think “listen to the customer” means customers should design the product for you.
That can create a different problem.
Customers understand their own experiences extremely well, but they do not necessarily know what technology will be possible next year or what approach could solve a problem in a completely different way. If companies only build exactly what customers request, they can miss opportunities to create something better.
So there is a balance.
You have to listen closely enough to understand the underlying problem without assuming the customer’s proposed solution is the only answer.
That can be uncomfortable because there isn’t always an obvious line between listening and leading. When should you challenge what a customer believes? When should you accept that they understand their environment better than you do?
I don’t think there is a formula for it. Experience helps, but even then you can get it wrong.
What I try to avoid is starting with the assumption that the product must be the answer.
AI Has Made This Lesson Even More Relevant
Artificial intelligence has made the problem-first approach especially important to me.
There is enormous interest in AI, and understandably so. The capabilities have developed quickly, and businesses are trying to understand where they fit.
But “we should use AI” is not really a business problem.
I would rather start by asking what we are trying to improve. Is there repetitive work consuming people’s time? Is there information that employees struggle to find? Is there a decision that could be made with better context? Are customers experiencing unnecessary friction?
Once the problem is clear, AI may be an excellent solution. It also might not be.
I think being willing to reach that second conclusion is important. Not every process needs AI simply because AI can be applied to it.
Good Go-to-Market Work Starts With Curiosity
After years of working with technology companies, I have become less interested in having the fastest answer in the room.
I would rather ask another question.
There is usually something underneath the first problem a customer describes. Understanding it requires curiosity about how the organization actually works, who is affected, what has already been tried, and why the problem remains unresolved.
Sometimes that process confirms exactly what you expected. Sometimes it changes the entire conversation.
That is one of the things I continue to enjoy about go-to-market work. You can know a product extremely well and still learn something new every time you see it through a customer’s eyes.
Products will continue to change. The technology certainly will.
The habit I want to keep is much simpler: understand the problem first. Everything that comes after that tends to make more sense.
