Why curious founders beat bold ones - hypothesis vs dogma
In the messy early stages of building a startup, it’s easy for founders to cling to strong beliefs. It’s even necessary. That’s the drive and motivation that made you survive, that made you doggedly wake up and push to build and solve the same problem every day, even when it was just you alone. But what starts as vision can harden into dogma – and that’s where the danger begins.
At Pitchwits, we encourage founders to adopt a mindset of hypothesis, not certainty: treating your business as an experiment, not a mission to be defended at all costs. Let’s discuss why hypotheses are not a sign of indecision, but a signal of intellectual honesty and long-term adaptability.
The trap of early certainty
Unless you have tested the assumptions in your business model, your business plan is just creative writing. –Steve Blank
The startup world glorifies confident, visionary founders. But too much conviction – at any stage – can lock you into flawed assumptions. The real danger is that you start defending your ideas instead of testing them.
Dogma is untested belief, often rooted in ego or sunk cost. “This is what customers want.” Conviction, rigidity, defensiveness.
Hypothesis is a testable, falsifiable assumption, rooted in curiosity and learning. “I believe this is what customers want, and I’ll run an appropriate test to find out.” Inquisitiveness, evidence, falsifiability.
Why do hypotheses win (especially early on)?
Encouraging experimentation leads to faster learning cycles.
Robust hypothesis-testing practices makes your team feel safer contributing new ideas and satisfied when they do or don’t go ahead
Challenging your every assumption as habit keeps you open to pivoting when the market speaks.
Hypotheses reduce your and your team’s emotional attachment to specific features, go-to-market strategies or brand narratives
You don’t need to be an infallible founder. You need to be relentless about learning.
Instagram started as Burbn, a location check-in app. The hypothesis was that users want social check-ins. Founders Kevin Systrom and Mike Krieger observed their users and pivoted when data showed that photo-sharing had 10x more engagement.
Slack started as Tiny Speck, a gaming company. By recognising the potential use of their internal tools (originally just designed to streamline workflows), they hypothesised that there was a market for a robust and user-friendly team communication platform.
Quibi stuck with the dogma that short-form, premium mobile video was a category-defining idea. They ignored market signals and feedback, and folded after $1.75bn in funding.
Building a hypothesis-driven culture
1. Frame all major ideas as problem/solution tests
Every idea (even small ones) involves a problem (We need to solve Problem Y) and a solution (We’re launching Feature X).
Many founders we work with at Pitchwits are already fairly disciplined at testing solutions: “We’re testing to see if Feature X solves Problem Y” instead of “We’re launching Feature X” (but check out our article coming June 2025 on How to break your tech startup’s cargo cult trap). As your startup picks up pace, validating problems is the part usually left behind. But oftentimes the assumption is that Problem Y represents a real opportunity, or a meaningful enough pain point to solve. Solutions consume resources.
Example: Your sales team reports that some prospects drop off because your app doesn’t have a native calendar integration. The immediate reaction might be: “We need to build a calendar integration to win more deals.”
But before committing engineering time, you ask: “Is lack of a calendar integration truly a meaningful problem for a significant number of customers?”
First, you need to define the language objectively. What number of customers do you count as significant and why? What data points would signify a meaningful problem?
Once you’ve settled on your definitions, to test the hypothesis, you:
Manually offer a workaround (e.g. sending users a calendar link export or Zapier connection)
Ask sales to track how many deals explicitly cite calendar integration as a dealbreaker
Run a lightweight landing page experiment showcasing the feature and measure interest clicks or sign-ups
Survey existing users to see how often they need calendar sync and how critical it is to their workflow
After two weeks, you learn that only a handful of prospects actually need calendar sync, and most active users don’t mention or miss it. The few who do are power users from a niche segment with lower retention.
Result: You don’t build the integration – because the problem isn’t as widespread or painful as it initially seemed.
2. Measure success in outcomes, not outputs
Success comes from validating learning, not shipping features.
It’s natural as a founder to identify business progress through tangible milestones – things out there in the world produced by your company, that can be shown in a sales demo, that can be talked about at networking events, that are ticked off your to-do list instead of imagined.
And in startup teams, creation of a focused solution in a rapidly-changing, resource-tight environment is an achievement. We tend to chase those dopamine hits. The follow-up process – judging the impact of the focused solution – can be perceived as boring, exhausting, and even focusing on the negative, if something isn’t working as well as originally hoped but is still there, live, kicking, and the resources already spent.
At Pitchwits, we believe one of the strongest traits of successful founders is the ability to properly define success. Our mantra is outcomes over outputs.
Example: your product team ships a slick, bug-free, new feature – a customisable dashboard – on time. That’s a great output. But the outcome you care about is whether it helps users engage more deeply, retain longer, or extract more value from your product, and it is tested after the output.
In six months time:
Did weekly active usage increase over time?
Are users creating more custom views of the dashboard over time?
Has churn decreased for users who use the dashboard?
Did support tickets about dashboard limitations drop?
If these metrics don’t show that the dashboard solved a problem, call it as you see it. Maybe only 5% of users tried the new dashboard, and out of those, most reverted to the default.
How do you communicate failure? It’s six months later, and the product roadmap has moved beyond the dashboard. What’s the point of dwelling on the negative and showing your product team the results? It won’t help morale to tell them the work they did six months ago wasn’t valuable. The temptation to forget and move on is real.
Here’s why you should confront it.
What you learned is that shipping the feature wasn’t enough – you didn’t yet validate learning. Maybe the original need wasn’t there, the feature was poorly communicated, or it solved the wrong problem.
Those conversations (as difficult as they can sometimes be) are the ones that can strengthen your team, your product roadmap, and your idea generation processes company-wide. This leads to our next point…
3. Be happy to be wrong, and be obvious about it
In a startup, founder praise carries outsized weight. It shapes morale, signals what’s valued, and quietly defines the cultural tone of the business. When used deliberately, it becomes a powerful tool to reinforce a learning-driven, hypothesis-based mindset.
Early on, many founders fall into a praise pattern that feels natural – but isn’t sustainable:
Praising correct guesses
This is the default in most scrappy teams. A risky bet pays off, and it’s celebrated as validation of instincts or luck. That rush of relief becomes a cultural loop: trust your gut, build fast, celebrate wins. But as the stakes grow, luck runs out and instinct starts to falter. If the culture only rewards being right, nobody wants to be seen testing bold hypotheses, or being wrong.
Praising insights gained
A more resilient model is to celebrate what was learned, not whether the outcome matched expectations. Good hypotheses teach you something, even (especially?) when they fail. Praising the insight reframes failure as progress. This isn't toxic positivity – it’s about reinforcing intellectual honesty and curiosity.
Whether you’re a solo founder or leading a team, now is the time to reflect:
How often are you praising outputs vs learnings?
How many of your early “wins” were luck-based – and did you recognise them as such?
Do you make it safe (and visible) to be wrong?
Modelling this matters. When leaders openly acknowledge flawed assumptions and highlight the value of what was learned, it gives everyone permission to experiment – and fail – without fear. That’s how a culture of hypothesis-building takes root and scales.
If you’re leading a growing team and trying to reform a culture that’s too focused on “being right”, start by revisiting your own leadership habits. What do you praise about yourself? What do you punish? What do you downplay? The answers shape whether your startup stays agile or ossifies under the weight of its early assumptions.
Craft the right culture for your business with Pitchwits
