I Built a $500M Mobile Product, but the MISTAKES I made???

Here's a confession I don't often make at parties: some of my best-looking work was actually my worst thinking.

When I joined iHerb as a Senior Product Manager, I was handed one of the most exciting blank canvases in product management — build the mobile apps from scratch. No legacy code to wrestle with. No "but we've always done it this way." Just a massive opportunity and a team ready to run.

We ran. Hard. Eighteen months later, we had iOS and Android mobile apps. Real ones. And over the next five and a half years, those apps helped grow iHerb's mobile revenue to more than $500 million annually. If you looked at it from the outside, it looked like a home run.

It was. And it wasn't.

The trap of building what you think users want

Here's what nobody tells you about 0-to-1 product work: the launch is the easy part. The hard part — the part that will humble even the most seasoned PM — is figuring out what to build next.

After our MVP, I was energized. I had ideas. A lot of them. I wanted to build features that would delight users, things that felt innovative, creative, different. So we built them. And some of them... quietly flopped.

Not dramatically. There were no alarms going off. No one yelled. In fact, on the surface everything looked fine. But the data told a quieter story: users weren't sticking with the features we were most excited about. Retention wasn't moving the way we expected. We were building, but we weren't learning.

"I confused being creative with being right. Turns out, creativity without validation is just expensive guessing."

— Peter Hong

The shift that changed everything for me was simple, but not easy: I stopped asking "what cool thing can we build?" and started asking "what problem are we actually solving, and how do we know?"

A/B testing changed how I think — not just what I ship

We started running A/B tests. A lot of them. And what happened next was one of the most professionally humbling stretches of my career: I was wrong. Repeatedly. Confidently wrong.

Features I thought would skyrocket engagement? Flat. Designs I was sure users would love? Meh. But every wrong call taught me something invaluable — users are not you. They are also not your stakeholders, your CEO, or whoever has the loudest opinion in the room. They are the people with the actual problem, and they vote with their behavior, not their words.

The lesson I carry everywhere

Validate before you build. Test before you scale. The best product instinct in the world is still just a hypothesis until data proves it. A creative idea is the beginning of the conversation with users — not the end of it.

What this taught me about leading teams

Somewhere in those years at iHerb, I also became a team builder — somewhat accidentally. A small product team started forming around the work, and I had to figure out leadership on the fly.

What I learned: the best teams aren't driven by the PM's vision. They're driven by a shared goal that the whole team helped shape. When everyone understands the "why" behind what they're building — when a developer sees the connection between their code and a real customer outcome — something shifts. People stop being order-takers and start being problem-solvers. That's when the magic happens.

I've carried that belief through every role since: from Walgreens (where I joined during COVID because I wanted to make a real difference in healthcare access), to building in-flight entertainment distribution products at Thales and Panasonic, to running my own eCommerce business on Amazon and my own website using Shopify. The industries change. The principle doesn't.

So why consulting? Why now?

After 14 years across eCommerce, health, aerospace, and my own ventures, I've noticed something: a lot of small and mid-size companies are sitting on incredible potential, and they're leaving it on the table — not because they lack talent, but because they lack the product infrastructure to channel it.

They're building features based on gut feel. They're prioritizing based on whoever shouted loudest. They're measuring the wrong things, or not measuring at all. And they don't need a full-time PM team to fix it — they need someone who's been in the trenches and can help them build smarter.

That's why I started this consulting practice. And this blog.

I want to share the real stuff — the mistakes, the frameworks that actually work, and the mindset shifts that turned me from an engineer who builds things into a product manager who builds the right things.

Welcome to the blog. Let's build something worth building.

Message me and book a FREE intro call

© 2026. All rights reserved.