The Art of Building Products That Matter

There's a moment in every product's life when a decision is made. Not the big decisions. Those get debated endlessly in meetings and strategy docs. I'm talking about the small ones. The ones nobody will notice.

The animation timing on a button. The error message when something goes wrong. The way a loading state feels.

These decisions reveal everything about the people who built it.

---

The Metric Trap

Most products today are built backwards. Teams start with metrics (conversion rates, DAUs, retention curves) and work backwards to features. The result is predictable: products that are optimized but not loved.

You've felt this. You open an app and everything is technically fine. It loads fast, the UI is clean, it ticks every box on a product requirements doc. But something is off. It feels hollow. Like nobody who built it actually uses it.

That's the metric trap. When the dashboard becomes the product and the user becomes the data point.

I've fallen into it myself. Early in my career, I'd celebrate a feature shipping on time without asking whether it shipped well. It took building multiple products, and watching some of them fail quietly, to understand the difference between something that works and something that matters. The products that stuck, the ones people actually came back to, were never the most feature-rich. They were the ones where someone on the team cared about how it felt.

The best products aren't built by people who are good at optimizing. They're built by people who are good at caring.

The question I keep coming back to is simple: would I use this myself? Not "does this hit our OKRs." Would I actually want to open this app on a Tuesday morning? If the answer is no, something is wrong, and no amount of A/B testing will fix it.

---

The Toolkit Fallacy

Let me be clear. I'm not against metrics. I live in them.

OKRs to align on outcomes. Scrum with two-week sprints to confront reality early. Funnel analysis and cohort analysis to understand where users drop off and whether retention is real. RICE scoring to cut through opinion-based prioritization. A/B testing when intuition isn't enough. Jobs-to-be-Done interviews to discover what users actually hire your product for, which is almost never what you assume. On the engineering side: event-driven architecture, CI/CD pipelines with quality gates, distributed tracing for observability at scale.

I run all of this. Any serious team should.

The playbook works. It gets you to a solid product. Functional, measurable, defensible. But it doesn't get you to a great product. There's a gap between something that performs well on a dashboard and something someone genuinely loves. No framework covers that gap. No OKR captures it. No sprint story accounts for it.

That gap is where everything I'm about to say comes in.

---

The Game Developer's Education

My journey into tech started at twelve years old with a Google search: "How to make games." That search changed everything.

I didn't know it at the time, but game development was the best possible education for building products. Not because of the code. Because games are ruthlessly honest. A game that's technically impressive but not fun is a failure. Nobody cares about your shader pipeline if the gameplay is boring. A game with simple graphics but incredible feel? That's a masterpiece.

This taught me something that carries into everything I build: technology should have personality. It should be useful, yes. But also delightful.

When we built Area of Darkness: No Escape (Pakistan's first AAA VR game) every design choice was driven by a single question: "How does this make the player feel?" Not "what does this optimize for?" but "what does this feel like?"

That question changed how I think about everything. Games taught me progressive disclosure: don't overwhelm people, reveal complexity gradually. They taught me that every action should feel like it did something. That small moments of delight compound into loyalty. That a user should never have to wonder "what do I do next?"

I carry those lessons everywhere now. At Trukkr, where we're building logistics infrastructure, the natural instinct is to make things functional and move on. Freight management doesn't exactly scream "delight." But that's exactly the opportunity. A logistics platform doesn't have to feel cold and transactional. It can feel smart, responsive, alive. And when your users are truck drivers and fleet managers working long hours on the road, that feeling matters more than you'd think.

---

The Mohsin Discipline

There's a concept that guides everything I build. Mohsin, from the Arabic root Ihsan (إحسان), meaning to do something with excellence and beauty.

I didn't always have a word for it. For years, it was just a feeling. An inability to ship something I knew could be better. A compulsion to rewrite a function that worked but didn't read well. An obsession with details nobody asked for but everybody would feel.

Then I found the word, and it clarified everything.

Mohsin isn't about perfection. Perfection is a trap; it paralyzes you. Mohsin is about caring enough to make it right. Every detail considered. Every decision intentional. You do it because the work deserves that much.

You do it for the beauty of doing it.

In practical terms, it means never shipping something you're not proud of, even if the deadline allows it. It means sweating the details that users feel but can't articulate. Building with intention, where every feature, every interaction, every word has a reason. Respecting the craft (code quality, design consistency, architectural integrity) not because someone will audit it, but because you know.

What Mohsin looks like in code

The difference between doing-it-right and just-doing-it:

# This works
def get_users(db):
    return db.query("SELECT * FROM users")

And this:

# This works AND communicates intent
def get_active_users(
    db: Database,
    since: datetime | None = None,
    limit: int = 100,
) -> list[User]:
    """
    Retrieve active users, optionally filtered by last activity date.
    
    Returns users sorted by most recently active first.
    Excludes soft-deleted and suspended accounts.
    """
    query = (
        db.query(User)
        .filter(User.is_active == True)
        .filter(User.deleted_at.is_(None))
        .order_by(User.last_active_at.desc())
        .limit(limit)
    )
    if since:
        query = query.filter(User.last_active_at >= since)
    
    return query.all()

Both "work." Only one shows Mohsin.

The first solves the immediate problem. The second communicates. To the next developer. To your future self. To whoever will maintain this at 2 AM when something breaks. It says: someone was here, and they cared.

---

The Long Game

Every product I've worked on, from VR games to fintech to logistics infrastructure, shares a common thread. They weren't built to flip. They were built to last.

That's what Mohsin does to you. Once you internalize excellence as a discipline, you can't turn it off. You start seeing the gap between "good enough" and "genuinely good" everywhere. In code. In design. In how a team communicates. In how an error message treats a confused user.

Some people think this slows you down. In my experience, it's the opposite. When you care about the craft, you make fewer decisions you have to reverse later. You build trust with your team and your users faster. You spend less time firefighting and more time creating.

The market rewards speed. But history remembers craft.

---

"Let the beauty we love be what we do." - Rumi

- Kasra Zunnaiyyer, October 2022