The three laws of technology strategy

The other day when I was writing about the fate of mobile apps ( http://stephaniefulke.blogspot.com /2008/02/mobile-applications-rip.html">link), I mentioned one of the laws of technology strategy. It made me realize that although we in the industry talk about those laws all the time, I've never seen them all written down in one place. There are probably more than three laws, but these are my favorites. Please post a comment if you want to add some more.

Here we go, twenty years of industry experience boiled down to three lines:


1. An elegant business model paired with mediocre technology beats an elegant technology paired with a mediocre business model.

To put it another way, if you create a marvelous tech product that has no way of making money, you get a long and passionate entry on Wikipedia. If you create a lousy tech product that prints money, you get to be Bill Gates.

Windows is the best case study here, but this one has been proven over and over again in the history of the tech industry. But companies keep tripping over it because they're often run by engineers who have been trained to value technical elegance as an end in itself.

Don't get me wrong, elegance is great. The most wonderful tech companies are those that combine elegant products and great business models. But you must pay the bills or you don't get to keep playing. And wads of money can buy a lot of patches and kludges.


2. Design for a need, not a desire.

A serial entrepreneur once expressed this to me nicely: "I focus on aspirin issues." In other words, if someone has a serious enough problem that they feel pain, they'll be much more likely to pay money for an answer. (I wish I could remember who told me that -- I'd like to credit him by name.)

Very often tech companies will fall in love with a concept that is compelling to people in the company, but not to non-technologists. They'll convince themselves that people will want it because, well, they ought to want it.

A related problem: A company will come up with a product that's nice, but doesn't really address an aspirin problem. You know you have this problem when someone in the company says that need a marketing campaign to explain to people why they should want the product. The really good products need marketing for visibility, not persuasion.

I think this is the underlying problem behind most failed web applications. They do something interesting, as opposed to something compelling.

What makes this whole problem especially tough is that you can't just ask customers what they need. They aren't engineers, they don't understand what you could build. All they'll ask you for is improvements on the products they already have today. What you have to do is get inside the customers' heads, understand how they live, and figure out what you could do to improve their lives. That's what the best product managers do.


3. Software designed for one platform usually fails on another.

We teach this one to ourselves every time the industry goes through a platform transition, and then we promptly forget it again:

A computing platform isn't just a technology, it's a mindset, with a huge set of unstated assumptions about customers and business practices attached to it. When you port software from one platform to another, you take those assumptions along with you, and usually they don't fit.

This is why the software leaders in one generation of computing usually fail in the next generation. Check it out -- which software products led in the DOS world? Lotus, WordPerfect, Ashton-Tate. Did any of them thrive in the Windows/Mac world? Nope.

Then did the software leaders in Windows/Mac -- Adobe, Microsoft, Symantec, Intuit -- dominate in the Internet? Nope, the new startups without the mental baggage dominated.

Which leads to an interesting question: Do you think the leaders of mobile Internet will be the same companies that led the PC Internet? Or is the next Adobe/Lotus/Google a little startup out there, rethinking what it means to be connected in a mobile setting?

Think about it.