Prachi Tambe
building experiences beyond AI.

Here's a strange thing about working on Face ID: when it works perfectly, the user experiences nothing. No interaction. No moment of delight. Their phone is simply unlocked, the way a door is simply open. The product's success is the absence of a product experience.

This broke every PM instinct I'd been taught. We're trained to make value visible — to show progress bars, celebrate completions, surface the magic. But for a whole class of products, visibility is failure. Every time Face ID asked you to try again, that was the product becoming visible. Our job was to make it disappear.

The highest compliment a user can pay your product is to never think about it. That's also the hardest thing to get a roadmap approved for.

Three things I learned shipping invisible products:

1. You have to invent your own scoreboard. Nobody opens an analytics dashboard and gets excited about "unlock attempts that the user did not consciously register." We had to build metrics for non-events — false reject rates across lighting conditions, latency distributions at the 99th percentile, performance across the full diversity of human faces. If you can't measure the absence of friction, you'll never get resources to reduce it.

2. The edge cases are the product. The happy path was solved early. The years of work were sunglasses, masks, twins, kids growing up, faces changing with age and weather and angle. When your product runs a billion times a day, a 0.1% failure rate is a million bad moments a day. Invisible products are built almost entirely in the long tail.

3. Sell the silence internally. The hardest stakeholder conversation isn't about what to build — it's convincing leadership that "nothing happened, faster and more reliably" is worth another quarter of investment. I learned to translate invisibility into business language: support tickets that never got filed, passcode fallbacks that never happened, trust that compounds silently into retention.

I think about this constantly now that I work on agentic AI. The current generation of AI products is loud — chat windows, typing indicators, capability demos. But the endgame is the same as Face ID's: the agent that triages a thousand store photos overnight and never needs to announce itself. The work just gets done.

Invisible is the destination. The demo is just how you raise the money to get there.

— Prachi

I now work on AI systems that look at photographs of retail shelves — taken by field reps walking through stores — and decide whether a display is compliant, whether a promotion is actually set up, whether the thing the brand paid for is the thing that's happening.

When I describe this work, people ask about the models. Object detection accuracy, fine-tuning, hallucination rates. Reasonable questions. Also, almost never where the project lives or dies.

Everyone wants to talk about model capability. Almost nobody wants to talk about the workflow you're asking a human to change.

Here's what actually determines whether an AI product survives contact with reality:

Trust is built per-decision, not per-demo. A field manager doesn't care that your model is 94% accurate in aggregate. She cares about the one store she knows personally, where the model flagged a compliant display as a violation, in front of her team. One visible wrong answer in a domain the user knows cold can erase a hundred invisible right ones. So you design for graceful wrongness: confidence thresholds that route uncertain cases to humans, explanations that show the evidence, and an easy way to overrule the machine that feeds back into the system.

The eval is the spec. In traditional software, the PRD describes behavior. In AI products, your evaluation set is the product definition — it encodes every judgment call about what "correct" means. If your eval set doesn't include dim stockrooms, partially blocked shelves, and that one retailer's weird fixture, you haven't specced the product. You've specced the demo.

You're not adding AI to a workflow. You're replacing a workflow with a different one. Before our system, a human looked at every photo. After it, a human looks at the 12% the model is unsure about. That sounds like a pure win, but it changes someone's job, someone's headcount plan, and someone's sense of what they're for. If you don't manage that transition like the organizational change it is, the most accurate model in the world will quietly stop being used.

The boring integration is the moat. Anyone can call a vision API. The defensible work is the unglamorous part: routing the output into the system the partner already uses, matching their SKU taxonomy, correlating compliance with sell-through data so the insight is "this display drives revenue," not "this display exists."

My rule of thumb after a year in this domain: budget one unit of effort for the model and three for everything around it. If your plan is the reverse, you're building a demo with a deployment problem.

— Prachi

For years at Apple, my job was to ship ML features that depended on the Camera API team, the Neural Engine team, and several others — and I managed exactly none of them. Every PM book calls this "influence without authority" and then gets vague, as if it's a personality trait. It isn't. It's preparation.

The secret wasn't charisma. It was knowing their constraints better than they expected me to.

What that looked like in practice:

Learn the other team's scarcity. The Neural Engine team didn't think in features; they thought in compute budgets, memory footprints, and thermal envelopes. The Camera team thought in frame timing. When I walked into a room asking for something, I'd already done the math on what it cost in their currency. Half the time, that homework changed my ask before the meeting even happened — and the asks that survived were ones I could defend in their terms, not mine.

Bring the tradeoff, not the request. "We need animal detection to run continuously" is a demand. "Here are three ways to get pet detection: continuous at X power cost, triggered at Y latency cost, or hybrid — and here's why I'd pick the hybrid" is a collaboration. Teams say no to requests. They engage with tradeoffs, because tradeoffs respect their expertise.

Be the person who absorbs the coordination tax. Cross-team features die in the gaps — the API change one team needs that's priority twelve for another. I made myself the connective tissue: the single person who knew the full dependency graph, wrote it down, and kept it current. It's grunt work. It's also why people returned my messages: working with me was lower-friction than working around me.

Spend credibility like it's irreplaceable, because it is. The first time you escalate something that didn't need escalating, or promise a partner team something your own roadmap can't deliver, you've taken out a loan against every future conversation. I tried to be boringly reliable for a long time before I asked for anything hard. When the hard ask came, the answer was usually yes — not because of the meeting, but because of the two years before it.

None of this is glamorous. That's rather the point. Influence without authority is what it looks like when respect compounds — and respect compounds from homework, delivered consistently, in someone else's language.

— Prachi