“You are such an idiot!” That’s what my wife’s eyes were saying while we were sitting in my friend’s living room after I had just commented on a piece of art on their mantle. You see, I made an assumption about that piece of art that put me in a really awkward position. Let me set this up for you.
We were invited over for a cookout at my friend’s and while we were waiting for the burgers to finish cooking, we were all sitting around the living room doing some small talk when a lull in the conversation happened. I noticed the new piece of art earlier and decided this lull would be a good time to bring it up, so I said:
“Oh, that’s pretty, did your daughter paint that?”
Did you notice my assumption? I assumed their 11-year-old daughter had painted it! Unfortunately, my assumption was incorrect, and my friend’s wife answered with:
“No, I painted it. I know it’s not very good.”
Do you see what happens when you assume? I offended my friend, embarrassed myself and my wife, and put a real damper on the cookout. Don’t worry, we’re still friends, but man, that was awkward.
The thing is, this type of scenario happens all the time when working in the world of digital product too, but instead of paying for it in awkwardness, you pay for it in missed revenue or customer value. We are presented with a lot of ideas, hopefully to solve real problems. The thing about ideas, though, is that they’re filled with assumptions. Let me give you an example.
Let's say you’re working on a new feature for a website you're responsible for and you need to let your users know it's coming. Your first thought would be, Let's send an email letting people know about this new feature. This would be a logical idea. Let's take a look at some assumptions built into this solution:
- Most of your customers are still subscribed to receive emails from you.
- Your customers are interested and will take the time to read the email.
- Your customers’ email providers haven’t flagged your company as spam.
- The subject line will be compelling enough to get your customers to open it.
- Adding an image will increase open rates.
- Keeping it all text will increase open rates.
See? These are all assumptions that could be baked into the solution of sending an email. The question is, so what?
Well, I'm glad you asked. The best thing about taking the time to identify the assumptions built into any potential solution, is it gives you the opportunity to prove out the value of the solution without building the entire thing. Just identify the assumptions that if false would make the entire solution fail, then go validate those.
Here, let me explain using the examples above.
Now, depending on where you work, an email might not be a big deal, but I've worked at places where getting an email sent to customers was like trying to turn the Titanic. It happened, but it took a long time. So how would you go about proving out the value? You'd validate or invalidate the assumptions. Here's how that could look:
- Assumption: Most of your customers are still subscribed to receive emails from you.Validation step: Check your subscribe list count and see if it's even close to your total user count. If it's not, you might have a problem.
- Assumption: Your customers are interested and will take the time to read the email.Validation step: On your next few customer interviews, ask about their interest in this feature, and then have them describe it to you. Then use the same words in your email to ensure maximum understanding and connection.
- Assumption: Your customers’ email providers haven't flagged your company as spam.Validation step: Check the open rates on previous emails your company has sent. Are they being opened? Even after resends? If not, there's a good chance you're being blocked.
- Assumption: The subject line will be compelling enough to get your customers to open it.Validation step: Once again, use customer interviews to validate whether your subject line is going to catch attention.
- Assumption: Adding an image will increase open rates.Validation step: How did previous emails perform when you added pictures?
- Assumption: Keeping it all text will increase open rates.Validation step: How did previous emails with just text perform?
Most of these assumptions can be validated pretty quickly. And the great news is, this works with more than email. It also works with full-blown features. Let's say, for example, you worked on an app that helped people book last-minute hotels during a trip. You've heard from a few users that they are generally looking for last-minute hotels while driving and need a way to get the information without taking their eyes off of the road. So, your idea is to integrate a virtual assistant that allows your user to ask for help finding a place to stay for the night. So let's look at some assumptions:
- Your user is on a smartphone with virtual assistant capabilities.
- Your user is somewhere with a strong enough internet connection that a search can be completed.
- Your user knows that they can use their voice to start a search.
- Your user knows the closest town or the town they want to find a hotel in.
- Your user has a payment card on file that will allow them to reserve a hotel without needing to enter it manually.
- Your user is comfortable making a reservation without seeing pictures or reading reviews.
There are some pretty big assumptions here. What are some steps you think you could take to validate these assumptions? Go ahead, pick one or two and try it right now.
The great thing about listing and then validating the riskiest assumptions is that you don't have to build the feature yet. You just need enough information to validate your assumptions are true to give you and your team more confidence in the solution that you’re working on. If, however, you prove that some of the biggest assumptions are false, it allows you to move on to another solution quickly.
So, here’s my challenge to you. What are you working on right now? What assumptions are baked into it that you haven’t validated yet? What are the riskiest assumptions that if proved false would cause the whole thing to not work? Write these down, then get with your team and come up with several ideas on how you could validate those assumptions true or false. Don’t be the person who builds solutions based on a bunch of unvalidated assumptions.
