Last week Redfin asked how they should display their Search Options, offering a $250 prize for the winner proposal. This week, they showed some of the proposals and ask what their users are looking for.
When I saw the first proposal last week I immediately thought the answer didn’t matter much because the question was fundamentally wrong. And it all boils down to be a Database-driven service or a Search Engine service?
First of, let’s be clear there are 100 engineers that understand how to develop database apps very well to each developer that understands search engines. So, when you build a vertical search engine (like Redfin), it’s more likely that you find a typical developer that knows how to store and retrieve large amounts of data from a database.
If you look from a 10,000-feet view, a database and a search engine are one of a kind. Both contain data that will be queried and return results. As you get closer to the ground, you start to see the differences and soon you realize the way they work and what they offer to the end user is significantly different.
A database has your typical rows and columns, it has a sort order, it has filters – which Redfin is calling “search options” – and you pretty much get a deterministic response in a specific sort order (Price? Square feet? Distance?). That is typical. That is what most “vertical search engines” do – by the way, they should be called “vertical databases”. – Go to any Real Estate site that offers a search service and the way they work is pretty much the same.
What they lack is personality, which search engines have. Most Developers (or Program Managers) believe other people think in deterministic terms. Why? Because they ask people what they want and they give a very specific response: A 3-bedroom house, with 2.5 baths in Redmond with a 2 car garage with a price between $600K and $700K. That is pretty specific. That is what the customer said she wants, so we must enable this person to find it, right? Coincidentally, that fits very well with a database driven app. Here is the ‘WHERE’ clause, here is the ‘ORDER BY’, here is the ‘FROM’. Bang! I have a “vertical search engine”.
The fact is that people don’t know what they want. When they say it *must* have 3-bedrooms, they might be flexible into a 2 or 4-bedroom, maybe there is a bonus room that would work out great as the 3rd bedroom. Maybe they requested 3 bedrooms because they thought it would be on their price range. The fundamental problem I am trying to tell is that giving users filter options (or “search options”) is the wrong way.
The solution is to allow users to define their rank formula. This is very different from filtering because you are not eliminating any result; you are just moving the best ones to the top and the less interesting ones to the bottom. How do you present that to the user is the secret sauce. I don’t have an answer for that but I could think of a few ways. Ideally, you let users enter a location and click search and the results will display *all* the houses near that location ranked by the most common criteria (this would be a auto-learning ranking system). Then, you give them knobs to control what was called the “search options”, finally, for the more hands on users you let them order how important each of those options are for them. For example, the number of bedrooms is more important than the square footage of the lot which is more important than the year it was built. I can see the UI in my head and is not that daunting.
In 2005-2006 MSN Search had a neat option to allow you to tweak its ranking formula, by moving some sliders like “fresh content vs. old content”. It got a lot of buzz at the time because it let you play with search results in a way that was not possible before, except if you worked on a Search Engine.
Now Glenn, you don’t have to pay me $250 or anything but lunch and I’ll gladly spill out more details to you. You’ll probably save $235.
I'm the Co-founder & CTO of 
