No More Big Bets

“We have this amazing idea. We’re going to apply the model of Tinder to… the jobs market! Tinder for Jobs, it’s a slam dunk!”

It was 2018, and I was pitched a new job. The product pitch was clear: we’re going to build tinder for jobs. It made sense, the company was already a leader in the jobs space, and this would give it another big boost by attempting to reach passive job seekers — people not actively looking for jobs, but… given the right opportunity wouldn’t refuse it.

A golden idea, right?

However, there was some internal pushback in the company. Decision makers were not yet on board to make a big bet like this.

“We’re not convinced this is going to work. There are too many assumptions you’re making. Let’s go lean on this one.”

Either way, I swiped right on the idea, and joined to company. This started my journey applying the lean product approach to developing a product. A technique that has wider applications than just full products, it can be applied to features as well. And probably should be.

The Lean Startup

Already some years before, I had read the book “The Lean Startup”¹ by Eric Ries. In the book he documents his discovery journey towards his first successful product and how we may apply a similar approach as they did.

Ries shows that most start-ups fail. They fail, because they get obsessed with a specific product idea. They convince themselves and their investors that the product is a slam dunk, we just need to build it. They get funding, and then they build and build and build. After half a year, a year, or longer, they launch the product and… crickets. Nobody wants to buy what they’re selling. End of exercise.

Next!

To avoid this problem, Ries argues, a startup ought to focus on learning more than building, for sure initially.

The approach to take is called “validated learning” and in essence it’s simple:

You start = listing your assumptions underlying your product idea. For our particular tinder for jobs concept some examples would be:

1. Passive candidates will create a profile for the service
2. Once matches are found, candidates will check them out
3. Passive candidates will actually interact with the found matches through swiping

Then, you go through this initial set of assumptions and you validate them one by one as follows:

1. Formulate a hypothesis, e.g. for our “tinder for jobs” concept one may be “at least 2% of passive candidates exposed to the service will create a profile.”
2. Validate this hypothesis as quickly and cheaply as possible.

The more creative you can get in validating your hypothesis quickly, the better.

The Making of This Book

Let me share some secret background on how I ended up writing this very book.

While I had already done some thinking and some research and organizational work at the time I announced it, the fact was that when I launched this book’s website², all I did was prepare some mock cover art using a free service (Canva), and hacked together a fancy looking landing page in an hour using an off-the-shelf ConvertKit template.

Effectively, there was no book to buy. All there was, was a fake book cover and a sign-up form.

Why did I do that? To validate a few hypotheses:

1. If this book would exist, X number of people would be interested in buying it.
2. There is sufficient demand for a print edition to further investigate how to prepare those in a cost-effective way
3. There is not sufficient demand for a non-DRM, non-Kindle eBook version to invest in setting up the sales infrastructure for this.
4. People see this as a book as a way to influence their entire team.

I chose not to actually let anybody pay upfront (that would be a bit messy with refunds if I aborted the mission), but the act of getting them to sign up was sufficient signal for for me to proceed.

In addition, the extra ask on the sign-up form was to select the editions (no-DRM ebook, Kindle ebook, print edition, team edition) people would be interested. These informed the other three hypotheses.

Pop-up Driven Development

This is also how we started our journey with our tinder for jobs concept. Jokingly, we internally referred to this approach as “pop-up driven development” because it involved creating a bunch of pop-ups that we’d show to existing users of our main product’s website.

Here’s roughly what we did:

First, we preselected a few thousand users, some of which we knew (based on website behavior) that they may be interested in jobs, some were not.

Then, we showed them a pop-up window once they visited our main product’s website with a message along the lines of:

Hello! We would like to learn more about our users, how would you classify yourself in terms of type of job seeker that you are?

Since we were mostly interested in passive job seekers (seekers not actively looking, but open to the option if the right opportunity came along), based on this selection they would proceed in the process.

Awesome! By the way, we’ve just launched a new product for people just like you that will make it super easy to find a new job, are you interested?

If they’s select “Yes” they’d end up on a landing page that pitched our tinder for jobs concept as if it was already built. On the page was a clear call to action: “Click here to create your profile right now!”

If they’d click that, they would be presented with a simple form to create a profile. Once that form was filled in, we’d thank them and send them back to the main website.

A few days later, they’d get another pop-up (or email):

Hello! Maria from company X checked out your profile and thinks you may be a great fit for a position she’s hiring for, want to have a looksie?

When clicking “Sure!” they’d launch into our Tinder for Jobs UI, looking at the job ad, and swiping it and other job matches left or right.

We hacked this all together in a matter of weeks.

How? By faking most of it. The profile creation form was essentially a Google Form on steroids and would simply feed profile data into a spreadsheet. Once people signed up, we’d proceed to manually find interesting job matches for them and copy and paste these ads back into the spreadsheet. We’d then build a super basic tinder-like UI that would based on some profile ID pull the job ads from that very spreadsheet, of course tracking all actions along the way.

This allowed us to validate all the particular three assumptions listed earlier in a relatively short amount of time. We then did something similar on the employer side. Along the way we learned a lot about our potential customer base and adapted our approach and product concept quite a bit.

We learned a lot.

The results ultimately lead to creating a lot more buy-in from management to spend more resources on building the product for real.

No more big bets.

Validate all the things

As alluded to in the beginning, this approach is not just relevant to startups or new products, it can be applied to features as well. I have found it to be a great way to avoid big feature bets just the same. In fact, investing in infrastructure for experimentation is likely to pay off big time. If you’ve ever been exposed to how large companies like Facebook and Google work: they run hundreds if not thousands of experiments simultaneously, all trying out new features, and checking what their actual effects are.

An additional reason to apply this same approach to features is that whereas startups tend to just disappear when the fail, failed features do not. They tend to stick around, even though they did not really work. We never bother to remove them, because, perhaps, we’re afraid to upset the few users that do use them. And as a result, we have to drag them along. They become product debt.

Perhaps the application of validated learning goes even beyond our daily work. Perhaps we can apply it in our private life as well? Should we organize a “Harry Potter” themed dinner party? How will we decide? Well — let’s pick a date, create a sign-up form and see how many people sign up?