How to rapidly identify and test the hypothesis behind your product or feature

At Humbleteam we help a lot of companies bring their ideas to life through product design. We work with all kinds of clients, but we particularly love startups. They’re hungry, excited and fun to work with.

A part of the fun is that startups usually don’t have a lot of resources, and they need results fast. They want to know: Does our idea make sense? And can we transform it into a Minimum Viable Product before we run out of money?

Still, even though a startup’s whole existence depends on speed and agility they’re sometimes painfully slow. Instead of focusing on getting a Minimum Viable Product (MVP) out the door as fast as possible, startups often spend too much time and resources on their initial version, with lots of features that don’t necessarily map onto the central hypothesis behind their products.

But what product features should a startup be improving?

After launching more than a hundred digital products in the last few years, Humbleteam has come up with a process that we think brings strategic clarity and speeds up the implementation.

Figuring it out, fast

Step 1: Figure out your hypothesis

What you’re really doing when you’re making an app or a new feature is advancing a hypothesis about the world. For example, if you’re building an app for landlords and tenants, your hypothesis could be this: “We think tenants are more likely to pay their rent on time if we offer them cashback.”

Once you figure out your hypothesis you’re halfway there. And remember, it’s important to be very specific. The narrower and more well defined your hypothesis is, the more clearly you’ll see if it will work in the real world.

Step 2: Find the biggest risk you’ll face

Here are some of the typical risks a startup faces:

• Users won’t see value in your product. For example, you’ve added a crypto trading option to your fintech product, but the majority of your potential users are already committed to services like Coinbase or Revolut.
• It will be hard to acquire users. Your app helps users find doctors in their hometowns, but it turns out most cities have great websites listing local medical professionals.
• The product is hard to execute. Let’s say your app offers users help with moving. But as soon as you reach 100 requests there are no more van drivers in your city, and you’ll have to move quickly to recruit more.
• It’s hard to monetize. Yes, your product is being used, but you’re still losing money.

Step 3: Deal with it!

Did you figure out your biggest risk? Great. Now, deal with it! Think hard until you come up with a product or a product feature that solves your problem. Sometimes it doesn’t take much!

Here’s what Marcel did

How does this three-step process work in real life? Let’s look at an example from our friends at Marcel, an art platform where artists and art lovers from all over the world sell and buy art, build portfolios, like and share, and discuss artwork. It’s a whole community, and Humbleteam has been working with them from the beginning.

Recently, Marcel wanted to extend their core user group of thousands of non-professional artists, and roll out a couple of features that would appeal to professional artists who sell their paintings for thousands of dollars. But how to do it? What could Marcel do to attract the professionals?

The first thing we looked at was the high threshold to entry — a new artist needs to upload all their works with various metadata: titles, descriptions, categories, sizes, location and much more. So we naturally started thinking about how to simplify onboarding — reducing the number of steps required, automating more processes, and options for pulling up data from public sources. But those things are both hard to implement, and we weren’t sure that it would be enough to convince a successful and busy artist.

So Marcel’s team decided to make a Knight’s Move. What if we just manually took an artist’s work and uploaded it to the application, making them a ready-made profile in which they’ll only need to log in with their email and a password? In other words, what if we just did the work for them? Then there wouldn’t be any need to make a lot of costly and complicated changes to the onboarding process.

The moral of the story

The main risk in Marcel’s case was that professional artists wouldn’t want to use the app to sell their art. It would have been tempting to spend a lot of time and resources on optimizing the onboarding process for these special users. But since we figured out a different way to deal with the risk factor, we ended up saving Marcel a lot of time and money.

The goal of any product increment is to test a product hypothesis as quickly as possible. If you only check one hypothesis per month, in a year you’ll only test 12. We think that a small startup should realistically be able to test at least 20 hypotheses a year to maintain a good rate of improvement. And, in our experience if you can’t test a hypothesis in 15 days, you’re probably doing something wrong.