The PM Cringe Test

How becoming a real user of my own product changed my view on what truly matters

A couple of weeks ago, we launched Opal. We knew it was an early experiment with plenty of rough edges, but also full of amazing potential that I wanted to explore and build on in public. This has been referred to as the Build <> Learn loop, and on my team, we champion a "build to learn" mentality. While this idea has always made sense to me, a recent experience made it click in a way it never had before.

The main way product managers engage in this loop is through "dogfooding"—the practice of using your own product internally as a primary tool. The goal is to uncover bugs, feel UX flaws, and, most importantly, develop empathy by experiencing the same pain points your users will. It signals a core belief: if it’s not good enough for us, it’s not good enough for our users.

And I'm a huge proponent of it! I take our products through the wringer, filing bugs and leaving long, rambling notes in our team chat (a special thank you to everyone who turns those into actual tickets!).

But this latest experience was different.

It started with a side project: an Opal to create custom storybooks for my kids. The workflow was simple: it would take a voice recording of my daughter telling a story, use AI to refine the narrative in a fun style, and then generate illustrations for each page. After a bunch of iterations, I had an Opal I was proud of. It worked!

And then came the moment of truth: I wanted to share it.

The Moment of Truth: From Proud Creator to Frustrated User

My oldest is in school, and I’m part of the class WhatsApp group with all the other moms. It’s a space where my identity is “mom,” not “product manager.” Most of them don’t know what I do for a living; these worlds haven’t really overlapped yet.

But this time, my work and my mom-life were colliding. I had built this cool storybook app, and I genuinely wanted to share it with them. I typed out a message, ready to paste the link.

And then I stopped.

At that moment, I wasn't the PM anymore; I was just a mom about to share something cool. And I was hit with a visceral, uncomfortable truth: the experience I was about to ask my friends to go through was a confusing mess.

It wasn't a new bug I had discovered. It was a friction our team was already aware of - we had talked internally about how annoying it was that to use a shared Opal, someone had to sign in. But putting on my "other mom in the group" hat, the friction suddenly felt ten times worse.

I imagined them clicking the link, not knowing what an "Opal" was, and being immediately hit with a sign-in screen. Why? All they wanted was to use the fun thing I made. Then, if they got through that, they'd see a complex UI allowing them to "remix" my app. While I love giving users that power, in this context, all I wanted was a simple, "read-only" version for them to use.

That's when it hit me. No amount of internal dogfooding had given me this feeling - this visceral cringe of knowing my product was about to create an awkward experience for people I knew. The proud creator vanished, replaced by an empathetic user who knew she couldn't, in good conscience, send that link. The abstract "known issue" had become a concrete, emotional barrier.

It became crystal clear that while we had been so focused on the creation experience, we had a lot of work to do on the equally important sharing and consumption experience. This is a classic limitation of traditional dogfooding; it’s hard to replicate the emotional stakes of actually sharing something you’ve made with a real community when you can’t yet share it.

From User Frustration to Product Action

This accidental user journey immediately translated into action. I jumped into our team chat, shared my experience and the visceral cringe I felt, and the response was amazing. Together, we quickly brainstormed a range of potential solutions. These insights are now helping the team shape the path forward, informing both the 'quick wins' we can implement to alleviate the friction, and the larger, more strategic feature requests that will require a fundamental rethink of our sharing model.

So, did I share it with the mom group? Not yet. Instead, I shared it on X, knowing that a more tech-savvy audience is more forgiving of early-stage friction.

This whole experience was a powerful lesson. Dogfooding is essential, but nothing replaces the clarity that comes from having real skin in the game. Building in public isn't just about shipping early to see what other users think. It’s about forcing yourself to become a user in a real-world context, to feel the friction firsthand, and to close the gap between what you think your product is and what it actually feels like to use.

The Power of Imperfect Launches

While this experience was a powerful learning moment, I wouldn't change how we did it. The goal of an early-stage experiment isn't to be flawless; it's to be a catalyst for learning. We now have real-world, emotionally-charged insights (and not just from me, but from all the Opal users providing us feedback) to channel into our next iteration, which is infinitely more valuable than any internal debate.

Launching early gave us precisely that. Now, armed with this new clarity, we can continue to iterate and improve our product with a much deeper understanding of what truly matters to our users.