Markets vs. Technologies

During the irrational days of internet bubble 1.0, I had started a software company along with a college friend. Looking back now, I realize that I made a number of mistakes. I learned a lot from that experience though, and I think the most important lesson I took away from it is that markets are not the same as technologies.

Like many entrepreneurs at the time, I was a technical geek, and loved any exciting new technology. My mistake however, lay in thinking that people would pay money for a product just because it was exciting and new. In hindsight, it seems like an obvious mistake - with the exception of a very few technophiles, people don't pay for technology, they pay for convenience. Customers only care about the technology to the extent that it allows them to solve problems better, faster, or cheaper than before.

Our company, along with several others during the bubble, fell into the trap that technology is all it took to build a company. We focused on how to solve a problem, rather than looking at what problems to solve. Since then, I've had this idea repeatedly stressed, not only in my readings, but also in my entrepreneurship and VC classes at Stern.

But my question is, why didn't I think of this the first time around? I'm a consumer too, so why wasn't my natural inclination to think as a consumer? I should have focused on the problems that I could address, rather than the technology I could use. I think one of the causes was my education and experience at the time I left to start the company. After getting my undergrad degree in Chemical Engineering, I went to work as a consultant at Price Waterhouse, doing SAP implementations. In both my coursework, and then in the first couple of years at work, all my training and evaluation were based on how well I met the requirements presented to me. Problems or requirements were handed down as scripture, and all my effort was spent on the mechanics of figuring out the heat transfer coefficient, or the right sql to generate a report. Not once was I encouraged to ask why these requirements were the right ones.

After my company folded and I went back into consulting, I moved into positions of more responsibility, and a lot of my new responsibilities were to do exactly that - determine what to do, rather than how to do it. I realize that until I had the mechanics of development down, I wasn't qualified to do this job, but I don't know why this need was completely ignored in school and in my first assignments.

Most of my engineering education was about teaching me how to think analytically, not about the specific subjects I learned. That's why I was able to take the problem solving concepts I learned in chemical engineering, and apply them to programming. With this focus on skills rather than facts, it seems really surprising that the program didn't take it one step further, and teach us to question the problems themselves, not just the solutions. This may be a result of many of the professors having been academics their entire careers, and not worrying about the business value of what they were teaching. With all the efforts that schools spend on making sure their graduates succeed, it would be an easy win to make sure that every technical graduate had to take at least one class that stressed this type of thinking.

But even if school could be excused for neglecting this education, I don't understand why companies would not drill this into every new hire's head. Since they make their revenue from solving clients' problems, it only makes sense that they would want every person in the company thinking that way from day one. To this day, I see companies who think that developers don't need to worry about the business needs, just about their code. The most successful companies though, make sure that everyone in the organization knows that they exist to solve client needs, and development avoided is much better than development done quickly.

While simple, this is probably one of the most important lessons I've learned in my career. I know many people who've gone through the same learning process, but who now assume that it's common sense. If you are responsible for the development of someone else - as a teacher, a manager, or a mentor - don't take this skill for granted, and make sure you convey how important it is to focus on needs, not technologies.