What happens when a product manager stops helping other people build their vision — and starts building her own?
Read and find out. 😎
☕ 7 min read
I’ve spent my career helping companies figure out what to build, why to build it, and how to make it matter to real customers.
As a Software Product Manager, you get comfortable living in the tension between a half-baked idea and something that actually provides value. You learn to ask hard questions, say No to half-baked ideas, and hold the line between what customers want and what’s technically possible.
What I didn’t fully appreciate until recently? All of that experience is genuinely useful when you’re the one starting the company.
This is Part 1 of a series documenting my journey as a new founder — building a platform for creative small businesses. I’m sharing the messy bits, the pivots, and the moments of doubt. Because if I don’t write this down, I think it will all start to blend together.
The “I’ve Always Had an Idea” Phase
Like a lot of people in product, I’d been quietly contemplating the pivot to entrepreneurship. But starting a company always felt like a lot. Too much risk. Too many unknowns. Never the right idea. A jump that was a little too big because I’ve always been working within a team.
Then in 2024, I was thinking about my next career move. My current job was coming to an end. After a couple years in an enterprise setting, I wanted to work within a small, fast-moving team, but the right opportunity wasn’t showing up. And then, completely out of nowhere, someone messaged me on LinkedIn.
“She was also based in Chilliwack, had a vision for helping small businesses find local customers — and needed someone with a tech and product background to help bring it to life.”
That was Hillary. We met at a local coffee shop, shared stories and started talking about an idea. Why is it so hard to find locally made things? As a customer, you have to stumble upon local makers. The longer we talked, we realized, we could build something to make it easier.
Hillary brought finance, business consulting experience, and an existing vendor community from a six-week pop-up event she’d run. I brought the product lens and tech experience.
We opened a Word doc and started roughing out our thinking. Our unofficial PRD — product requirements document, for anyone not living in PM-land.
Step One: Prove the Concept
The first real question in any product management process is to outline the problem. And then asking “can we build something that proves this is worth building?”. That’s the POC — proof of concept.
Our first decision was choosing a platform. Do we build or buy? Maybe there was already a platform out there that could add our branding to. We needed something with enough flexibility to test our core idea without draining all resources and locking us into a dead end. After researching options, I landed on WordPress.
I’d recently got hands on experience with it, while building my own portfolio website. It had the plugin ecosystem we needed and a low barrier to get moving.
📋 PM Perspective
- Treat early platform decisions like you’d treat any build-vs-buy tradeoff — fast, reversible, and based on learning, not perfection
- A Word doc brainstorm is a valid PRD at this stage. Writing down ideas is critical to alignment, but we didn’t want to spin our wheels
- Define your MVP ruthlessly — what’s the minimum you need to put in front of real users?
Defining the MVP (And Actually Meaning It)
Here’s where my product management background paid off immediately. It’s so easy to ideate and dream of the perfect solution. I knew that “MVP” gets abused constantly. People call their fully-featured, took-eight-months product an MVP. An MVP is not a fully functioning product. That’s not what MVP means. It’s a minimum viable product.
For us, the problem we’re addressing is vendor visibility: a vendor profile page and a location-based map search.
That’s it. Could a local customer find a vendor near them? Could a vendor show up on the platform? If yes — we had something to put in front of our focus group.
Hillary and I collaborated on the design and customer journey. I dove into customer journeys and UX. Then finding WordPress plugins that fit our needs. By November, we had a working prototype.
Yay! If you want to see it in action -> Visit my archive of the POC
The Pivot (There’s Always a Pivot)
Here’s the part was reminded of: the first version of the thing will probably not be the right version. And that’s ok.
We had a prototype. A map and a couple sample vendor profiles. But our prototype had a real problem: it looked rough on mobile screens.🤮 The available WordPress themes didn’t reflect our brand, and the user experience on small screens was clunky. For a platform meant to serve busy vendors and local shoppers browsing on their phones, this was a blocker — not a nice-to-have fix.
So we went back to the drawing board.
“We needed to pivot. Failing fast is good.”
I went back to the platform research, looking for other options. We needed more control and customization. I started researching no-code development frameworks as a way to build products quickly.
If you haven’t explored this world, it’s genuinely remarkable. These tools take development concepts and make them visual — development knowledge without the need to learn specific syntax. It was exactly in my wheelhouse. And a fun challenge to get back into development.
I dove into Bubble.io tutorials. Within a 3 weeks, I learned the framework and rebuilt the MVP: mobile-first, clean design, intuitive UX.
It was exactly what we envisioned and much faster to deliver.
The “Wait, Can I Actually Do This?” Moment
I’m not going to pretend there wasn’t a moment of genuine surprise when it all came together. I felt a mixture of fear and excitement. And I found myself thinking: can this really be happening?
As a product manager, you’re often surrounded by talented engineers doing the actual building. You influence and guide, but the code isn’t yours. Building this prototype myself — watching the thing work because of decisions I made and work I did — felt different in a way I didn’t expect.
“Do I take the leap and fully commit?“
It also came with a decision I couldn’t delay any longer. My contract was coming to an end, and an extension wasn’t looking exciting. I had to choose: jump in and give this everything, or keep it as a side project while taking a safer full-time role.
I’ll tell you what I decided in Part 2 — but I think you can probably guess.
We’re living in an era where the technical barriers to getting something off the ground have genuinely never been lower. What would have required a full-stack developer and $100K ten years ago can now be validated with a no-code prototype and a few weeks of focused effort.
Whether the product is a success, is a whole other story.
📖 Up Next: Part 2 — Riding the Wave
What happens after the prototype works? I’ll share what it looked like to go all-in, get in front of real vendors, and start learning what the market actually wants.
