Yesterday ...
A founder we're working with saw his development roadmap stretching out over the next couple of months. And this ain't his first rodeo. So he knows that even though he's on the right track with his idea, it would still be very easy to build something that doesn't work for his market.
So he asked us, "how can we test this idea right now? I don't want to risk wasting the next 8 weeks".
We rolled up our sleeves, stepped way away from the designs and the to-dos, and sketched a very quick Multiverse Map, zooming into the specific part of the service that had proven tricky to test.
It showed the following behaviours. (The details have been redacted, but the principle of "select and adjust items π see feedback" is common.)
"For us to succeed, a customer needs to see this set of data, choose some items to put into a group, see some calculations based on the items they chose, adjust the weighting of the items, see updated calculations, then tune the selection and weighting of the items in the group based on updates to the calculations. When they're satisfied, they move into this other sequence of behaviours, where a system will take action based on their choices."
Once we had agreed on the map above, we could use it to figure out how to create just enough stuff to simulate the full experience for one customer at a time.
Seeking the Good Janky
We started with an old favourite trick. Need to show a customer a bunch of real data? Use a spreadsheet.
We discussed how you might copy-paste rows to simulate making a group of items, and then use formulae and charts to simulate the calculations. We wondered whether a potential customer could even make a spreadsheet asynchronously and then send it to us. But we also had worries: might this be a little too easy to break, a little too fiddly to operate? And getting the calculations to work reliably might take us too long.
Then someone suggested Airtable. Like a spreadsheet on steroids. We could upload the data as a csv file and then use Airtable's built-in functionality to simulate making groups and doing calculations ...
And at the same time, someone else had opened up Lovable and started vibe coding. In a few minutes, they'd sucked in the real data we'd be using and outputted a first stab at a prototype. It would be buggy and janky. It would be only partially complete and not really look like our final service. But for the purposes of testing perceptions and behaviours with one customer at a time to find out where we were wrong, that's all perfectly fine.
(We could've chosen any of the above routes β or other alternatives. More on that later.)
If, after testing the janky prototype, we realised we were still far off a workable idea ... well, no worries β we'd only spent a few hours on it. And if we were pretty close? We'd feel justifiably confident to have the devs go ahead and build the just-right-enough service properly.
Why bother with all this?
Because we know we're wrong about at least some of the details about how a real customer will find, choose, use and get value from this service we're building.
And we know that building the thing for real β even as the most M of MVPs β is a slow and expensive way to find out where we're wrong. And it puts us in a big, smelly sunk cost hole that we may fail to dig ourselves out of.
We know that it's almost always quicker and more effective to deliver the service for real, mostly by hand, for one person, today.
Where this can get tricky for teams is in delivering the parts that aren't easy to simulate by hand. And that's when teams often hit a wall and default to building it properly, or creating pretty mockups that can't test the behaviours they need to understand.
But now, hey: those tricky bits we can vibe-code, flinging together just enough throwaway code to enable our one customer to manipulate some real data.
The Catch-22 that actually isn't
You probably know this simple story that seems to stymie people who want to get funding for an idea.
Whether you're a founder or an intrapreneur, whether you need funding in terms of cold hard VC cash or departmental budget, headcount and other internal resources.
It goes like this:
You need proof to get funding so you can build your idea, yet at the same time, you need funding to build your idea so you can get proof.
Or do you?
It might feel like your limbs are tied up with twenty metres of battle rope, but there is a way to get proof without building.
There's a lot of lore about what it takes to get funded, but it really comes down to two things:
Vision and proof.
Vision, you have in spades
"This thing could be huge. No, bigger than huge! It'll solve a problem for the world and get you a hefty return on whatever you invest (thus also solving your problem of not having even more money than now)."
And that's where a lot of decks kinda peter out. Founders pitching to investors or a leader's deck within an organisation petitioning for resource and precious space on the roadmap β only telling half the story.
It's great if your vision gets your potential funder juiced. The problem is, anyone can tell a compelling tale of how great things will be one day, once their thing is up and running.
Don't get us wrong: your vision is amazing. You're amazing, probably. Maybe you really can make it happen. But the odds are not in your favour. Most startups fail to take off. Most ideas on roadmaps fail to deliver any outcomes.
So you also need proof
Not just proof of addressable market size, the competitive landscape and so on. Unpopular opinion: that's the easy bit.
No, you need proof that you're off the starting blocks. Proof that you've taken action and the world has responded. Proof that you've sidestepped the big four reasons for failure.
A new idea always fails in one of only four ways. People don't find it, don't choose it, don't use it, and/or don't get the value from it.
And most new ideas fresh out of a founder's imagination probably fail at all four at once. The glow from the vision of how good the idea could be tends to blind people ... tends to make the founder and their team feel like the idea is close enough that they should build it β then they can tweak the tiny details later. This never works.
These founders treat the four ways that ideas fail as problems that can be solved by throwing features and money and people at them. But they're not problems to solve, they're constraints to work with. When you treat them as the problem, all you do is kick the real problem down the road.
And the real problem to solve isn't making all those people you don't control do what you want. The real problem is *awkward cough* erm ... you.
Every founder has to go through their "oh shit, I was completely wrong about everything" moment. It's like a rite of passage. When they look back on two wasted years that ended in layoffs, bad press, bitterness and broken bridges, and puzzle to themselves: what on earth went wrong?
And so successful second-time (and nth-time) founders don't start by building. They start by seeing if they can help just one person find their thing, choose their thing, use their thing and get value from their thing.
Do this sort of vibe coding β we double-dare you with bells on
Vibe coding has the potential to enable every team to level up in probe-based learning and figure out the right things to deliver faster than ever.
But most teams will use it (and continue to use it) to deliver more junk that nobody needs, faster than ever.
We reserve the word "should" for magnificently special occasions. You know, the ones with bunting and balloons. Today is one of those days: everyone should realise that now it's cheaper, faster and safer than ever to find out how you're wrong, with the help of vibe coding. Everyone should realise that by approaching building that way, you become antifragile β you kill bad and only OK ideas faster, making room for great ideas to emerge and flourish.
Our bet? Most teams and founders won't take that step.
They'll still resist putting their work in front of customers. They'll still try to guess what's right based on debates, opinions, assumptions, and interpretations of past data (which can only show you what IS, not predict what IF).
They will still try to get funding for the big idea based on hope.
What's getting in the way?
We'll dive deeper into why another time, but as a starter for ten:
Most teams simply haven't seen this kind of thing done, so it feels weird. They're used to a way of working which starts with conversations and feature lists and then moves onto screen designs which are handed off to developers to build. The approach we described above is much more collaborative, exploratory and action-oriented than most folks are used to.
Another layer is simply that it can be uncomfortable finding out that you're wrong. In that moment itself, most people wouldn't put the experience in their top 10 of joyous life events. (Including us.)
Another layer is that even when teams become ready to learn and explore, they often get lost in the "has to look like the final product" trap. The shift that's needed is from "let's make a complete flat prototype that looks like our app" to "let's cobble together ugly bits and bobs that enable our customers to follow the same thought process that our app will enable."
Which brings us to the constraints and incentives in many companies, which tend to discourage the kind of scrappy rigour we specialise in. We know. Those constraints are very real and often very difficult to shift.
The path to proof is FREEDOM
All in all, it's generally not easy to be fast and effective. (That challenge is exactly what jabs us out of bed in the morning. As friend of The Reach Ben Sauer once put it: "you make it feel safe to be usefully wrong".)
But the payoff? It's worth it. By delivering the service to one customer today, mostly by hand, with a smattering of vibe code, you'll take a journey though your myriad wrongnesses and come out on the other side, buzzing.
As we hinted at earlier, in our example above, we could have used any of the options to test and learn with β the spreadsheet, the Airtable, the vibe coded prototype, or something else entirely β because we were grounded in the behaviours we needed to learn about instead of skidding around on surface polish. The trick: choose whichever one energises your team most. Because whichever you choose, it'll be imperfect in some ways, and whichever you choose, it will enable you to learn.
This is liberating! Suddenly a spreadsheet is a valid test for a complex dashboard. A conversation is a valid test for a chatbot. A manual process is a valid test for a multi-step automation.
Then, once you can show that one real customer found it, chose it, used it, and got value from it, and then another did, and then another ... even though it was a bit of a cobbled together mess ... Well then you're not pitching a hopeful vision. You're pitching a proven pattern that just needs resources to replicate and polish. In other words, the kind of thing people will queue up to fund.
We're not saying any of this is easy. But it sure beats building something nobody wants for years on end.
Tom & Corissa x
β