There's a specific kind of clarity that only comes after you've done things the hard way.

After months of scrappy building, manual workarounds, and more defeated evenings than I'd like to count, my co-founder and I had something we hadn't started with: proof. We had creators on the platform. We had restaurants signed up. We had a process that worked, just not a platform that could scale it.

So we started again. Properly this time.

When It Was Time to Build Properly

The decision to rebuild wasn't dramatic. It was just obvious. We'd validated the idea, we understood our users in a way we couldn't have at the start, and we'd hit the ceiling of what our first version could do. The limitations we'd worked around were becoming structural problems, and structural problems don't get better by ignoring them.

The redesign wasn't just a visual refresh. It was a rethinking of the entire architecture; mapping user flows for creators, restaurants, and customers redeeming offers through public links, working through every touchpoint, every state, every edge case. It was the kind of thorough, considered product work I'd done in corporate, but now I was doing it for something I owned entirely. Something that would either work or wouldn't, and where the outcome landed squarely on us.

That felt different. Everything felt higher stakes, more personal, more real.

What the First Version Actually Gave Us

Here's what I understood going into the rebuild that I hadn't understood at the start: you can't design a good product without knowing your users deeply, and you can't know your users deeply without having shipped something imperfect first.

The first version wasn't a failure. It was research. Every manual workaround, every limitation we hit, every piece of feedback from a creator who couldn't find what they needed, all of it fed directly into how we approached the rebuild. The architecture decisions we made the second time around were better because we'd lived inside the first version long enough to understand where it was breaking down.

The MVP is where you earn the right to build the real product. It's where you find out what you actually need to make, as opposed to what you thought you needed to make. That distinction matters more than most people realise.

The Rebuild in Practice

We migrated to a new platform, rebuilt the backend with scalability in mind, and implemented automations through Make.com that replaced the manual processes we'd been running by hand. We used Memberstack for user authentication, built out proper campaign tracking, and designed the creator and restaurant experiences as distinct journeys rather than variations of the same flow.

The sitemap alone took longer than I expected — not because it was technically complex, but because getting it right required holding two completely different user types in mind simultaneously and making sure neither experience was compromised by the needs of the other. That's a product problem, not a technical one, and it's exactly the kind of thinking that corporate PM work prepares you for. The difference is that in a startup, you're solving it without a team around you, and the decisions you make at the architecture level will either support or constrain everything you build on top of them.

We launched. And it worked.

What It Looks Like Now

A year later, Table Talks has over 500 creators and more than 25 restaurants signed up. That number means something to me, not just as a metric, but as proof that the scrappy, imperfect, learn-as-you-go approach actually works when you stay close to your users and keep iterating honestly.

Today, my role doesn't fit neatly into any job description. I plan, design, and build. I troubleshoot at odd hours. I talk to creators and restaurants and try to understand what they need before they know how to articulate it. I write the brief and then review the output against the brief I wrote, because there's no one else in the room.

The PM title is still the closest thing to what I do, but it's a version of the role with no ceiling and no floor. The scope is everything, and the accountability is total.

What I've come to appreciate is that this is actually the purest form of product thinking. There's no layer of abstraction between you and the user, no committee between you and the decision. I used to think the structure of corporate PM was what made the work good. Now I think it was just what made it feel safe.

The best product work happens when you're close enough to the problem to feel it, and honest enough with yourself to keep going when the solution isn't obvious yet. Some of the most important things I've built started as defeated evenings in front of a screen, not knowing if it was going to work.

That's what being a PM as a co-founder actually looks like. And I wouldn't trade it.

This is part two of a two-part series. Part one, "What Nobody Tells You About PM-ing as a Founder," covers the early days, the mindset shifts, and everything I had to unlearn.