Ashutosh Nilkanth's Blog

Recently I read about the yet unbuilt 2011 Ford Fiesta that attracted more than a thousand online pre-orders within the first 6 days of the launch of its reservation program. It made me wonder not only about the marketing hype associated with such campaigns, but also about the fact that pre-orders from such campaigns help dealers gauge interest in the vehicle and what accessories consumers find most appealing.

I found it interesting that the same thought can be applied in the context of technology startups. Pre-release expressions of interest can immensely help Lean Startups gauge interest in the (yet unbuilt) product and what features consumers may find most appealing. It can also help startups ascertain the actual scope, perspective demand and real-world audience of the product, all of which are very important factors for effective monetization. After all, the first goal of a startup is to find those first 50 paying customers.

A big part of the problem is that no one knows what will work with the consumers and what won’t. No amount of market research, case studies or investment will ever substitute a real-world trial. So you start with a bare bones product that requires minimum efforts to build & release for a “preview product”, and hence reduce the time to market.

Building this “preview product”, or a Minimum Viable Product (MVP) as Eric Ries likes to call it, is essentially based on minimizing total time through the Lean Startup feedback loop:

Bootstrapping, rapid prototyping, customer driven development, iterative improvement, eliminating waste (muda), unit testing and continuous deployment are all essential components for building a MVP. Much of this paradigm is also derived from the Toyota Production System.

For example, having a paid account availability notification in your application is a tiny yet nifty approach to a MVP. You build a smaller product, or rather, you build a single feature. You incrementally improve it based on early feedback from interested users. And during this lean startup loop, you measure the actual value of the product by inviting users to pre-order your lean product.

In the field of human-computer interaction, a Wizard of Oz experiment is a research experiment in which subjects interact with a computer system that subjects believe to be autonomous, but which is actually being operated or partially operated by an unseen human being. A related true story I read about an ad-hoc approach, similar to what an MVP can often employ, goes like this:

There was a guy who wanted to sell cars online. But it was a huge system to write from end-to-end, and moreover he didn’t know if it would work or not. So he made a simple website with basic content and forms etc., but he processed the entire back-end work by hand. There was no real automated backend, but the customers got the impression that the entire thing is pretty much automated. This experiment provided him the feedback he needed for expanding his business processes and automating only the essential components.

The best way to predict the future is to invent it.

Another year has nearly come to an end. A new decade is set to begin. It’s amazing how time just whisks away.

What’s also amazing is how much we can learn about ourself in time just by paying a little more attention to that sound in our head. After a year of pondering and progress, mistakes and accomplishments, I felt that I should share what I really learnt this year:

1. Just do it, and more importantly, do it fucking now! Create stuff that excites you. Do stuff that scares you. And, if you think you haven’t found your passion…

2. …Procrastinate. It ain’t that bad, as long as you have a desire to start somewhere. Most people never follow their dreams because they are shit scared to open their eyes. Start small, grow organically. The key is to start. Start!

3. Never argue with a fool. They will drag you down to their level, and then beat you with experience. Same goes for pseudo-intellects and pedants.

4. Health is wealth. I quit smoking for good this year. Took up swimming instead (after a halt of around 10 years). I’m nearing a kilometer of a swim daily, but what’s significant is that mentally and physically I feel rejuvenated.

5. Have positive people around you. I don’t think that people are inherently “bad”, but some people have a tendency to measuredly create naive obstacles to restrain you from doing what they couldn’t or can’t do. If you fail in your repeated efforts to make such people understand the reality, then at-least don’t react negatively yourself. One persons oasis is another persons reality.

6. Wife is always right. But that doesn’t stop me from doing what I want anyway, or so says the wifey.

7. If you are wrong, say sorry. If you are right, shut up.

8. Never do anything for money alone. Do it for a reason you believe in. Do it for your passion. Relatively, don’t be a miser but be frugal.

9. If something doesn’t excite you (makes you say HELL YEAH), then don’t do it. Family commitments are exempted.

10. The most important things in life are not things. An African saying suggests: “If you want to walk quick, walk alone. But if you want to walk far, walk together.”

11. Let bygones be bygones. The only way is forward, so move on. If others want to constantly whine on past grievances, then let them do so. Eventually, they’ll see the bigger picture.

12. The most effective productivity technique that works for me is to just have one goal in a day. If you happen to complete it, then have a second smaller goal, but never have more than one goal a day to start with and more than two goals to end with.

13. Make the World a better place. Again, this doesn’t have to be overwhelming. Don’t expect to change the World over-night. Reduce wastage. Help begins at home and neighbourhood. Start small with Kiva and World Vision. Giving is a good criterion of a person’s mental health. Generous people are rarely mentally-ill.

14. Not everybody agrees to the same things as you do. One must always respect other opinions (so please excuse my rant if you don’t really relate to much of it). Great things happen when people share their opinions, discuss them rationally keeping the larger goal in mind, and reach a simple solution. An interesting thing I took from one of my company meetings was that to make things happen (in an organization or with-in a group of people in general) you need 100% commitment but only 80% agreement.

15. Thank people.

Kudos to some really smart people like Paul Graham, Derek Sivers and many TED speakers who inspired me to prune and spruce my thoughts, and put it all to action in my everyday life.

May the New Year 2010 bring you happiness and good health. Merry Christmas.

When the student is ready, the teacher will appear.

This beautiful Buddhist proverb is a true declaration of an open mind, a mind of a learner. Ever since I heard this proverb, I often wondered if it reflected more than what meets the eye.

A few years ago, I discussed with some friends about our quest for a “teacher”. In our individual lives, our hive-less minds, we need a teacher to guide us. We deliberated, we concurred. But we could never find the real answer. I always considered this proverb on Prima facie, until today, when I realized that I’ve been looking at it differently all along.

After reading Rands’ words on challenging oneself, the proverb made more sense:

You’re in a hurry

Maybe you’re waiting for validation. You’re waiting for that someone you respect to say, “Yes, you bright person, you should do that thing.” It was your parents when you were you kid and then it was your first boss, but now it simply needs to be you.

What you need to understand about these people that support you is that they’re not here to slow you down, they’re here to get the hell out of your way so you can brilliant. You need discover the moment when you actually know better than everyone around you — when you make the first move without asking permission.

We all long for a validation. A validation, that we are taking the right decision, the right choice, at the right time, in the right place, around the right people, and for the right cause (or effect). But we wait. We wait for the teacher to appear and validate our thought. We are spoon-fed to the teacher’s nod, or rejection.

But, the real teacher is within. The real student is within. What we seek is within. What must grow is within.

Validate yourself.

Not so long ago, an acquaintance who was seeking a software development job interviewed for a role at a “market leader” in the development, implementation and support of financial services software. During the interview, it was revealed that the position is concentrated around the implementation of an Enterprise scale project for a large government organization. He was told that the implementation will be based on the companies existing flagship product (a SOA based turnkey system of some sort), which will be extended and customized according to client requirements.

Just a few days before the interview, a team of representatives from the same company met with the business executive from the government organization, at their high-rise conference room overlooking the pier. RFP’s and RFQ’s were already out of the way, and so were the product specifications. The company won the tender because they already had a base solution in the form of a customizable product, and the industry-specific expertise to go with it. It was just a matter of signing the dotted line, with fingers crossed.

What my acquaintance, and the large government organization didn’t know was that there was no such flagship product in existence, at-least in a functional form. The whole proposal was a farce, filled with enough fluff to have lasted as a year’s stock of toilet-paper. In a sense of over-estimation the company did have the technical capability to develop the solution from surface, but realistically it was impossible. The fact of the matter is, almost always — things take longer than they seem, and money lasts shorter than you plan.

Fearful, but not rare. This mechanism, how so ever unethical, is not uncommon in the Enterprise landscape. Garbage-disposal giant Waste Management is still embroiled in a $100 million legal battle with SAP over an 18-month installation of its “fake” ERP software. Waste Management claimed SAP executives participated in a fraudulent sales scheme that resulted in the massive failure. What did a $400 million upgrade to Nike’s supply chain get the world-renowned shoe and athletic gear-maker? Well, for starters, $100 million in lost sales, a 20 percent stock dip and a collection of class-action lawsuits.

The problem lies in three broad facets: people, perspective, and process.

People, at all levels in an organization (large or small) need to rationally answer a question: if I were a business owner, would I invest gazillion dollars on bloated software that takes years to implement, then years to fine-tune, by when it doesn’t solve the ever-transforming problems. Perspective, in terms of the scope and scalability of a solution. “We want to build more features than our competitor”, is a very common notion. Keeping the feature-set minimal may sound like a joke to many corporate vendors and business executives. But, minimalism really promotes iterated execution; which eventually saves money, time and efforts. And finally, process — the end-to-end software engineering approach, which I think is a big factor for so many spectacular failures and huge spending nightmares. Software engineering is relatively young, hardly a few decades old. Compare it with dwelling construction, which originated from the era of the cave man, and you’ll probably understand what I mean.

So you overheard from the cubicle next to yours, “it’s not that simple“. Well, that’s right. Complex ideas result in complex software. The bigger an object, the more energy is required to change its direction. In order to finish a project on time and on budget, without reducing the level of quality, we should ideally implement less and iterate more often. Under-do, and you will make successful software that is lean and opinionated.

Sir Charles Antony Richard Hoare (best known for developing Quicksort in 1960) said:

There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

What makes a programmer good at their craft? For years, organizations which hire programmers have reasoned with this question. Yet, the criteria for selection of a “good” programmer differs by the lot. As candidates, most programmers are put through tough technical interviews, grinding analytical tests, and twisted coding sessions. Employers also review attributes like past work experience, skill-set, education qualifications, references etc. With all sorts of characteristics to gauge, it becomes very difficult to recognize a good programmer, let alone to hire one.

After reading an article titled ‘Signs that you’re a bad programmer‘, I thought hard at what makes a good programmer. No wait, let me rephrase that, for the reason that everyone (including yours truly) is marginally horrible at programming. It’s a craft that takes decades to excel, if not to perfection. So the real question then is, what makes a programmer less horrible?

I have been interviewed for job roles, and I have interviewed other people on occasions. I’ve also been gracefully delegated the awkward task of firing a programmer. To my comprehension, following all these years as a programmer, the most reasonable sign that you are a less horrible programmer is your ability to build stuff during your spare time that serves a utility or solves a problem (maybe your own). When programming becomes a hobby, and as side-projects start taking shape, you’ll start getting marginally less horrible. Even better if those side-projects are collaborative.

This inherent trait shows that such programmers are passionate about the craft as they indulge in “extra-curricular” problem solving. An ad-hoc practice with a variety of small projects also improves the quality of work and estimation accuracy. This skill of utilizing time for 20% of the causes is what makes a (talented) programmer less horrible. Moreover, when you are both the teacher and the student, you’ll find it easier to surpass any illusory superiority. Programmers who strive for a process of continuous learning through self-teaching can be distinguished much easily than with conventional steps of recruitment.