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.

What the Playbook Gets Right

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

Every product I build runs on a foundation of structured methodology and data. OKRs to align the team around outcomes, not output. Scrum with two-week sprints — not because it's fashionable, but because shipping in small increments forces you to confront reality early instead of discovering it at the end of a quarter. Sprint retrospectives are religious practice. They're the fastest feedback loop a team has, and the teams that skip them are the ones that repeat the same mistakes for months.

On the growth side, I go deep. Funnel analysis — AARRR pirate metrics — to understand exactly where users drop off and why. Cohort analysis to separate genuine retention trends from noise. We track churn rate, LTV:CAC ratios, activation rates, and we build dashboards the whole team can read, not just the product manager. I've spent enough hours in Mixpanel and Amplitude to know that you're flying blind without proper event instrumentation, and I pair quantitative data with session recordings to see the story behind the numbers — because a 12% drop-off at step three means nothing until you watch someone actually get stuck there.

For prioritization, RICE scoring (Reach, Impact, Confidence, Effort) cuts through opinion-based arguments. Feature flags for controlled rollouts. A/B testing when intuition isn't enough and the stakes are high enough to justify the sample size. Jobs-to-be-Done interviews to understand what users are actually hiring your product for — which is almost never what you think it is the first time you ask.

Architecture-wise, I think in event-driven systems, domain-driven design, and CQRS where the complexity warrants it. CI/CD pipelines that enforce quality gates — linting, type coverage, automated tests — before anything touches production. Infrastructure as code. Observability with distributed tracing, not just logs, because when something breaks at scale you need to trace the request across services, not grep through a monolith.

I say all of this not to list credentials, but to make a point: the playbook works. It gets you to a solid product — functional, measurable, defensible. Any serious team should be running most of this.

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.

What Game Development Taught Me

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.

Mohsin: Excellence as a 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

It's the difference between:

# 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.

Building for 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