Start with the customer, not the technology

Over the last few months, I have been thinking a lot about how customer experience is no longer just a nice extra around the product. More and more, it feels like the main differentiator between success and failure of the product, as it decides whether the users come back. Part of that shift is obvious. Software is easier to build than it used to be. Small teams can ship things that once required much bigger companies and AI is accelerating that even more. But when everyone can build faster, the swamp of products is inevitable, which we're already experiencing. What starts to matter more is how the product feels to use. How quickly someone reaches value. How clear the product feels when they first open it. Or how many tiny moments of friction, uncertainty, or confusion they run into before they decide whether this is something they want to keep using. That side of product has become much more interesting to me. It is also a big part of why I care so much about what we are building with Custory. ## The companies I admire are winning on experience I do not think the next generation of great products will win just because they can do more. Some will. But the ones people really stick with have the whole experience feeling sharper, calmer, and easier to trust. Look at [Cursor](https://cursor.com/blog/series-c). Yes, AI is part of the story. But the reason people talk about it is not only "AI exists inside the editor." It is because the workflow feels faster and more natural for the job developers already care about. Or at [Linear](https://linear.app/now/building-our-way). It is not a beloved product because issue tracking is inherently exciting, it's quite the opposite. It is loved because the product feels intentional. It respects speed, clarity, craft, and the emotions of people doing serious work. That, to me, is the standard more products will be judged against. Not just: can you build this? But: can you make it feel good enough that people want to keep coming back? ## Start with the customer, not the technology There is a [Steve Jobs quote from WWDC 1997](https://www.youtube.com/watch?v=EZll3dJ2AjY&time_continue=2) that I keep coming back to: you have to “start with the customer experience and work backwards to the technology.” In the same talk, he also said Apple’s strategy had to begin with what real benefits they could give the customer and where they could take them, not with a room full of engineers figuring out what technology they had and how to market it afterwards. I think that idea matters even more now than it did back then. A lot of teams, especially in AI, still start with the technology first and only later try to find the use case. But the better path is the opposite: start with the customer, the friction, the outcome, and the experience you want to create, then use technology to make that possible. Customers rarely care about the underlying stack as much as product teams do. They care whether something is useful, clear, and worth coming back to. ## Customer experience breaks when context breaks Most teams do care about customers. I do not think empathy is usually the problem. The real problem is that customer understanding gets scattered across too many places. A bit of it lives in calls. Another piece is in support tickets. Some of it sits in Slack, analytics, sales notes, PRs, docs, or research. And then somehow the team is expected to turn all of that into clear product decisions. That is where things start to fall apart. One person remembers a customer complaint. Another sees a drop in conversion. Support is hearing one thing, product is seeing another, and the founder has a different picture again. Everyone has part of the story, but not the whole thing. So teams do not really ship from a shared understanding of the customer experience. They ship from fragments they remember. At that point, the issue is not that people do not care. It is that the system makes it too hard to keep customer context usable over time. ## The real job is making customer understanding usable This is the part I think matters most. It is not enough for a team to collect feedback, run interviews, or look at dashboards. The hard part is turning all of that into something the team can actually work from. Something clear enough to guide decisions, but lightweight enough that it does not become another dead document. That is also how I think about Custory at its healthiest. Not as a pile of features, and not as some AI wrapper around customer research, but as a way to help teams stay closer to what customers are actually experiencing and act on it with less friction. The value is not in mapping things for the sake of mapping them. It is in helping teams spot what is hurting the experience, understand why it matters, and respond faster with more confidence. That matters whether the issue is onboarding friction, a recurring support pattern, or something quietly hurting retention. The goal is simple: make customer understanding easier to keep alive and easier to use. ## AI should reduce the busywork, not replace the thinking AI is still a big part of how I think about this space. I just do not think it should be the whole story. To me, AI is most useful when it takes away the manual work around understanding the customer. Things like pulling signals together, helping make sense of messy input, spotting patterns earlier, and moving context between tools without the team having to do every step by hand. That is useful. But the important decisions still stay with the team. They know the customer best and they should decide what actually matters, what is worth fixing, and where the product experience should improve. AI should support that process, not pretend to replace it. ## Why I care about building this The reason I care about Custory is tied to a broader belief that I mentioned at the beginning: customer experience is going to matter more and more as building products becomes easier. As software gets easier and faster to build, the real difference between products will less often be the feature itself and more often how well the team understands the customer behind it. Who notices friction sooner, understands what is breaking trust, and improves the experience in ways people can actually feel. That is the kind of product work I want to be closer to. And that is also the broader idea behind Custory: customer journeys should not live as static workshop outputs that get forgotten a week later. They should be something a team can continuously learn from and build from. If we do it right, the outcome is not just better documentation. It is better product decisions, better prioritization, and a team that feels less scattered and more in control of the experience it is creating. That is the kind of software I want to build. And honestly, it is the kind of software I want more teams to build for their own customers too. If you are thinking about this too, or trying to make your product more customer-led, try our product at [Custory](https://app.usecustory.com/sign-in). If you're interested in what we're building, feel free to reach out at filip@usecustory.com, I always enjoy talking about this stuff.