So you’ve got a great business idea and can’t wait to build it, fail, and then build again, right?
Wrong.
Tempting as it may sound, building software shouldn’t be the first thing you do when you have a business idea.
That’s because it’s often the least risky part of the process, says David J. Bland, co-author of Testing Business Ideas with Alex Osterwalder.
The bigger risk? Whether you’re actually solving a problem people are willing to pay for, says Bland.
“You can spend a lot of money building something and releasing it without it solving a real need at all and flop,” says Bland. “Or you can just run a series of experiments along the way and understand if you’re on the right track before you place a big bet like that.”
New businesses are in a rush to build but need to slow down and learn first whether their idea is solving the right problem and whether anyone will pay for it. That’s the bigger business risk, says Bland.
To do that, run experiments. Don’t know where to start? Testing Business Ideas lists 44 of them with a rundown on cost and the strength of evidence each experiment provides.
The book is the manual you didn’t know you needed, says Zeitspace partner Jeff Fedor.
He has seen companies new and old get swept up in the excitement of building a new product or get wrapped up in trying to solve a problem in the dark.
“Product strategy is both harder work and less glamorous than it sounds, so it’s easy to just default to tactical work because it feels like you’re doing something even if you’re not sure you’re doing the right thing,” says Fedor.
“It’s emotionally hard and scary to test out your idea. What if someone doesn’t love your baby?”
Even worse, what if you bet $1-million that everyone will love your product without testing your idea and later find out it just won’t fly?
That’s what Bland wants new companies to avoid and that’s why he partnered with Osterwalder to write Testing Business Ideas.
They found that businesses kept leaning on the same experiments — surveys, landing pages, and customer interviews — but didn’t really know what other experiments they could run. Bland kept giving the same advice and decided to turn that advice into a book that became a “field guide” for companies looking to cut down their risk.
“I’ve worked on a product where we manually delivered something to a customer and then looked at that whole process and said, ‘You know what? If we built an app, it should do x, y, and z — not because we thought it would be cool, but because this is what our customers value in that experience,’ ” says Bland.
“So you can really do some interesting things in informing the product design by manually doing things and finding creative ways to generate evidence versus, ‘Wouldn’t it be cool if?’ ”
Test, learn, and act
Testing, like product design, is iterative: test, learn, tweak, act. That’s the cycle sweet spot, says Bland. Ideally, there shouldn’t be more than a week between learning and acting on it, he says.
“It doesn’t have to be a huge bet on learning, but at least it makes it into the next experiment or it makes it into a small feature or there’s something that you can do with it. Because if that takes months, the market changes and what you’ve learned may become stale and no longer valid,” he says.
But too often companies get stuck in the learning cycle. They make space to run experiments, but don’t make that same space to analyze the results and act on them, says Bland. But learning, he points out, has an expiration date.
Managing risk
The book is really meant as a way to help businesses cut down their business risks, says Fedor, who has used parts of the book, such as the assumptions mapping exercise, with Zeitspace clients.
Fedor says any time you’re developing new features usually there are one or two things going on: You’ve read the books that say fail fast so want to build, fail, and try again, or you have a problem and you want to fix it.
“Those are two high risk scenarios but if you spend a week doing testing, you can significantly decrease your risk,” says Fedor.
But that’s not necessarily everyone’s happy place, he admits.
“I know myself as a founder when things got tough all I wanted was to go write code,” says Fedor. “The risk of doing the hard work is to find out nobody cares.”
Run experiments to move forward
You may be worried about bypassing the build fast, fail fast model for one that feels slower, but consider this: Testing your business idea could save you from spending big dollars on features that someone isn’t willing to pay for.
And you’re not really slowing down the process, points out Bland. The only thing you’re really slowing down is the rush to build.
Running experiments will also help move you forward, says Fedor, whether or not you validate your business idea.
Bland says too often he’s seen talent wasted on business ideas that no one cares about.
“All of us that evangelize this stuff have been burned in the past by building stuff that no one cares about over and over and over again. It’s almost like we ended up doing these things because we were just so frustrated by that loss of opportunity and wasting people’s talent,” says Bland.
“There’s a trend in everybody who’s really passionate about this and has personally experienced it in their career so we thought, ‘How do we address this problem?’ We can’t keep building products that way.”
Three ways to test your business idea:
1. Map your assumptions. Make the time to talk as a team about risk. "I would really love for people to have a conversation about where their risk is together versus putting their heads down and just building like this is all fact," says Bland.
2. Test before building. How do you ensure you’re solving a meaningful problem that people are willing to pay for? Take the time to test your idea “before you worry about what all the features of everything looks like,” says Bland.
3. Test, learn, act, then test again. Don’t just set aside time for testing, carve out time to analyze what you learned, apply that to the next experiment, and test again. “Learning has an expiration date,” says Bland.
