I sat listening as the team debated about what to do next. They had originally built software to handle complex workflows in the executive recruiting space, and now they wanted to beta test it with a customer in the healthcare market. The question was what modifications should be made to the software so the beta customer could use it right away.
“I think we can change some fields to be more healthcare-focused, add data to a few of the pages, and we’re good to go,” said the founder.
“That will probably only take us a few days to do,” replied one of the engineers.
The conversation continued for a few minutes, and everyone agreed that the engineering team should start work right away. Everyone except me.
“What if you’re wrong?” I asked.
The room was silent for a moment.
“Wrong about what?” the founder asked.
“It sounds like you’re making a few assumptions,” I replied. “One, that the changes you’ve discussed in the past ten minutes are clear to the team and are simple enough to make in a few days. And two, that these changes to software designed for one market will make it useful for customers in a different market.”
I paused.
“If you’re wrong about either, the time and resources you spend on making the changes will potentially be wasted.”
The engineer knitted his brows and spoke. “The changes we’re talking about should only take a few days.”
“Ok.” I replied, “Suppose you’re correct. Suppose you clearly understand the changes, and suppose they will only take a few days. What do we do if the customer looks at the software and says, ‘I don’t understand. We can’t use this because it doesn’t match our process.’?”
“Then we’ll go back and make more changes,” said the engineer. He was beginning to get annoyed.
“How much of this back-and-forth do you think it will take to get the software to where the customer can use it in beta? Do you think you’ll have to make two rounds of changes? Five? Twenty?” I asked. The engineer confessed he didn’t know.
“So we’re talking about an unknown amount of engineering work. That’s risky and potentially expensive. Instead, we should learn as much as possible about the customer’s process so we can build the right thing and minimize rework.”
I smiled. “I’m an engineer by trade, but I think we should do as little development as possible. It’s expensive as hell.”
“How do we do that?” the founder asked.
“If we have our designer create mockups of the software,” I replied, “we should be able to get something in front of the customer by later today/early tomorrow, make changes based on feedback within hours, and repeat until we are much more certain what we should build. This way we’re learning while maximizing speed and minimizing spend.“
Assumptions like “We know enough to start development right away,” are all too common. Most of us place bets on risky assumptions that end up costing us big, and much of the time we don’t even realize we’re gambling.
Hone your ability to detect assumptions. If you’re not used to identifying, questioning, and validating your own assumptions, start small by developing the habit of examining both your thinking and that of your team.
Are you about to commit resources because you believe that customers will scramble over each other to pay for your solution? Assumption. Are you drafting a budget based on a belief that you can hire 10 high-quality engineers over the next 8 weeks? Another assumption. Are you sure that your software’s interface will be used as intended? Yep, another assumption.
In situations where both the stakes and complexity are high, the only thing you can truly be certain of is that you’re wrong about something. Assume that you have at least one invalid assumption somewhere in your plan, and if you don’t identify it, your entire project could come crashing down. Step back and reexamine your thinking: where do your biggest assumptions lie?
When evaluating assumptions, consider two criteria:
- How costly is the assumption?
- What is your level of certainty?
For (1), ask how much being wrong will cost you. If you believe that greeting your users with a “Hi Nathan!” message is a better experience than “Hello Nathan!”, it’s probably not going to be a big deal if you are incorrect. It likely will have little impact on the user experience and it’s easy to change.
However, let’s suppose you believe that you can get a significant number of customers to buy into a new product tier that will take $750K and 6 months to build, where $750K is a considerable investment for your company. If you’re wrong, that’s going to be a painful pill to swallow. Congrats, you’ve identified a very costly assumption!
For (2), estimate the probability of being right. If you know the terrain well, have a ton of information about the decision, and there is a significant amount of evidence that what you’re suggesting is true, then you can probably feel pretty comfortable that your assumption is correct. Your level of certainty is high.
On the other hand, if you’re new in the space, don’t know the customers well, or have more questions than concrete answers, then your level of certainty is low.
Big decisions or projects usually rest on many assumptions. Since it’s not practical to validate every single assumption before making a decision, we can use the two criteria above to identify the riskiest, high-cost, low-certainty assumptions.
To test assumptions, get creative. We’ve already given the example above: instead of taking weeks or months to build software and put it in front of customers, use design mockups and high-fidelity, clickable prototypes to learn in a matter of hours or days whether your product will be used in the way you think.
If you’re assuming that customers will buy a product, can you test your assumption by getting them to pay before you incur the expense of making it (the classic MVP use case?)
If you’re assuming that users will want to share your product with others via a slick sharing mechanism, can you validate that assumption by getting them to share via some less sophisticated method that’s easier to test?
How can you test your assumptions faster? How can you confirm that you’re on the right track as quickly as possible?
Stop guessing. Get in the habit of sniffing out your assumptions, identifying the riskiest ones, and testing them quickly and cheaply to give you a fighting chance at success.