Why technology matters less than engineers think

We engineers, and technically inclined people generally, are convinced that the most important part of any product is its technology and engineering. That is completely backward. Technology is among the less important ingredients in any product. I learned this firsthand with HotCar.io. With some engineering pride I will add that I am pleased our engine searches at lightning speed, surfaces the best deals and filters out fraudulent listings. That did not help us build a successful product. A successful product has a market, demand and, most importantly, users willing to pay for it. Technology is a means to an end. This post is about one of the lessons I learned.

It was a great idea and the path looked straightforward. We had lots of data on used cars, and surely plenty of people would jump at the chance to use it to get a good deal. All we needed was to put the data in context, preferably through analysis. Everyone wants to know whether the car is cheaper in neighboring Bavaria or what the used car they buy will be worth in a year. Then there are users who do not care about any of that because their analytical skills end at opening Excel. Are you a mother of two looking for a new car? You'll want a bigger boot, something safe, and low running and service costs. Fine. Come to our site and we will show you the best listings for your preferences.

Did you know it is common for dealers to list cars that do not exist to get your attention, then sell you a heap at the first opportunity? That is before you even get to odometer rollbacks. Tell your friends about all this and they will say that it would be an excellent service they would definitely use.

An aside. Never, and I mean never, under any circumstances, take a friend's word for it when they say your startup idea is brilliant. Friends rarely give it a brutally honest teardown, and after the fifth beer even a bad idea sounds good. Always validate it with someone who does not give a damn about you. If they are interested enough to pay, there is some chance it might work and you will avoid burning time and money for nothing.

We were not lucky enough to get that kind of eye-opening criticism. So you start building. Since it happens in the evenings and in your spare time, it takes six months. You polish every technical detail. Half a year later, after much sweat, you have something you might call a stripped-down beta. Then comes the moment you show it to someone for the first time and discover, to your horror, that the group of end users you tailored it for may not exist. You have a great engine, but no product anyone is willing to pay for. You have a toy to keep your inner engineer happy. Great fun, but it will not put food on the table or pay the bills.

Lesson one. What matters most is the users and their willingness to pay. That defines the product. Technology is what lets you build it. Will there be enough users? How will we reach them? Does our model scale? Instead, we discuss which API the app will have, whether to write it in React or Ember, and whether to use a document or relational database. These details matter, but they aren't essential.

Next time someone comes to me with a brilliant idea that every friend will agree to over a third beer, I will define the product first and validate it cheaply. Only once I am reasonably sure there is a group of people willing to pay will I worry about which technology to build it in.

On this subject I recommend the excellent article Seven lessons I learned from the failure of my first startup, Dinnr, the book Running Lean, and the podcast with Hubert Palan on product management and the thorny road every idea travels before it becomes a full-fledged product.