What I Learned About Customer-Centric Go-to-Market from Invest Ottawa's IOFlex Program

Startups that Sell to Ghosts Die

Uncomfortable fact: most startups do not fail because the founders didn’t know how to build. They fail because they built something for someone who does not exist. Or, they fail because they couldn’t satisfy their clients' needs consistently. I know this because I have been guilty of both myself. As a founder running AI Buddy Catalyst Labs, I have spent entire weeks polishing features that my actual customers never asked for. And in a previous start-up I worked at, I had failed to grow the B2B wing because I didn’t have products to upsell. 

Disclaimer: 

My company, AI Buddy Catalyst Labs, is currently in the IO Flex program of Invest Ottawa and we recently got accepted into the Traction Program. This blog is the first in a series where I will share what I learn from each session, translated into real, usable strategy for founders who are seeking to grow.

If you have ever wondered why your product is not selling even though it is "really good," or how to grow your startup from 5K MRR to beyond, this one is for you.

The session was taken by Urooj Qureshi, Founder & CEO of Design Centered Co.

Session Breakdown: From Assumptions to Validation

1. Introduction to Customer-Centric Approach

In short, build for real people, not imaginary ones. A customer-centric approach means you build exactly what the customer needs. 

This sounds simple, but the gap between "I know my customer" and "I have validated who my customer is" can be the difference between a thriving company and a burning bank account. The session challenged us to stop assuming and start asking.

“Who is the actual customer who can buy from me and keep me profitable?” 

2. Hypothesis of Ideal Customer Profile (ICP) and Proto-Persona

Next, we went deeper into the concept of an Ideal Customer Profile (ICP) and a proto-persona. Think of a proto-persona as a sketch of your ideal buyer. As one version you want to test and validate, before you start jumping into creating ads or marketing content.

The key distinction here is important:

• ICP: Your north star; the fully validated, data-backed description of who will pay you money consistently.
• Proto-Persona: The hypothesis version built from your assumptions and gut instinct.

 
Then you go test it. If it holds up, great. If it cracks under pressure, even better, because now you know before you waste six months of development time.

3. Rapid Validation, Research Tools, and Techniques

The session then moved into rapid validation, which is where things get practical. We discussed research tools and techniques you can use to test your assumptions before committing to building anything expensive.

A major theme repeated throughout the session was the importance of detailing the user journey. You cannot validate a customer if you do not understand their path from frustration to solution.

Two tools were highlighted as especially useful: Apollo and ZoomInfo. LinkedIn, Clay, and other apps are also there. These platforms help you find real professionals who can share genuine frustrations from their work experience.

When people share their real professional pain points, you are no longer guessing at problems. You are hearing them directly. That makes building solutions dramatically easier and more accurate.

4. Prototyping Products and Services

We touched on prototyping products and services toward the end, though we did not go deep into this topic. The conversation centered on the idea that once you have validated your assumptions, you move into building something testable. Not a full production product, but a prototype that lets your potential customer interact with your idea and give you real feedback.

Exercise Spotlight: The Hypothesis-Persona Map

One of the first exercises we completed during the session was the Hypothesis-Persona Map. This is a structured template that forces you to formalize your assumptions about your ideal customer before you go out and validate them.

The template asks you to define a clear hypothesis statement about who your customer is and what they will do. Then it walks you through building a proto-persona by answering specific questions: What does this person look like? What is their name? What is their role? Where do they work? What is their personal mission?

It then pushes you further: What are they struggling with? What are they trying to accomplish? How do they currently address their needs? Why would they want your solution? Where are you likely to find them?

The beauty of this exercise is that it forces clarity. You cannot hide behind vague language like "our target market is small businesses." You have to get specific. You have to name the person. You have to describe their pain in their words, not yours. The Hypothesis-Persona Map is your accountability partner before you spend a single dollar on development.

Exercise Spotlight: Bringing the Proto-Persona to Life

The second exercise took the Hypothesis-Persona Map and made us fill it in for our own business. For AI Buddy Catalyst Labs, I built a proto-persona named Adam. Adam is a CEO of an early-stage startup generating between $1K and $10K in monthly recurring revenue. He is successful, curious, and willing to allocate $2K to $5K monthly for experimentation to grow his business. 

Adam's core struggle is that he has a good product, but cannot figure out how to scale. He does not know where to invest his limited budget or time or both to make more money, serve more clients, or do both. He wonders whether he needs a consultant, a subcontractor, a co founder, or new digital tools. He is currently solving these problems by talking to AI, hiring human consultants, Googling answers, reading books, and doing things himself.

His goals break down into two timelines. Immediately, Adam wants more sales, more marketing exposure, more work getting done, and a better product. Six months later, he wants investment readiness and improved marketing presence. A year later, he wants to have a loyal community, sold 1 Million Dollars worth of his product, and has raised 3 Million to do more of the good work.

Now, why would Adam buy DocDirector? Because he wants immediate results, MBA-level knowledge enablement (an AI that is built with knowledge base focusing of strategy, management principles, and productivity wisdom, with BI dashboards for data visualization, project management support from a seasoned operator, access to quality subcontractors at fair rates, and a partner who gives him more context time because we work with fewer clients. You can find Adam on LinkedIn, in newspapers, on blogs, and across social media channels.

This exercise turned abstract thinking into something tangible. It gave me a person to build for, not a "segment." That shift alone changes everything about how you approach product development, marketing, and sales.

The Iteration Loop: Why Getting It Wrong Is the Strategy

Founders looking for perfection at this stage are actually at a risk. They need to resist the urge to lock in your ICP on the first attempt. It is an iteration loop.

If your proto-persona does not hold up during validation, that is not a failure. That is the system working exactly as intended. You go back, adjust your hypothesis, refine the persona, and test again. Like pruning a tree, you cut back what is not working so the strong branches can grow. 

When you skip this loop and jump straight into building a production-grade product, you’re at a risk of building for a customer who may not exist. 

This brings up a practical question for technical founders: should you build in staging first, or should you use vibe coding to create quick prototypes?

My take after this session is that both approaches have merit, but the sequence matters:

• Start with rapid prototyping or vibe coding. Build something fast and cheap. Get it in front of real potential customers. Let them poke holes in it. Let them tell you what is missing, what is confusing, and what they actually need.
• Validate before you invest. Only when a customer has touched your prototype and confirmed that it solves their problem should you consider moving to production. Production code has higher requirements for security, scalability, testing, and maintenance. That investment is only worth making when you have evidence that someone will pay for what you are building.
• Use staging as the bridge. Once validated, build in a staging environment where you can verify quality with the customer before going live. This gives you a safety net between "validated idea" and "shipped product."

The formula is simple: Hypothesize, prototype, validate, iterate, and only then build for production. Skipping steps is how you end up with a polished product that nobody wants.

What Is Coming Next in This Series

This blog is the first installment in my IO Traction Learning Series, where I will document insights from each session in the Invest Ottawa’s Traction Program. Upcoming topics will include deeper dives into sales, growth marketing, customer service, and go-to-market execution frameworks.

If you are a founder building in Canada's startup ecosystem, or anywhere else for that matter, follow along. These are lessons I am learning in real time, and I believe sharing them openly creates more value than hoarding them.

Conclusion

The biggest takeaway from this session is that your first ICP guess is almost certainly wrong, and that is completely fine. The best practices are to validate assumptions early, iterate relentlessly, and resist the temptation to build production-grade products before confirming a sale or a waiting list registration. 

P.s. As mentioned earlier, I made this exact mistake. I built a product last year and pushed the sale but didn’t find customers who were continuously willing to pay me for that product. Luckily, I work in software development and content creation so I got to pivot faster and avoid a crash. Being flexible helps. More on that later.