The Interface Is the Product
On Minimum Viable Products and worrying about technical debt…
Ask Bob is my own search engine. It is better than Google (for some users).
I wrote it in an hour.
You enter a question, and if it is a question where I have more expertise than Google then you get my local, expert opinion.
Otherwise it forwards your query to Google for the easy answers.
If you lunch in Bellingham, my search site is superior, and for any other question it is equal to Google, because it is Google.
Ask Bob is a complete product. It looks clean (thanks, Twitter Bootstrap!). It delivers on its promise. It is functionally complete. It delivers my special expertise on several topics plus everything Google can.
But what about the technical debt? Well…
The code is pretty lame. It’s if/else statements. It clearly should be a dictionary object loaded from JSON. But if we are going to deliver my expertise on hundreds of topics, we might need a database. And if we’re going to deliver my expertise on even more, it might not be enough to have keyword/answer pairs; we might want to run NLP queries against the full-text of all my writing over the years.
And to keep it fresh, it should text me any questions it can’t answer, so that I can reply with a specific, current answer, which is then cached for future use.
And then, we should use deep learning, which could read everything I write (and transcribe everything I say) and then learn to answer in my voice, from facts I know and opinions I have expressed…
And why call it Ask Bob? There are smarter people around… let’s have it support asking other people. We should make Ask Bob a more generic “Ask Experts!” site… we are going to need some thoughtful architecture. We’ll need a robust database that supports multiple shards and can spin instances up and down as required. We’ll need a good API, and an admin panel where we can add subject-matter experts and their expertise… we should schedule some planning meetings…
But to the user, this is all behind-the-scenes detail.
To the user, the interface IS the product. And it’s done.
To the user, my silly little hack is ‘complete’ in the same way Google was ‘complete’ in 1995. How complete? Let’s take a look:
Google Frontend 1995 vs Google Frontend 2017
In 20+ years the Google UI has changed by removing ‘BETA’ and the instruction text. Google was ‘complete’ in 1995.
What about the back-end? Well, in 1995 Google’s entire infrastructure fit on a desk.
Now you can ride bicycles through massive data centers around the world.
Over two decades they’ve done quite a bit of refactoring and paid down a lot of technical debt…but the core user experience today is the same as it was in 1995, when the whole thing ran on top of a desk.
To the user, this automated chess opponent:
And this automated chess opponent:
Are the same thing… only the first looks more interesting and fun to play.
The user didn’t care that the first had high operation costs, lacked features, and represented significant technical debt. It took two hundred years to pay down that technical debt and deliver full automation. But to the user, it was a machine that played chess, and it worked in 1770. (And it made money.)
To the user, the interface is the product. The interface is what they can see. The interface is what they can touch. The interface is what returns information to them. Most users don’t know and don’t care how it works. They care about what it does.
We are free to change the how at any time.
If we start with delighting the user, almost any working implementation can get us into the market and building our customer base while we grow and improve the product behind the scenes.
