“Target fixation” is a very interesting phenomenon.
I found a very good post describing it far better than I could written by a lawyer. The relevant quote is:
In World War II, fighter pilots spoke of the danger of target fixation. During bombing runs, pilots could become so focused on their targets that they’d dive, drop a bomb on the target, and yet remain so intent on hitting the target that they’d fail to pull up in time. They’d end up hitting their target and killing themselves. Although they would have achieved their mission, they wouldn’t survive to fly the next one or even to celebrate their accomplishment.
As people working on software we sometimes suffer from this as well. You have a client that is waiting on you to deliver, and you disappear for a month to work on the software, and fail to keep the client informed of status updates.
This is a very common case of ‘target fixation’ with us software folk. From the client’s point of view, they are being kept in the dark and out of the loop. They have customers and other stakeholders they need to inform as well.
The worst possible scenario is when you deliver two days late, and at the last minute inform the client of the delay. Prepare to be attacked. The client now looks bad in front of their customers and stakeholders and you’ve lost credibility big-time as a professional.
In this case the software developer suffered from target fixations to the extent that they hurt their customer relationship.
Being adept at communication is a very important skill, and a competency that will determine your level of success. Indeed, this is what distinguished people such as D. Eisenhower who had to deal with very skittish and nervous allies, and keep interests aligned with the most unlikely of supporters, in a very challenging time. Most of us are not asked to win impossible wars, but we should make the effort to make sure that we do take care of our responsibilities, and effective communication makes this more likely.
I read a very interesting post recently titled ‘Acknowledging problems versus solving problems‘.
It struck home to me, how it is so important to keep the flow of communication open at all times. That is one of the reasons why it is important to have an autoresponder on your website, and even better, to send a response from a human. People like to know that they are being heard.
They will understand if the work takes a while, but will never forgive or trust you if you leave them hanging, and wondering if anything is happening.
There is a very eye-opening interview with Peter Norvig, Research Director at Google. The interview is available here
I finally understood why Google is always funding these initiatives that are unlikely to translate to revenue. It’s about growing the customer base by making the Internet more useful. Brilliant, and very healthy, strategy.
Despite all the experiments Google has initiated since it began, the vast majority of your profits—I’ve heard between 97 percent and 99 percent—come from just one thing: advertisements related to search. Obviously, then, income generation is not the metric you’re using to decide if a product succeeds or fails. What is?
You’re right that most of the money comes in through ads. But you can think of everything else as bringing in customers so that they’ll click on the ads. We know the value of adding a new customer, and we can see what the usage is of individual sites. So we can say, “This feature is popular, our usage is going up, and because usage is going up, we’re making more money.” We do things to make Google better so people will come to Google and click on the ads.
What’s interesting, though, is that we’re now at the scale where we can also do things that just make the Web better. We do a lot of open-source projects, because if we release code and some other company makes something really cool that makes the Internet better, we benefit, too. About half of Internet users are using Google search, so if another company builds something and two people start using the Internet because of it, we’re going to get one of them.
Over the past year, I worked in excess of 60 hours a week, between my consulting, working full-time and the development of my prototype, and the education/organization aspects of establishing, maintaining and nurturing a startup.
I had the opportunity to learn some very valuable lessons as part of this process. One of these concerns qualifying your leads.
As soon as you have something of value to sell, whether it is a product, a service, a capability or information, you get into conversations with people in your network who want to benefit from what you are peddling. I have noticed that the ones who are the most enthusiastic about your startup’s offering are usually the ones that you want to avoid. They want to essentially spend your R&D budget on solutions that may be of use to them, without investing anything material into the process.
On the other hand, the people who are skeptical, and appear worried about whether they should work with you are the ones who have something at stake. They have a budget that they want to spend, and are weighing whether they should spend it with you, or with some other alternative.
The important thing here is that they have a budget, and that makes them the sort of customer that you want to spend your effort on.
Keep these customers, and the other guys who want to have endless meetings, and let you run with the development and expenses, and be there for the upside without shouldering any of the load, well, it may be time to discuss consultancy fees for advisory services
I have recently learned that the theories I held dear to me were false and misleading, in economics as well as software development.
Economics theories are based on 18th century physics, with a preponderance of linear models and tons of assumptions. We don’t do physics that way, and doing economics that way will only lead to more financial crises’ (like we have been experiencing for the past century). Physics has moved on advanced simulations and chaos based maths.
Software development is based on manufacturing theories, with inputs going in through one door, and the work being passed on from specialized function to specialized function until the patched, reworked product comes out the other door. Manufacturing has moved on, with the most successful firms employed continuous learning and root-cause analysis to ensure that quality problems never show up in the first place. Read more about this on these excellent posts by Eric Ries on the Five Whys for Startups and the Startup’s Rules for Speed.
I remember when I had to carry out an experiment on Word-Sense-Disambiguation while doing by PhD. I was dealing with several million word collections of text (corpora), and when I started the WSD process, I realized that it would take me around two months to get the data I needed.
That was crazy. However, luckily, Cambridge had access to a CONDOR supercomputing cluster that was available. I paralleliized my code, and launched it on this cluster. After a couple of false starts I got all the data I needed. 42 computers working over 4 days (a weekend+!) got me the 60 days of data.
Nowadays, if you have a bit of cash to burn, you can use the cloud for the same purposes. Here is a case study of an individual who (two years ago!) employed a thousand nodes on Amazon to get their data processed.
It cost them 900 for the CPU and perhaps another 800 or so for the data transfer. Not bad.. that’s pretty cheap to have a thousand computers working for you !
I carried out a quick estimate on the monthly cost of a reasonably CPU intensive web application being run on a cloud computing platform. The results are quite interesting:
Cloud Computing Costs Summary
Configuration: 10 CPU instances, 1 TB of data transfer, and 0.5 TB of data storage
Amazon EC2: 720 + 150 + 50 = 920
Google App Engine: 720 + 100 + 75 = 895
Slicehost: 70 * 10 = 700
Amazon EC2 pricing:
$72 per month
0.15 per GB
150 per TB
$0.10 per GB-month of provisioned storage
100 per TB-month
Google App Engine
Outgoing Bandwidth gigabytes $0.12
Incoming Bandwidth gigabytes $0.10
CPU Time CPU hours $0.10
Stored Data gigabytes per month $0.15
CPU (monthly): 72
$163 per month
0.15 per GB
150 per TB
$0.10 per GB-month of provisioned storage
100 per TB-month
10 instances of 1GB slice
10 cpu instances (burstable to equivalent of 40)
$70 * 10 = 700
Note: The primary constraint on slicehost is storage. You get more bandwidth and CPU capability using multiple slices working together as compared to the standard cloud computing offered by EC2 or App Engine
I have been reading an excellent book recently, ‘The four steps to the epiphany‘ by Steven Gary Blank. He mentions something critical in there, that when you’re developing your product, you don’t get tons of features from customers and keep on developing.
Instead, your goal should be to try and get validation on whether your product (as designed), in its simplest form, is useful to the customer, so much so that they are willing to purchase it.
Powerful advice there. Without this disciplined approach, you’re going to spend all your time (and R&D budget) solving one-off customer needs, rather than having a mass-market-ready product for sale!
Clark Shirky has an excellent post on how complex business models are collapsing in the face of modern technology. It’s a very well argued piece, with examples from media, telecom and ancient empires. Well worth reading.
This also dovetails well with the hypotheses behind the “blue ocean” strategy and “innovator’s dilemma” books, which both essentially state that disruptive technologies usually come from solutions that are resource-poor initially. It’s not always the superbowlesque ‘buy millions of users’ strategy that wins out. A viral strategy, based on an easy to understand value proposition, coupled with natural referencing can always beat out the most expensive of ads in terms of effectiveness.
Read the post here.
Seth Godin is a very prolific blogger. There is a lot of wisdom in his writing, I’ve had quite a few ‘aha’ moments when I can snatch a bit of time from my busy schedule to dash through a few lines that catch my fancy (and his articles are usually not too long, which is nice).
Of course, as with all nuggets of wisdom, the real art is in knowing when that particular nugget applies to your situation. I just read his last article, and absolutely loved it. Read it on this blog at Finding Your Brand Essence.
If you go a bit deeper into what he is saying, you get the message that you should always have a strategy. This is important, because when you have strategy, it means not only that you have a doctrine, vision, and a set of values to guide you to success (or a glorious attempt trying at least), but that you also know where not to go, which battles not to fight, and which doors to close on your way.
Nicely done Seth.