
Last week I logged into Prodini as if I'd never built it. No insider access, no shortcuts, full onboarding flow, cold start, blank screen.
I wanted to feel what a new user feels. Not what I imagine they feel.
Most founders call this dogfooding. I'd call what I did something different. Dogfooding is using your own product within the comfort of everything you already know. What I did was deliberately strip away my own context and simulate the experience of someone who has never heard of us.
The difference matters more than most founders realize.
The Blind Spot Nobody Talks About

Here's the uncomfortable truth about dogfooding: the people who build the product are structurally the worst people to evaluate the first-time experience. You know the codebase. You know the intended flow. You navigate intuitively past the exact friction points that stop a stranger cold.
Research on product dogfooding confirms this pattern. Internal teams validate their own assumptions. Edge cases get classified as rare rather than common. The confirmation bias is well documented and almost universal.
Superhuman's CEO, Rahul Vohra, understood this early. He personally onboarded every one of their first 200 users, running five two-hour sessions per week. Each session produced pages of notes, feature requests, and bugs. His head of growth later said that depth of insight is impossible to gain from analytics alone, even with session recording tools.
The lesson wasn't that founders should watch users. It was that founders should become users, without the safety net of insider knowledge.
Why the Obvious Fix Doesn't Work
The instinct is to run usability tests. Hire a research firm. Watch recordings. Build dashboards.
All of those have value. None of them replace the experience of sitting down, cold, and trying to accomplish something with your own product when you have zero context about how it's supposed to work.
Dashboards tell you where users drop off. They don't tell you what it felt like in the moment they decided to leave.
What I Actually Found

The Confluence context loading surprised me. Fast, and the relevance filtering was better than I expected. The edge case section caught two things I hadn't included in my own brief. The output length was shorter than I feared, which turns out to be a feature. Engineering teams prefer documents that fit on one screen.
Those were the good parts. Here's what frustrated me.
First-time setup takes 8 minutes. That's too long. We know. We're working on it.
That number isn't a minor UX complaint. Industry benchmarks show that 75% of SaaS users abandon a product within the first week if they struggle to get started. A studied case found that reducing time-to-first-value from 8 minutes to 3 minutes lifted Day-1 retention from 45% to 61%. Each friction point removed during onboarding improves completion rates by 3 to 8 percent, and those improvements compound into 25 to 50 percent increases in customer lifetime value over 12 to 24 months.
Eight minutes sits exactly at the industry's documented danger zone.
The other thing that frustrated me was subtler. Freeform input produces freeform output. The tool rewards structure, which is probably right, but it feels like friction before you learn how to work with it. This is the kind of insight you can only get by experiencing the product without the mental model of how it was designed.
The Chef Who Never Orders Off Their Own Menu

Think about it this way. A chef knows every component in their kitchen. They source the ingredients, trained the line cooks, designed the plating, tasted every dish in development. But they almost never sit at a table on a Saturday night, read the menu cold, wait for service, and eat the dish as a stranger would.
The 8-minute experience gap is not a technical failure. It's the difference between making the dish and eating it.
Most founders who talk about dogfooding are describing the kitchen experience. They taste the sauce while cooking. They never sit at the table. The useful version of this practice requires deliberately making yourself ignorant. Almost no one does it.
What This Means for How We Build Prodini

This test changed how we prioritize. Not because we discovered new bugs. Because we felt old friction differently.
We built Prodini to preserve decision context across tools and conversations. The AI product management workflow connects Confluence, Jira, codebases, and team conversations into a continuous system. The architecture works. The context loading is genuinely good.
But none of that matters if a new user bounces at minute six of setup before they ever see what the product can do.
The pre-activation churn problem is the invisible metric in early-stage SaaS. These users never appear in your retention data. They just disappear. You can only find them if you go looking, and you can only go looking if you know the problem exists.
The Uncomfortable Verdict
My honest bar was simple. If I were a product manager who didn't build this, would I have emailed the founders by now?
I would.
The less comfortable part: that setup friction will cost us beta users who don't push through it. LinkedIn's algorithm now rewards this kind of operational transparency from founders. But the real reason to share it isn't engagement. It's accountability.
If you've tried Prodini and bounced, I genuinely want to know where you stopped. DM me or book a quick call. The next version gets shaped by exactly that conversation.