Lessons

Product Teams Need AI That Understands Ambiguity

Product Teams Need AI That Understands Ambiguity

"The team agreed to move forward." It reads clean and decisive - and it might be completely false. Did they agree on the direction but not the implementation? Agree to explore it but not commit? Was the whole thing hinging on one unresolved technical question? Was the customer pain real while the solution was still contested? A summary that smooths all of that into a single confident sentence hasn't captured the meeting. It has misrepresented it. That's the lesson building Earmark taught us: product teams don't need AI that pretends every meeting was clean. They need AI that understands ambiguity.

Real meetings are messy by nature. People contradict themselves, requirements shift halfway through, someone floats a suggestion that sounds like a decision but isn't, engineering raises a concern no one resolves, design likes the direction but not the details, leadership wants speed while the team knows the scope is still soft. That's not a defect in the conversation - it's what product work actually is. The mistake is forcing that mess into a fake-clean output, because the worst possible artifact is the one that sounds confident about something the team was still debating.

False clarity is dangerous precisely because it feels productive.

The artifact looks tidy, the action items are neat, the summary sounds decisive - and then engineering starts building and discovers the team was never actually aligned. That's worse than messy notes, because at least messy notes show their seams. So AI shouldn't flatten uncertainty; it should represent it. What was decided versus merely suggested. What's still open. What changed mid-discussion. Which tradeoff was accepted, which risk needs review, which assumption the team is quietly making, and what still needs a human decision before work can move. A ticket shouldn't hide an unresolved question. A spec shouldn't promote a tentative direction into a requirement. A decision log shouldn't confuse debate with commitment. An implementation plan shouldn't bury the tradeoff that made the work risky in the first place.

That's why the best outputs don't just capture conclusions - they preserve the shape of the conversation: the agreement and the disagreement, the hesitation, the open question, the decision still waiting on approval, the idea that shouldn't become a ticket yet. The honest version most teams actually want is the one that flags where the conversation was unresolved instead of papering over the hard part with a beautiful recap.

Product work was never a straight line from discussion to decision. It's a sequence of tradeoffs, revisions, objections, and partial commitments, and any AI that means to serve product teams has to understand that. The goal isn't artificial certainty; it's usable clarity. And sometimes the clearest, most useful thing a tool can say is simply: this part is decided, this part is not.

Let your meetings finish the work.

Earmark turns conversations into finished work — so the follow-up is already started when the call ends.