There's a version of product management that looks very clean from the outside.

You have a roadmap. You have engineers. You have designers. You run standups, write tickets, prioritise the backlog, and somewhere in between all of that, you ship things. It's structured. It has edges. You know where your job starts and where it ends.

That was me, for years, in corporate. And I was good at it.

Then I became a co-founder, and I had to unlearn almost everything.

The Moment the Job Description Disappeared

When my co-founder and I started Table Talks, there was no product team, no design team, no engineering team. There were two of us, a laptop, a landing page, and a Google Form.

That was the MVP.

I remember sitting with that reality and feeling two things at once: excited, and completely untethered. In corporate, being a PM means connecting the dots between business, design, and engineering. In a startup, it means being all three simultaneously, imperfectly, and usually under pressure. There was no one to escalate to, no process to fall back on. Every decision was mine to own, and the only way to know if it was the right one was to ship it and find out.

The title didn't change. Everything else did.

What Corporate Taught Me, and What It Didn't

Corporate PM gave me a strong foundation. I knew how to think about users, frame problems before jumping to solutions, write a brief, push back on scope creep. Those instincts didn't disappear when I became a founder — if anything, they became more valuable, because I was the only one applying them.

What corporate didn't prepare me for was the speed, and the ambiguity that comes with it.

In a large organisation, decisions move through layers. There are sign-offs, reviews, alignment meetings. It can be frustrating, but it also means you're rarely making a call completely alone. There's a safety net built into the structure, and most of the time you don't notice it's there until it's gone.

In a startup, that net doesn't exist. You make a call on a Tuesday afternoon, and by Thursday it's live and real people are using it. The feedback loop is brutal and immediate, and if you got it wrong, you're the one who has to fix it, usually that same Thursday, usually while something else is also on fire.

The biggest mindset shift wasn't technical. It was learning to be comfortable with imperfection. In corporate, shipping something half-baked felt like a failure. In a startup, it's often the point — you need real signal before you invest further. I had to let go of the idea that good product work always looks polished. Sometimes it looks like a Google Form. Sometimes that's exactly right.

The PM Brain vs. The Startup Reality

My PM brain wanted structure. User flows mapped before a single screen was designed, a clear information architecture, a considered backend before we touched the frontend.

The startup reality was: we needed to ship now.

We built our first version in Webflow. It wasn't perfect, far from it. But it worked well enough to run real tastings, sign up real creators, and learn what we actually needed to build next. And that was the whole point.

The tension between "build it right" and "build it now" is something every founder has to navigate. I won't pretend I always got the balance right. What I've come to understand is that the answer isn't to pick one side permanently it's to be intentional about which mode you're in, and why, and to know when to switch.

The Feature That Nearly Broke Me

If there's one moment that captures what building as a founder actually feels like, it's the Public Links feature.

The idea was simple: each creator would have a public-facing page showcasing all the restaurant offers they'd opted in to promote. Show the restaurants, show the offers, filter by what the creator had selected. Simple, right?

In my head, yes. In Webflow, absolutely not.

The problem was nesting. Webflow limits how many CMS collections you can double-nest, and what we needed required double-nesting with dynamic filters based on each creator's individual opt-ins. We tried a third-party app that seemed like it would solve it, until we hit a cap on the number of items it could display. Back to square one.

I spent days on this. Days of Webflow forums, workarounds that almost worked, solutions that introduced new problems. There were moments where I genuinely didn't know if we'd be able to build what we needed on the platform we'd chosen, and that's a frightening place to be when the feature isn't optional.

In the end, I turned to ChatGPT and went through it piece by piece until we landed on a custom code solution that actually worked. But getting there involved more defeated evenings than I'd like to admit, staring at a screen wondering if I'd made a fundamental mistake somewhere upstream.

What that experience gave me, beyond the solution itself, was a much more honest relationship with the limits of my own knowledge and a much greater respect for what it takes to build something from nothing when you're the only one who can fix it.

What I Had to Learn From Scratch

Webflow forums became a second home. ChatGPT became a patient tutor. I spent evenings learning enough about backend structures to make informed decisions about the frontend, and enough about automations to build our own workflows in Make.com. I learned about user authentication, QR code tracking, and what a sitemap actually needs to contain when you're designing for two completely different user types on the same platform.

None of this was in my job description as a PM. All of it became essential.

The gaps in your knowledge don't stay abstract when you're a founder, they show up in the product. The closer you can get to understanding how the thing you're building actually works, the better your decisions will be. That much I know for certain.

This is part one of a two-part series. Part two, "The Rebuild: What Happens After You've Figured Out What You're Making," picks up where this leaves off.