Here’s a meme that resounds quite often in the startup world:
Execution is more important than ideas.
Good ideas are only so good in the mind of the beholder, unless proven to be useful or effective through execution. Ideas matter. The execution of those ideas matters more. But, what is execution?
Execution may mean different things to different people. In it’s basic form, execution means:
a carrying into effect or to completion
I believe that execution fundamentally derives from two inter-related facets: achievement and focus.
Achievement comes from continually completing a thing, more than repeatedly starting many things. Initiation is important, but without completion it’s worthless. Having said that, it’s practically impossible for one person to start many things and complete all of them. So, basically, the secret to achievement is to start fewer tasks or projects, and focusing on completing them before starting anything new.
Focus, and more precisely – uni-focus, is related to achievement. It’s an equally important factor in execution.
Let’s look at an example of a toaster. It’s a common gadget in many households, available in many shapes and sizes. Its primary function is to toast bread.
The ‘Back to Basics Egg & Muffin Toaster’ does it all. It has a 4 slice toaster, 2 egg cooker, slots for toasting muffins & bagels and a host of device controls.
On the other hand, the ‘Transparent Toaster’ has a radical design. It’s a novel idea, but it only does one thing. It toasts bread. And it is transparent, so you can see it all happening, thus avoiding the dreaded burned toast. The sad part is that it’s only a concept design. It couldn’t be mass produced due to a lack of heated glass panel technology.
Then there’s the ‘Magimix Vision Toaster’, which is similar to the ‘Transparent Toaster’ concept, only that it is an actual product. It toasts any kind of bread. It has minimal controls, and it is a classic example of uni-focus execution. It does less, yet its streamlined design overshadows the lack of bloat. Most importantly, it’s a finished product with paying customers.
If you look at some of the most popular and widely used Web applications today like Google Search, Facebook, Twitter or even the Google Chrome Web browser, you’ll find a common theme. They are all uni-focused. Their primary function is based on a single point of operation. The Google Search box is where the world starts their search. The Twitter status update box is the epicentre of real-time micro-messaging. The Facebook status update box helps millions of users to express themselves. The Google Chrome Omnibox is another brilliant example of a uni-focused control where you can search and navigate from the same textbox. All of these applications do much more, but 80% of the users only use the primary function on a daily basis.
Execution is about finding the right balance between achievement (the ability to do less, but get more done) and focus (the ability to concentrate and streamline).
The real question is not “how to build” something. There are enough technology experts around us who can build stuff. Capital, technology, processes and standards are only secondary to good product design. The real question then, is “what to build”, or “what to build” better.
It’s a tough question, but an important one for any entrepreneur (aspiring or established) to address early on. Most startups fail because they build something people never wanted in the first place (i.e. it doesn’t really solve a real-life problem or doesn’t add any value to an existing process), or they take too long (often over-engineering) to build something and hence fail to gain early feedback.
Over the past few months, I have observed that a successful (viz. revenue generating at the very least) product should be able to satisfy one (or more) of these four broad scenarios:
1. It directly helps people make money. Such a product would allow the users to monetize their own creations or digital assets. A few good examples of this product category are Google AdSense, Square, Etsy and oDesk.
2. It directly helps people save money. Such a product would allow the users to save money on their current expenditure (personal or business), or at-least help them manage their money better to start with. A few good examples of this product category are Mint and Google Apps.
3. It helps people to collaborate easily. People like to share stuff and stay in sync (across devices), while saving time and effort. That makes collaboration really effective and lucrative. It also makes this the most crowded category of all. Everything from Project Management apps to Social Networking apps to iPhone/iPad apps try to fit in this broad segment. But only a few genuine products survive due to two factors: most products are too bloated to be used efficiently, and secondly the sheer volume of this segment requires ingenuity. A few good examples of this product category are Dropbox, Evernote, Posterous and Basecamp.
4. It helps people customize a physical good or object. People like to stand-out in the physical world, by looking unique or by creating unique things. A few good examples of this product category are Shoes of Prey, Arduino and Blank Label.
These scenarios can be interpreted as statistical buckets. I’m not suggesting that all products follow (or must follow) these scenarios or that these are magical in any way.
On the contrary, I believe that a successful product is ingenious and simple. It should do less, but it should do that better than the rest. It’s not a novel idea, but first and foremost – you should consider building what you want. Keep it small. Build something that you would want to use everyday. Keep it simple. Build something that solves your own problem.
If you enjoy eating your own dog-food, you’ll eventually find others willing to pay you to share your dog-food with them.
How would you classify writing software? Is it science (as in computer science), a form of art (as in code is poetry or prose) or an engineering discipline? Terence Parr, a professor of computer science at the University of San Francisco, recently wrote about why writing software is not like engineering. Terence concludes that writing software is more an art than an engineering discipline:
Writing software is most similar to writing fiction novels. Writing novels is also an act of creation in an unconstrained and ethereal medium with few well-established construction rules.
I find this notion to be a fallacy, because writing software can be looked as a form of art, but it is largely driven by engineering. Programming can be called a craft or an art-form, but the software itself is not. My biggest argument in this context is regarding automation. Engineering primarily promotes automation of tasks. Most software is written to automate manual or semi-manual processes and enforce computational validations. However, we cannot automate art. A painting won’t automatically self-render itself into a 3D landscape. Nor would the premise of a fiction novel evolve or extend on its own, like refactored source code or OOP libraries can allow for in software.
It has become quite clear in the software world that a big design up-front doesn’t work. Engineering can solve this problem through iterative design and development. Art, on the other hand, cannot be progressive by its very nature. The final result of art is static, albeit beautiful or enjoyable.
Recently I heard Neal Ford talk about Emergent Design during a brown bag session at work. Neal is an author, a speaker and a Software Architect at ThoughtWorks. In his talk, Neal questioned the nature of code? What is software code? I think it’s a subtle yet very important construct in the understanding of software engineering.
A conventional engineer’s output, be it mechanical, aeronautical or any other branch, is the design or the blueprint. The engineer provides the very basis of objects architecture and its inner-workings. But what is the output of a software engineer? Yes, our lot designs architectures too and we also document the inner-workings (as much as some of us hate to). But the primary output of a software engineer is — the code. Hence, software code is the core output of a type of engineering, not a type of art.
To further draw the “art of engineering”, I’ll leave you with an interesting anecdote to ponder on:
Warning! If you still enjoy playing PacMan, don’t read the next paragraphs—they will ruin it forever for you. Sometimes knowledge comes with a price.
Consider the PacMan console game. When it came out in the 1970s, it had less computational ability than a cheap cell phone of today. Yet, it had to solve a really difficult math problem: how do you get the ghosts to chase PacMan through the maze? That is to say: what is the shortest distance to a moving target through a maze? That’s a big problem, especially if you have very little memory or processor power to work with. So the developers of PacMan didn’t solve that problem, they used the anti-object approach and built the intelligence into the maze itself.
The maze in PacMan acts like an automata (like in Conway’s Game of Life). Each cell has simple rules associated with it, and the cells executed one at a time, starting at the upper left and proceeding to the lower right. Each cell remembers a value of “PacMan smell.” When PacMan sits on a cell, it has maximum PacMan smell. If he had just vacated the cell, it has maximum PacMan smell –1. The smell degrades for a few more turns, then disappears. The ghosts can then be dumb: they just sniff for PacMan smell, and any time they encounter it, they go to the cell that has a stronger smell.
The “obvious” solution to the problem builds intelligence into the ghosts. Yet, the much simpler solution builds the intelligence into the maze. That is the anti-object approach: flip the computational foreground and background. Don’t fall into the trap of thinking that “traditional” modeling is always the correct solution. Perhaps a particular problem is more easily solved in another language entirely.
I’ve been reading a lot about “Augmented Reality” lately. Just the other day, I saw this beautiful short film titled ‘World Builder‘, that also depicts this powerful holographic technology to express the fusion of the physical and virtual worlds.
Augmented Reality (AR) is basically the combination of real-world video imagery and computer-generated data (virtual reality), where computer graphics objects are blended into real footage in real time. The GE Smart Grid demo uses AR (must watch the video). It’s a fascinating technology, and I think it has a lot of potential in the consumer space as well.
Some startups (like Layar and Wikitude) are already developing AR geo-interfaces (GPS based) for mobile phones, which would allow anyone to simply point their phone camera in open space (say a market-place in a new city you are in), and get a location-based interactive perspective (say the landmarks, ATM’s, or pubs near you) through dynamic recognition.
Zugara’s Augmented Reality & Motion Capture Shopping Application (demo video) is also a neat example of things to come.
Nokia has also been building this technology on more than a decade of academic research into mobile AR. Nokia researchers have been working on real-time image-recognition algorithms as well; they hope the algorithms will eliminate the need for location sensors and improve their system’s accuracy and reliability.
One day, in the genuinely not so distant future we will live in two worlds; reality and augmented, neatly combined into one.
At PDC 2008, Microsoft gave the first public demonstration of Windows 7, its next generation operating system.
I’ve been following the state of engineering behind Windows 7 for a while, both architecturally and UI, and after looking at the simplistic look, I hope it delivers a more secure, more stable, and less fussy OS.
The real question is not “how to build” something. There are enough technology experts around us who can build stuff. Capital, technology, processes and standards are only secondary to 
