There is a particular kind of clarity that comes from being responsible for both a product and the conversation about buying it. You cannot leave every unanswered question with another team. If someone does not understand the value, you have to examine the explanation and the product. If a feature is difficult to use, you have to decide whether the answer is better onboarding, a smaller scope, or a different design.
At Craze, I was the founder and CEO, and I built the full-stack AI interview platform end to end. The company focused on Gen Z consumer insights. We raised $80,000, grew to four full-time employees, and built a panel of more than 10,000 verified college students across 198 campuses. Those are useful markers of the company's development. The underlying work was connecting an audience, a product, and a reason for brands to pay.
A product is part of a larger system
It is possible to build a technically impressive tool and still leave the important problem unsolved. A research product, for example, needs more than a way to ask questions. It needs relevant participants, a clear experience for those participants, and an output that someone can use to make a decision. Each part changes the value of the others. A beautiful interface cannot compensate for weak inputs.
That is why I am interested in the whole path from a customer's question to a usable result. Where does the information come from? What happens between steps? Who has to take action next? Looking at the complete path makes it easier to see why a seemingly small operational issue can matter more than an ambitious new feature. The product is experienced as a sequence, even when a team builds it as separate components.
Make the promise specific enough to test
“Better insights” is an appealing phrase, but it is too broad to guide a useful product decision. Better for whom? Better at answering which question? Better within what time frame? A precise promise gives a team something to evaluate. It also helps a prospective customer understand what they are being asked to try. Ambiguity can make an early idea sound larger while making it harder to improve.
Craze secured four paying brand pilots in its first two months, including an engagement with Celsius. I see a paid pilot as a beginning rather than a final verdict. It shows that someone is willing to commit resources to testing an idea. The next responsibility is to learn what would make the product valuable in repeated use. Interest, payment, successful delivery, and lasting usefulness are related, but they are different signals.
Stay close without reacting to everything
Customer proximity does not mean turning every request into a feature. Different people can describe the same underlying problem in very different ways. A request might be a proposed solution, a symptom of a confusing workflow, or something specific to one organization. The job is to understand the need well enough to decide what deserves a durable place in the product.
A practical way to do that is to separate observations from interpretations. “The customer exported the results before sharing them” is an observation. “We need a new reporting dashboard” is an interpretation. There might be several explanations for the behavior. Keeping the two separate makes room for a simpler answer and makes it easier for another person on the team to challenge the conclusion.
Use speed to shorten the distance to evidence
I like building quickly because a working version can make a conversation more concrete. Someone can react to an actual flow, an actual output, or an actual limitation. But the value of speed depends on what it helps you learn. Shipping a larger number of features does not automatically create a better understanding of the customer. It can also create more things to maintain before their value is clear.
The version worth building is the one that makes the important assumption visible. If the uncertainty is whether the output is useful, a polished settings page will not resolve it. If the uncertainty is whether someone can complete a workflow, an attractive screenshot is insufficient. Matching the artifact to the question is a form of discipline. It keeps effort attached to the decision that needs to be made.
The kind of builder I want to be
Craze was acqui-hired in 2026. My work now focuses on building Morsa's North American go-to-market function, but the connection between product and customer remains central. I want to understand enough of the technology to see what is possible and enough of the customer's work to see what is worth doing. Neither perspective feels complete on its own.
The most useful thing I can bring to a small team is a willingness to move between those perspectives. Listen carefully. Make something tangible. Explain it plainly. Pay attention to what happens next. Then use that evidence to make the next version more useful. That is a working practice I want my portfolio to communicate, beyond any single title or company.
Have a different perspective? I’d like to hear it.
Continue the conversation