“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’s 2018, and I’m being pitched a new job. The product pitch is clear: we’re going to revolutionize the job market tinder-style. It makes sense, the company is 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 one.
A golden idea, right?
However, there is some internal pushback in the company. Decision makers are 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.”
But I was sold, I swiped right on the idea, and joined the company. Or left, whatever the appropriate direction is — I’ve never used Tinder.
This started my journey applying the lean product approach to developing a product. A technique that has wider applications than just full products and start-ups, it can be applied to features as well. And probably should be.
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.
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 with listing your assumptions underlying your product idea. For our particular tinder for jobs concept some examples would be:
- Passive candidates will create a profile for the service.
- Once matches are found, candidates will check them out.
- 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:
- Formulate a hypothesis, e.g. for our Tinder concept one may be “at least 2% of passive candidates exposed to the service will create a profile.”
- Validate this hypothesis as quickly and cheaply as possible.
The more creative you can get in validating your hypothesis quickly, the better.
Pop-up Driven Development
Jokingly, we internally referred to our 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 modal 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 opportunities), based on this selection, only they would proceed in the process.
Awesome! By the way, we’ve just launched a new product for people just like you. This product will make it super easy and fun to find a new job, are you interested?
If they’d select “Yes” they’d end up on a landing page that pitched our Tinder for Jobs application. 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:
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 start fervently swiping left and right.
We hacked this all together in a matter of weeks.
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 flashy looking 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 three assumptions listed earlier in a relatively short amount of time. No fancy machine learning required, not really even a real backend. 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.
The results were promising enough to get solid buy-in from management to spend more resources on building the product for real.
No more big bets.
Validate all the features
This approach can be applied to features as well. I have found it to be a great way to avoid big feature bets. If you’ve ever been exposed to how large companies like Facebook and Google work: they run hundreds if not thousands of such experiments simultaneously, all trying out new features, and checking what their actual effects are.
An important reason to apply this approach to features is that whereas startups tend to just disappear when the fail, failed features do not. They stick around, even though they did not really work. Once built, you never bother to remove them, because, perhaps, you’re afraid to upset the few users that do use them. And as a result, you drag them along. For eternity.
The key is to figure out if you’re on the right track as quickly as possible, with as little commitment and effort as possible. Even if you have to fake it ‘till you make it.
No more big gambles.
No more big bets.