Jeff D’Urso’s Blog

Ultimately, it’s big ideas that change the world (and make loads of money in the process). eBay, Google, Amazon - all of these started out as “big ideas” - and all of them have great valuations.

But it takes a lot more than a “Great Idea” to achieve great value.

If you have a great idea, in a great market, with a great presentation, and maybe even a great business plan - then what is it currently worth? The only accurate valuation method I can think of is that ideas are worth “a dime a dozen” - therefore your (unlaunched) idea is currently worth just under 1 cent.

And sadly many entrepreneurs spend weeks, months, or even years stuck in the “Idea” stage.

The old axiom “Measure twice, cut once” certainly is true in the game of entrepreneurship. Before spending enormous time, money, and resources building out an idea - it is worth researching the market potential and receptivity to the idea. But there’s a reason why it’s “Measure twice”, and not “Measure 500 times”.

Don’t get caught in the “Presentation” / “Great Idea” feedback cycle.

Once you’ve determined you have a good idea, you will likely put together a presentation and start getting feedback from friends, associates, and others - and the feedback will inevitably be that you have a “Great Idea!” Now that it’s a “Great Idea”, you can double your valuation to 2 cents, and then:

Build out a Beta site already!

Some of the greatest web success stories (including eBay) were up and running in Beta within days or weeks of the initial concept. Then the real magic began. What started as a “Great Idea” quickly became a proven idea, a proven model, and a proven business.

In the case of your idea, there will be 3 possible outcomes that you can get from your Beta launch. 1) the idea is the next killer app and you just need to add water, 2) the idea is “close” and needs some tweaking and iteration to get closer to “hitting a nerve” with your target audience, or 3) the idea is not good.

Now for the key take away…

It’s less important what the outcome of Beta is, then how long and how much it took to get there. If it takes twice as long as it should (or longer), and costs more than it should have (and remember that time is money if it took too long to get here) - then welcome to the land of lost opportunity.

If instead you got to Beta fast, and found out that “the idea needed tweaking”, then you have not exhausted your resources and can tweak away and get it right while the momentum is still there.

It’s amazing how you can do something for 25 years, feel like you’ve “seen it all” - then read a book that causes an “aha moment” and gets you as excited as you were the day you started with it.

Oddly enough, I had such an experience when I read “Building Scalable Websites” by Flickr CTO Cal Henderson. And it wasn’t a “geek moment” that you’d expect from a book on website architecture…

It was a validation of a Common Sense Approach to Software and Website Development that I had evolved throughout my career.

In the book, Henderson details all of the various best practices learned while building Flickr’s architecture from startup phase to a website that handles millions of hits a day. And - contrary to popular belief - the secret to handling the growth is more about “pragmatism” than it is about “rocket science”. 

But the part of the book that really hit home was how the team’s choice of development approach drastically influences its ability to get work done throughout the growth of a website. At the two extremes of development approach are what can be described as “One Giant Function” on one side, and “Object Oriented Programming” on the other - and (here’s the key), Sanity in the middle.

Few software development professionals would argue that “One Giant Function” (OGF) is a viable approach to building websites…

OGF (or putting all of the code into huge, quickly unmanageable scripts) is an approach that dominated the early web. It certainly made it easier to “get something up” faster without having to worry about frameworks or infrastructure, but in the medium and long term - it’s a disaster. With the exception of bottom-of-the-barrel offshore sweatshops, you’ll be hard pressed to find a lot of support for the OGF approach, but…

Too Much Focus on Framework can be just as deadly to a website’s success as not enough.

Without any framework, a website is unmanageable over time, but with too much framework - it can get stuck at the starting gate. Teams that overdo framework end up spending 80% of their time “paying homage to the environment”, and 20% of their time solving the business problem (vs the reverse which is clearly a better scenario!)

I’ve seen teams waste enormous amounts of time trying to get some awkward framework to do something absurdly simple, only to get stuck for days or weeks dealing with obscure errors spit out by a framework that required too many i’s to be dotted, and too many t’s to be crossed for any practical project. So if you’re about to build a new operating system, you can ignore what I’m about to say, but otherwise:

Aim for “High Speed, Low Drag”

Whatever “methodology” you use to get a project done, it should pass two simple tests. The “High Speed test” requires that your team is able to get functionality delivered rapidly at all phases of the website’s development. Elaborate frameworks fail this test miserably because they waste the team’s time figuring them out instead of delivering functionality.

The “Low Drag test” requires that you have enough framework in place that the site is easy to maintain over time. I.e., as the site gets bigger and more complex, it doesn’t create “drag” on integration of new functionality. Fortunately, there are several simple “lightweight” frameworks out there that deliver on this promise by creating just enough rails on the development process to prevent “spaghetti code” without slowing the process to a crawl.

There is a battle between 2 basic strategies that plays out on the web time and time again with consistent and predictable results.

On one side there’s “Keep it Simple Stupid” (KISS), best exemplified by Google; and on the other side it’s “Build Lots (and lots, and lots, and lots) of Application-fattening Tools” (BLOAT), best executed by Yahoo.

KISS is about relevance and resonance.

When executing the KISS strategy, it’s all about finding and solving the “main thing” - i.e., what is the user’s single biggest hot button (maximum relevance), and how do we overdeliver on that with excitement (maximum resonance).

For Google’s audience, it was all about relevant search results, and so Google focused on search and only search. For MP3 players, the goal of most users was to play MP3’s (go figure!) - and so Apple focused on delivering the simplest way to do just that. For Sales Force Automation, it was about easy pipeline management; and so SalesForce.com delivered it.

All 3 of these players grabbed enormous market shares in seemingly “crowded markets” by finding “the thing”, and delivering on that and only that.

The BLOAT Strategy - it slices and it dices; it delivers everything but a solution to the “main thing”.

BLOAT actually starts in the same place as KISS - with the seed of an idea that tries to get to the heart of the “main thing”. The problem is - then it keeps going, and going, and going to lots and lots of lower priority features. The underlying concept is, if we’re not super-confident that the end user is going to be wow’ed by the “main thing”, then we better gold-plate it with lots of razzle dazzle so that they’ll still end up liking the product.

But the problem is - if we don’t nail the end user’s “main thing”, then all the razzle-dazzle and functionality in the world isn’t going to change the fact that we failed to engage them. At worst they’ll scoff, or yawn, at best they’ll claim to like it and then disappear into the ether never to be seen again. The combination of our attempt at the “main thing”, and all the added bells and whistles just didn’t stir any emotions, and so it was all wasted.

And it probably didn’t come cheap!

The only thing worse than failing to engage the end user with our new product or website is that we wasted an enormous amount of time, energy, and expense on “bells and whistles”. Instead of delivering a first iteration of the “main thing” in a matter of days or weeks (like we could have in the KISS scenario), we burned months of time, thousands or tens of thousands (or more) in expenses, and lots and lots of “buzzkill” - and we’re no further along than we could have been.

But what if we miss the “main thing” in the KISS Scenario?

If you miss the “main thing” under the KISS scenario, then either 1) you have the wrong audience, 2) you have the wrong hot button,  3) you didn’t quite hit “resonance”, 4) you are way way off.

Assuming any of the above (except #4), the good news is that you haven’t wasted a lot of time and iteration on your first attempt, so you probably have lots more “steam” available to iterate on a second, third, etc. attempt than if you had gone down the BLOAT path. When it comes together, it’s like a radio station that’s off by a hair - it doesn’t sound so good, but with a few tweaks it comes in crystal clear.

And so the moral of the story is…

Use the KISS strategy, get something (i.e., a Beta release) in front of real live users ASAP, and then iterate as rapidly as you can until you get it right. And avoid the BLOAT monster at all cost!