What happens when a product manager stops helping other people build their vision — and starts building her own?
✍️ By Mimi Nearing📍 Chilliwack, BC ☕ 7 min read
I’ve spent my career helping teams figure out what to build, why to build it, and how to make it matter to real people. As a product manager in BC, you get comfortable living in the tension between a half-baked idea and something that actually ships. You learn to ask hard questions, build scrappy prototypes, 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. It’s a journey of building a marketplace for creative small businesses, from a random DM to a working prototype. I’m sharing the messy bits, the pivots, and the moments of “wait, can I actually do this?” because it’s been a big year and I don’t want to forget any part.
The “I’ve Always Had an Idea” Phase
Like a lot of people in Product, I’d been quietly contemplating about entrepreneurship and the idea of building my own product. I have hobbies on the creative side but never felt like they needed to be anything more. Friends and family have been telling me to “sell my makes” for years. I’ve been following other creators on social media — knitting, crochet, painting — so know it’s a hustle from dawn to dusk. Starting a company has always felt like a lot. Too much risk. Too many unknowns. A jump that was a little too big.
Then in 2024, I was thinking carefully about my next career move. After spending a couple years in the enterprise world, I wanted to work within a small, fast-moving team, but the right opportunity wasn’t showing up. Then, completely out of nowhere, I got a random message on LinkedIn. It said “Hello fellow Chilliwack Professional”.
That was Hillary. “She was also based in Chilliwack, had a vision for helping small businesses find local customers — and needed someone with a tech background & experience to help bring it to life.”
We met at a coffee shop, started talking about ideas, and the vision. 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 and tech lens. I couldn’t stop thinking about it.
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 isn’t “what should we build?” It’s understanding the actual problem users are facing. Just because we build something, doesn’t mean that people will use it. Our first step is validating our idea. That’s the POC — proof of concept.
Having worked within large companies, surrounded by professional developers, I didn’t realize how many options there are to build with. Technology, tools and frameworks have come so long, it’s significantly lowered the bar. We didn’t need to hire a dev and spend $100K. We needed something with enough flexibility to test our core idea without locking us into a dead end. After researching options, we landed on WordPress. It’s got a great community behind it and has been around for so long. It had the plugin ecosystem we needed and a low barrier to get moving.
📋 PM Perspective:
- Treat early decisions like you’d treat any build-vs-buy tradeoff — fast, reversible, and based on learning, not perfection
- As much as I love documentation, at this stage, all that’s needed is to write out our thoughts. No template/format needed. A Word doc brainstorm is a valid PRD at this stage.
- Define your MVP. What’s the minimum you need to put in front of real users? This is what the majority of our discussion centred on.
Defining the MVP (And Actually Meaning It)
Here’s where my product management background paid off immediately. I knew that “MVP” gets abused constantly. People call their fully-featured, took-eight-months product an MVP. That’s not what MVP means.
For us, the real minimum viable product was two things: 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 WordPress tutorials and plugins. By November, we had a working prototype.
The Pivot (There’s Always a Pivot)
Here’s the part I know to be true: the first version of the thing will probably not be the right version. And that’s fine. Because even if it’s not right, there is something to learn.
Once I had a prototype put together, we had something tangible. Trying it out and playing around with it, we realized we 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, not good. 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. Not panic or give up.”
We needed more control over the front-end. The existing POC wasn’t configurable enough so I started researching no-code development frameworks. If you haven’t explored this world, it’s genuinely remarkable. These tools take development concepts and make them visual — maximum flexibility, accessible learning curve. The community of products people have built on no-code platforms is seriously impressive.
📋 PM Perspective:
- Looking back at this decision, if we were making it today, I think we would’ve made a different one. That’s how quickly technology is advancing.
- When deciding between web or app, what’s the guiding reasoning?
Within a couple of weeks, I brushed off my dev skills, completed a tutorial, got building. Having done it once, rebuilding the vendor profile and map search was so much faster. I rebuilt the prototype: now mobile-first, clean design, intuitive UX. The kind of product experience I’d advocate for in any PM role — except this time, I was the one who built it.
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. There was. The prototype worked, it looked good, users could actually navigate it. The moment I connected the domain to it, it started to feel real. 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 was so much more exciting. I was in it 100%.
This moment 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.
As a Product Manager in BC/Canada the leap to “founder” was big. It took me a while to make the leap, but I discovered in those first few months, something important: my skills are more transferable than I realized. Discovery, scoping, prioritization, user empathy, stakeholder communication — that’s the core work of building a product company. The title changes. The skills don’t.
And 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.
I’m not delusional about the road ahead. It’s hard. But the hardest part is starting. You can visit homemadecommunity.com and checkout how far we’ve come.
📖 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.
