My notes from meeting Kartik of CompileCrew, our client for over a year

Living and breathing the product is what separates a good designer from a great one.

From a conversation with Kartik, co-founder and CEO of CompileCrew

That’s the gist of what Kartik told me in person. We were introduced by another client two years ago, and CompileCrew has been our client for more than a year. Meeting like this is something we’re doing more of: this year we’ve been travelling to Indian cities like Mumbai and Bengaluru to meet clients and the people we’d like to work with. Next year, we’ll be doing the same in the US.

His feedback made me think about what knowing a product actually changes in a designer’s work.

Look past the convincing screen

A skilled designer can make a requested screen look convincing. That’s the risk. The better the screen looks, the easier it is to stop asking whether it belongs in the product at all.

Suppose a founder asks for a reports page with charts and filters, so sales managers can track their team. A good designer makes the charts clean and easy to read. But suppose most managers only open reports to copy three numbers into a WhatsApp or Slack message for their boss. What they need is those three numbers, ready to share. A beautiful reports page would sit between them and that message. You only see that if you know how the product is actually used.

Good designers answer the question well. Great ones know the product well enough to notice when the question is wrong.

Challenge the brief with evidence

Splitting a designer across several clients makes this harder. Each switch means rebuilding context. The brief becomes a shortcut: it tells you what someone asked for and what they’re likely to approve. A designer can get very good at satisfying briefs without ever learning enough to challenge one.

Most of our projects get a dedicated designer, and nobody here juggles five projects at once. That was true before Kartik said anything. But continuity alone isn’t enough. You can spend a year on a product and still treat each request as a separate assignment.

Following the brief is easy to judge: did we make what was asked for? Challenging it means asking a founder to reconsider a decision they think is settled. It looks like slowing down.

It can also go wrong. A designer can mistake their own preference for product knowledge. The difference is evidence. “Managers only open reports to copy three numbers” is product knowledge. “I don’t like charts” is preference.

Let product knowledge, not speed, decide

AI makes that risk bigger. At Rango, agents help us draft and edit faster, and a person approves everything before it goes live. That speed is useful. But if we can turn a request into a convincing interface sooner, we can also commit to the wrong request sooner.

CompileCrew has done more than most clients to move us forward, and Kartik’s feedback helped us find new AI workflows. Working with them pushed us to get frontend output while the design was still taking shape. Today our toolkit includes Claude Code, Codex, Paper and Figma MCP. But a faster handoff doesn’t tell you whether a screen should exist. For that, you have to know the product.

Our takeaway: live and breathe the product

We don’t always get this right. Living and breathing a client’s product, and thinking from its users’ point of view, is hard to crack, especially when you aren’t the one using it every day. But it’s the standard we’re aiming for, and a fair one to hold any design team to, including ours.

One check helps: before we design a requested screen, can we explain when it would be unnecessary? Answering that means knowing what the user is trying to finish and how the rest of the product already helps them. That knowledge rarely comes from the brief. It comes from watching how people actually use the product: support tickets, recordings, a call with a real user.

We talked about more than design, too: where service businesses are heading, and health and fitness, which I found really inspiring.

Thanks to Faiz, our dedicated designer for CompileCrew, and to Kartik for pushing us.