I thought I needed a better pitch. I actually needed better questions.
One thing that's surprised me while talking to founders:
The conversations go much better when I stop thinking about "pitching" and start trying to understand their business.
People open up when you ask genuine questions about what they're building, what's slowing them down, and what they keep putting off.
A lot of those conversations have challenged my assumptions about the problems founders actually want solved.
For those of you who've validated a product or service before:
Did talking to people change your original idea, or did it mostly confirm what you already believed?
Better questions uncover behavior instead of collecting polite agreement. Ask about the last time the problem occurred, what they did, who owned it, what it cost, and whether money already moved toward a workaround. Those answers make the pitch much easier to earn.
the moment multiple people described the same pain in different words, I knew I was onto something.
That's the signal I'm chasing too. What was the pain, and did it turn into something you built?
Talking to people didn't changed my original idea. Just added some features or improved it.
Curious was there a comment or conversation that specifically changed a feature, or was it more general polish?
It mostly confirmed the core problem for us, but changed who we thought would pay for it first. We assumed larger teams would be the early adopters, then kept hearing solo operators describe the same background tracking problem in almost identical language. That shifted who we are actually building the first version for.
One practice that helped me avoid collecting interesting conversations without making a decision is to define the decision before each set of interviews.
For example:
“We will focus on this segment if three out of five people describe the problem without prompting, already use a workaround, and can explain what the workaround costs them.”
After each conversation, I record the past behavior, the workaround, who owns the problem, and what decision the evidence should change.
Otherwise, it is easy to finish ten good conversations with more notes but no clearer direction.
The most valuable interview is often not the one that produces a feature idea. It is the one that changes the target customer, the urgency of the problem, or the reason someone might pay.
What specific decision are your current founder conversations intended to change?
That's a great way to frame it. Right now, the main decision I'm trying to make is whether I'm solving the problem for the right customer not whether the problem exists.
Going into these conversations, I assumed most founders would value someone simply taking operational tasks off their plate. What I've learned is that the pain is much stronger for founders who already have traction and are juggling growth, customers, and operations at the same time.
So now I'm paying much more attention to who already has a workaround, what they're doing instead, and whether that workaround is costing them meaningful time or money. If I keep seeing the same pattern, that'll shape who I build TaskRelay for much more than adding another service ever would.
That sounds like a meaningful narrowing.
“Founders with traction” may still cover a wide range, so the next useful signal might be the threshold where operational work becomes expensive enough to pay someone to remove it.
For example, it could be when support starts interrupting product work, when the founder is spending five or more hours a week on repetitive operations, or when they’ve already stitched together a workaround using contractors, assistants, or multiple tools.
At that point, the ideal customer may be defined less by industry or company size and more by a specific operating threshold.
Have you noticed a recurring trigger that appears just before founders start actively looking for help?
That matches what I've been seeing too.
The founders who seem most ready are the ones who already have recurring operational work that's pulling them away from building. That's actually why I'm building TaskRelay we take those recurring tasks off founders' plates without them needing to hire someone full-time.
Out of curiosity, what's your current workaround? Is there any operational work you'd happily hand off if someone could take ownership of it?
My current workaround is a mix of GitHub Issues, calendar reminders, and manual notes.
The operational work I’d most readily hand off is the follow-up around customer conversations: tracking who I spoke with, what problem they described, what I promised to do, and when I should follow up again.
It’s repetitive, but it still requires enough product context and judgement that simple automation tends to break down. I’m not actively looking to outsource it yet, but I would consider it once the process was clearly defined and the handoff was easy to audit.
How does TaskRelay handle recurring work that still requires product context or judgement?
That's exactly the kind of work I designed TaskRelay for.
My approach isn't to replace your judgment it's to execute a process you've already defined. For something like customer follow-ups, we'd first document how you decide what matters, how conversations are categorized, what gets tracked, and what triggers a follow-up. Once that's clear, we handle the repetitive execution while keeping everything transparent and easy to audit.
If a task genuinely requires a product decision, it comes back to you. The goal is to remove operational overhead without taking ownership of product thinking.
Out of curiosity, how much time do you think you spend each week managing those follow-ups instead of building?
I don’t track it precisely, but at the current volume it’s probably around one to two hours per week.
The bigger cost isn’t the raw time so much as the context switching and the risk of forgetting a promise or missing the right follow-up window.
That said, I’d probably count myself as not ready to hand it off yet. The trigger would be when the number of conversations increases enough that follow-ups start getting missed, or maintaining the process consistently takes several hours every week.
For your customer validation, that threshold may be more useful than general interest: how much recurring work exists, and what has already started breaking because the founder is handling it manually.
That's a really useful way to think about it.
I was initially measuring interest in the idea itself, but conversations like this are pushing me to focus on operational maturity instead. Someone saying, "That sounds useful," is very different from saying, "Things are starting to fall through the cracks."
Your point about context switching is interesting too. Even if the task only takes an hour or two today, the real cost is the mental overhead of keeping everything in your head. I'll definitely pay closer attention to the point where founders stop asking, "Can I manage this?" and start asking, "How do I stop managing this myself?"
Thanks for sharing your workflow it gives me a much clearer signal of what "ready to buy" actually looks like.
Glad it was useful.
I think that shift from measuring interest to identifying what is already starting to break will make the conversations much more actionable.
“Ready to buy” often shows up in failed workarounds and missed follow-ups before it appears as an explicit request for help.
Good luck with the next round of conversations.
One experience I've had is that good conversations rarely validate an idea—they redefine the decision you're trying to make.
Sometimes you leave with the same product, but for a completely different reason than the one you started with.
The shift you're describing (from pitching to understanding) is the single biggest unlock in validation, and most people never make it. But there's a sharper version of your question hiding underneath, because "did talking change my idea or confirm it" has a trap in both answers.
If talking mostly confirmed what you believed, be suspicious. That's the more dangerous outcome, not the reassuring one. It usually means you asked leading questions ("would you use a tool that does X?") and people were polite. Confirmation is cheap to manufacture and easy to mistake for validation. The conversations that confirm everything are often the ones where you were subtly pitching after all.
If talking changed the idea, that's usually the healthy sign, but only if it changed in a specific way: you discovered the pain was real but you'd misdiagnosed its shape, or you found the person you thought had the problem doesn't, and someone else does, worse. Vague "it evolved" isn't learning. "I thought it was a scheduling problem, it's actually a trust problem between the handoff" is.
For me, the pattern that mattered: talking rarely killed the core problem, but it almost always moved who has it most acutely and what they're currently doing instead. The problem was usually real. My assumption about which specific person felt it enough to pay was usually wrong. That's the thing interviews fix that a pitch never will.
The best diagnostic question I know, since your post is really about better questions: "what did you do last time this happened?" Not "would you use." Past behavior is data, hypothetical future behavior is politeness. If they didn't already hack together a workaround, the pain isn't real enough yet.
What's the assumption your conversations have challenged hardest so far? That's usually where the actual product is hiding.
That's a really helpful distinction. One assumption that's changed for me is who actually feels the pain most. I started thinking founders mainly needed help with the execution itself, but the more conversations I have, the more I see the real bottleneck is often deciding what deserves their attention in the first place. And I like your point about asking what they did last time that feels like a much better test than asking what they think they'd do.
That shift you just described is the whole thing, and it's worth sitting with because it's bigger than a validation finding, it might be your actual product. "Founders don't need help with execution, they need help deciding what deserves attention" is a much sharper problem than execution support, and it's sharper precisely because it's the thing nobody sells well.
Here's why that discovery matters more than it looks. Execution help is crowded, every project tool, VA service, and AI assistant claims to help you do the work faster. But "what should I even be working on" is under-served because it's hard, judgment-heavy, and doesn't fit neatly into a feature. Most tools help founders do things right; almost nothing helps them decide what's worth doing. If your conversations keep surfacing that, you've found a gap that's both real and uncrowded, which is rare.
The thing to pressure-test next: when founders say "I don't know what deserves my attention," dig into what they do right now instead (your own better-question test applies here). Do they make a list and guess? Ask their co-founder? Just work on whatever's loudest? The current bad workaround tells you what you're really replacing, and "deciding what matters" tends to have very hacky, very personal current solutions, which is a strong signal there's room for something better.
That prioritization-over-execution problem is, funnily enough, exactly the space I work in, I'm part of the team building Hivemind, an AI strategy copilot whose whole premise is helping founders decide what matters and pressure-test it, rather than just do more. Might be a useful reference point for what "help them decide" can look like as a product: https://hivemind.myosin.xyz
Either way, follow that thread. "Help founders decide what deserves attention" is a more valuable sentence than "help founders execute," and you arrived at it by asking instead of pitching, which is the whole lesson of your post proving itself.
I appreciate that perspective. One thing I'm trying to separate now is prioritization from execution.
The more founders I speak with, the more I realize they're connected but they're not the same problem. Even if someone knows exactly what deserves their attention, there's often a growing backlog of operational work that still needs to get done.
I'm curious have you found founders usually struggle more with deciding what matters, or with having enough bandwidth to follow through once they've decided?