What we learned: the best AI data product is the one that says "no"
What we learned: the best AI data product is the one that says "no"
Our mission has a line that keeps guiding every product decision: the key isn't what AI does - it's what it doesn't do.
In practice that's meant three things:
- The tool asks clarifying questions before generating anything.
- Every step is explainable - what it will do and why, giving users a full trail from raw data to insight.
- And the human stays in control of execution throughout.
The counterintuitive result: users trust it more when it slows down to confirm assumptions.
Which got us thinking about a harder design question - how do you build friction that feels like safety, not bureaucracy? Because the line between the two is thinner than it looks.
Still figuring it out. Curious if anyone else is wrestling with this.
The "friction as safety vs bureaucracy" distinction is something I think about a lot. My mental model: friction is welcome when it protects the user from a mistake they'd regret. It's bureaucracy when it protects the company from liability the user doesn't care about.
ATM asking "are you sure?" before a $5,000 withdrawal — safety. Cookie consent popup on every website — bureaucracy. The difference is who benefits from the pause. Your approach of asking clarifying questions before generating is smart because it signals "I'm slowing down FOR you, not AT you." That's a hard tone to get right in UI.
Curious: have you found a threshold where users start skipping the confirmations? Like, do repeat users eventually want a "just do it" mode, or does the trust loop keep them engaged with the friction?
Love this philosophy. "What AI doesn't do" is where trust lives.
The "clarifying questions before generating" insight resonates deeply. I apply similar thinking earlier in the pipeline: before AI generates code/content, I validate that users actually want the feature with video prototypes.
The "no" happens at the idea stage, not the execution stage.
Curious: How are you validating that users actually want these friction points (clarifying questions, explainability, human control) before fully implementing them?
I'm finding that what users say they want (safety, transparency) and what they tolerate in practice (speed, automation) can diverge. Would love to hear how you're testing these assumptions.