- Out of Scope
- Posts
- 🚀 Learning to Say Yes
🚀 Learning to Say Yes
What happens when a professional "no" person becomes a founder
Shoutout to Nausher for getting the riddle right. And also for threatening to stop responding if I didn’t give him a mention. Sometimes threats do work.
Six weeks as a founder. Am I seasoned yet? (Definitely not.)
But I have aged approximately seven years in dog years, so that's something. And I want to share the reality check on how it’s actually going—plus the uncomfortable truth I’m bumping into: the skill that made me an effective PM is working against me as a founder.
Last newsletter, I set three simple goals for myself:
Become a builder again
Find the problem to solve
Find a community of builders
Six Weeks In: The Reality Check
Here's how it’s going so far:
I'm building a SaaS product called Sticky Flows—a tool that helps app developers enhance their app onboarding by analyzing their screens and identifying improvements to implement. It's my first real attempt at building something myself since becoming a founder, using the latest tools and AI coding assistants to figure it out as I go. Is this the billion-dollar idea? Honestly, I have no clue. But I'm learning, which feels like progress.
I also shadowed a dental office manager for a day to try finding problems in the wild. (Turns out small business operations are fascinating and way messier than any roadmap I've managed.) Did I find my big idea there? Maybe. We'll see. But it confirmed something important: I need to get out of my head and into the real world.
The third goal—finding a community—is where things got interesting. I started saying yes to things. Meetups. Coffee chats. Twitter DMs. Random founder conversations. A virtual hackathon I had zero business co-hosting. And that's when the biggest realization hit me: One of the skills that makes me an effective PM is terrible for being a founder.
You're a Professional "No" Person
As the head of product at tendercare, one of my listed superpowers was to say "no" as much as humanly possible to keep us on track. Every feature request could grow 5x in scope if we weren’t careful. Every stakeholder had a "quick win" that would definitely only take two days. (Narrator: It would not take two days.)
My job was to be the gatekeeper. The bad cop. The person who protected my team's time and sanity so they could actually ship great work.
Take the Android app, for example. We knew there was demand. We got requests constantly. Users couldn't invite their family members to the platform because they were the dreaded “green texters”—Android users living in an iOS world. The guilt was real. The feature requests were relentless.
But I said no. Over and over and over.
Why? Because we were still refining our core offering. We barely had the resources to maintain one platform, let alone two. Adding Android would have spread the team too thin. Quality would suffer. Bugs would multiply. Someone would cry in a sprint retro. Eventually, the timing became right—the demand hit a tipping point, we had the resources, and we built it. But saying no for that long protected the team from chaos.
As a PM, saying no is a superpower. You're the shield between your team and the infinite entropy of stakeholder requests. Here's the thing: I got too good at saying no.
The Shift: Now You Need to Say Yes
As a founder, the entire game flips. You don't have a backlog overflowing with validated ideas. You don't have stakeholders lining up with feature requests. You have nothing. No customers. No traction. No proof that anyone wants what you're building.
Your job isn't to protect resources—it's to increase your surface area of opportunity. You need to expose yourself to as many people, problems, and possibilities as you can, because you never know which random conversation will unlock the insight you need. This is the exact opposite of everything I trained myself to do.
It's like being a character in that Jim Carrey movie, Yes Man, where he says yes to everything and his life transforms. (Yes, I'm comparing myself to Jim Carrey. Yes, my favorite movie is The Grinch. Yes, I'm aware how that sounds.)
But here's where it gets tricky: You can't say yes to everything because you're a team of one (or close to it). You have even fewer resources than you did as a PM. So how do you decide which yes’s really matter?
The Founder's YES Filter
Here's what I'm learning about when to say yes as a founder. Ask yourself these two questions:
1. Does this increase my surface area? Will it expose me to new people, problems, or opportunities in my space? Does it help me learn something about my potential customers or the problem I'm solving?
2. Can I actually afford it? Do I have the time, energy, and sanity to say yes without completely burning out or derailing my core work?
If both answers are yes, say yes. Here's the mindset shift:
As a PM: Default to no. Only say yes when the case is bulletproof and ROI is proven.
As a founder: Default to yes, only say no when you truly can't afford it.
The PM in me hates how unscientific this feels. There's no ROI calculation. No confidence interval. No stakeholder alignment doc. But that's the point. At this stage, you're not optimizing for efficiency—you're optimizing for serendipity.
What Happened When I Said Yes
So what actually came from all this "yes"-ing?
From meetups: I met three other founders working in adjacent spaces to mine. It's helped me refine my product idea and get feedback on my pitch.
From Twitter: My follower count is slowly climbing (emphasis on slowly), but more importantly, I'm getting daily feedback on my ideas. People DM me with their own experiences. I'm learning what resonates and what doesn't.
From experiments: I'm learning to build with AI coding tools—a skill I didn't have six weeks ago. Some project ideas didn't work (RIP to the MVPs that never saw daylight), but each one taught me something about what users actually want (or don't want). The failures are data points, not dead ends.
But here's the thing: I also said yes to things that went nowhere. A few projects that didn't pan out. A few meetups that didn't lead to any meaningful connections. Time spent that didn't have an obvious return. The difference? As a founder, I can afford a lower hit rate. I'm playing a volume game. As a PM protecting a team's limited capacity, I couldn't afford that luxury.
The Lesson: Surface Area Beats Efficiency (For Now)
If you're a PM considering a founder leap, here's what you need to know: Challenge some of your core instincts. You're trained to say no, to optimize, to protect your team from distractions. Those instincts kept you employed and made you good at your job.
But as a founder—especially in the early days—you need to increase your exposure to randomness. Say yes to things that don't make immediate sense. Show up to the meetup even when you're tired. Reply to the DM even when you're busy. You're not trying to be efficient yet. You're trying to increase your luck surface area.
And if you're a PM who's staying put? You can still apply this. Say yes to the coffee chat with someone outside your company. Say yes to the side project that doesn't advance your OKRs. Say yes to sharing your thinking publicly, even if it's scary. You don't have to quit your job to start saying yes.
The Riddle
I sometimes run, but I can’t walk. What am I?
The Meme
