Saturday, November 25, 2006
Mobile is dud « Elusive Consumer
Mobile is dud « Elusive Consumer
Mobile is dud
Wednesday, October 18th, 2006 in All
Last night I was reminded of my conviction that any business model build around mobile is doomed and that advertisers should ignore this medium for the time being.
Last night I was at PaidContent’s successful LDN ContentNext Mixer networking event that had over 350 attendants.
I talked to a number of mobile start-ups everybody I talked was in mobile for some reason). All had good ideas, none where getting traction. Many were desperately trying to find a work around the network operators.
Think about the innovation you’ve seen in the Internet since 1995 (the year Amazon launched and Netscape IPOed). Think of how you use the computer today compared to back then; of all the innovative services that have been launched; about the revolution we have experienced in the way we communicate, share content, find information. To name a few there is: Amazon, Hotmail, online news, eBay, Wikipedia, Yahoo, MySpace, YouTube, Google, Expedia, online banking, Napster, BitTorrent, digg, SecondLife, blogs, email, instant messaging, Skype…
Now think of the innovation you’ve seen in mobiles since 1985 (when mobiles began to be widely available) – and note they had over 10 years head start. Think of how you used your mobile phone then and now : uhh… you probably still use it to make and receive calls and text messages. Okay, to be complete there is a 1% or less sliver of mobile users who are Blackberry users; or who send picture messages, make video calls or watch TV. But, to drive the point home, these services were launched in the last two years or so.
So what happened to all the mobile entrepreneurs? Why haven’t we seen innovation on mobile phones as we say on PCs. The entrepreneurs were snuffed (1). Because they control the network the mobile operators figured they ought to make all the profit from any business using their infrastructure and totally control (own) the user experience (2). I know of three mobile-based start-ups, by friends of mine, all with reasonably good ideas, that fatally partnered with mobile network operators. The exception was – there is always an exception the defines the rule: ringtones.
Mobile network operators were (and are) too greedy. The only entrepreneurial mobile environment is iMode in Japan where DoCoMo charges a lowly 9% commission on sales.
And that’s my point. The only way a mobile-based business can succeed is to avoid, at all peril, the mobile network operators.
Prediction: Until there is widespread WiFi and 3G access to the Internet via mobile phones (in other words, mobile-based business can reach consumers by going around network operators portals) there will be limited opportunities to establish profitable mobile-based businesses. Established companies should steer clear until then.
Observations
(1) The death of innovation in a closed network environment should serve as a warning to US regulators being lobbied by US operators trying to create a two-tiered Internet.
(2) Another, technical reason, is that mobile phones didn’t have a standard operating platform equivalent to Windows and HTML – until the recent arrival of Java enabled phones. However, for years Nokia represented over 60% of the handset market which is big enough a market. So, though the technical conditions for innovation of services on mobile phones was not ideal, it was not unsurmountable.
Mobile is dud
Wednesday, October 18th, 2006 in All
Last night I was reminded of my conviction that any business model build around mobile is doomed and that advertisers should ignore this medium for the time being.
Last night I was at PaidContent’s successful LDN ContentNext Mixer networking event that had over 350 attendants.
I talked to a number of mobile start-ups everybody I talked was in mobile for some reason). All had good ideas, none where getting traction. Many were desperately trying to find a work around the network operators.
Think about the innovation you’ve seen in the Internet since 1995 (the year Amazon launched and Netscape IPOed). Think of how you use the computer today compared to back then; of all the innovative services that have been launched; about the revolution we have experienced in the way we communicate, share content, find information. To name a few there is: Amazon, Hotmail, online news, eBay, Wikipedia, Yahoo, MySpace, YouTube, Google, Expedia, online banking, Napster, BitTorrent, digg, SecondLife, blogs, email, instant messaging, Skype…
Now think of the innovation you’ve seen in mobiles since 1985 (when mobiles began to be widely available) – and note they had over 10 years head start. Think of how you used your mobile phone then and now : uhh… you probably still use it to make and receive calls and text messages. Okay, to be complete there is a 1% or less sliver of mobile users who are Blackberry users; or who send picture messages, make video calls or watch TV. But, to drive the point home, these services were launched in the last two years or so.
So what happened to all the mobile entrepreneurs? Why haven’t we seen innovation on mobile phones as we say on PCs. The entrepreneurs were snuffed (1). Because they control the network the mobile operators figured they ought to make all the profit from any business using their infrastructure and totally control (own) the user experience (2). I know of three mobile-based start-ups, by friends of mine, all with reasonably good ideas, that fatally partnered with mobile network operators. The exception was – there is always an exception the defines the rule: ringtones.
Mobile network operators were (and are) too greedy. The only entrepreneurial mobile environment is iMode in Japan where DoCoMo charges a lowly 9% commission on sales.
And that’s my point. The only way a mobile-based business can succeed is to avoid, at all peril, the mobile network operators.
Prediction: Until there is widespread WiFi and 3G access to the Internet via mobile phones (in other words, mobile-based business can reach consumers by going around network operators portals) there will be limited opportunities to establish profitable mobile-based businesses. Established companies should steer clear until then.
Observations
(1) The death of innovation in a closed network environment should serve as a warning to US regulators being lobbied by US operators trying to create a two-tiered Internet.
(2) Another, technical reason, is that mobile phones didn’t have a standard operating platform equivalent to Windows and HTML – until the recent arrival of Java enabled phones. However, for years Nokia represented over 60% of the handset market which is big enough a market. So, though the technical conditions for innovation of services on mobile phones was not ideal, it was not unsurmountable.
The Spam Farms of the Social Web
The Spam Farms of the Social Web
Key words that pay a lot
Google AdWords pricing Search term CPC ($)
teeth whitening 18.66
sedation dentistry 12.80
cosmetic dentistry 12.76
dental plans 9.78
dental implant 6.85
pediatric dentist 6.77
discount dental plans 5.93
oral surgery 4.95
braces 3.39
cavity 1.88
Key words that pay a lot
Google AdWords pricing Search term CPC ($)
teeth whitening 18.66
sedation dentistry 12.80
cosmetic dentistry 12.76
dental plans 9.78
dental implant 6.85
pediatric dentist 6.77
discount dental plans 5.93
oral surgery 4.95
braces 3.39
cavity 1.88
Sunday, November 19, 2006
The Parable of the Two Programmers
The Parable of the Two Programmers
The Parable of the Two Programmers
The Parable of the two Programmers
Neil W. Rickert
Dept. of Math, Stat., and Computer Science,
University of Illinois at Chicago.
Once upon a time, unbeknownst to each other, the "Automated Accounting
Applications Association" and the "Consolidated Computerized Capital Corpora-
tion" decided that they needed the identical program to perform a certain ser-
vice.
Automated hired a programmer-analyst, Alan, to solve their problem.
Meanwhile, Consolidated decided to ask a newly hired entry-level program-
mer, Charles, to tackle the job, to see if he was as good as he pretended.
Alan, having had experience in difficult programming projects, decided to
use the PQR structured design methodology. With this in mind he asked his
department manager to assign another three programmers as a programming team.
Then the team went to work, churning out preliminary reports and problem ana-
lyses.
Back at Consolidated, Charles spent some time thinking about the problem.
His fellow employees noticed that Charles often sat with his feet on the desk,
drinking coffee. He was occasionally seen at his computer terminal, but his
office mate could tell from the rhythmic striking of keys that he was actually
playing Space Invaders.
By now, the team at Automated was starting to write code. The programmers
were spending about half their time writing and compiling code, and the rest of
their time in conference, discussing the interfaces between the various modules.
His office mate noticed that Charles had finally given up on Space
Invaders. Instead he now divided his time between drinking coffee with his feet
on the table, and scribbling on little scraps of paper. His scribbling didn't
seem to be Tic Tac Toe, but it didn't exactly make much sense, either.
Two months have gone by. The team at Automated finally releases an imple-
mentation timetable. In another two months they will have a test version of the
program. Then a two month period of testing and enhancing should yield a com-
pleted version.
The manager of Charles has by now tired of seeing him goof off. He decides
to confront him. But as he walks into Charles's office, he is surprised to see
Charles busy entering code at his terminal. He decides to postpone the confron-
tation, so makes some small talk then leaves. However, he begins to keep a
closer watch on Charles, so that when the opportunity presents itself he can
confront him. Not looking forward to an unpleasant conversation, he is pleased
to notice that Charles seems to be busy most of the time. He has even been see
to delay his lunch, and to stay after work two or three days a week.
March 20, 1985
- 2 -
At the end of three months, Charles announces he has completed the project.
He submits a 500 line program. The program appears to be clearly written, and
when tested it does everything required in the specifications. In fact it even
has a few additional convenience features which might significantly improve the
usability of the program. The program is put into test, and, except for one
quickly corrected oversight, performs well.
The team at Automated has by now completed two of the four major modules
required for their program. These modules are now undergoing testing while the
other modules are completed.
After another three weeks, Alan announces that the preliminary version is
ready one week ahead of schedule. He supplies a list of the deficiencies that he
expects to correct. The program is placed under test. The users find a number of
bugs and deficiencies, other than those listed. As Alan explains, this is no
surprise. After all this is a preliminary version in which bugs were expected.
After about two more months, the team has completed its production version
of the program. It consists of about 2,500 lines of code. When tested it seems
to satisfy most of the original specifications. It has omitted one or two
features, and is very fussy about the format of its input data. However the
company decides to install the program. They can always train their data-entry
staff to enter data in the strict format required. The program is handed over
to some maintenance programmers to eventually incorporate the missing features.
Sequel:
At first Charles's supervisor was impressed. But as he read through the
source code, he realized that the project was really much simpler than he had
originally though. It now seemed apparent that this was not much of a challenge
even for a beginning programmer.
Charles did produce about 5 lines of code per day. This is perhaps a little
above average. However, considering the simplicity of the program, it was noth-
ing exceptional. Also his supervisor remembered his two months of goofing off.
At his next salary review Charles was given a raise which was about half
the inflation over the period. He was not given a promotion. After about a year
he became discouraged and left Consolidated.
At Automated, Alan was complimented for completing his project on schedule.
His supervisor looked over the program. With a few minutes of thumbing through
he saw that the company standards about structured programming were being
observed. He quickly gave up attempting to read the program however; it seemed
quite incomprehensible. He realized by now that the project was really much more
complex than he had originally assumed, and he congratulated Alan again on his
achievement.
The team had produced over 3 lines of code per programmer per day. This was
about average, but, considering the complexity of the problem, could be con-
sidered to be exceptional. Alan was given a hefty pay raise, and promoted to
Systems Analyst as a reward for his achievement.
March 20, 1985
The Parable of the Two Programmers
The Parable of the two Programmers
Neil W. Rickert
Dept. of Math, Stat., and Computer Science,
University of Illinois at Chicago.
Once upon a time, unbeknownst to each other, the "Automated Accounting
Applications Association" and the "Consolidated Computerized Capital Corpora-
tion" decided that they needed the identical program to perform a certain ser-
vice.
Automated hired a programmer-analyst, Alan, to solve their problem.
Meanwhile, Consolidated decided to ask a newly hired entry-level program-
mer, Charles, to tackle the job, to see if he was as good as he pretended.
Alan, having had experience in difficult programming projects, decided to
use the PQR structured design methodology. With this in mind he asked his
department manager to assign another three programmers as a programming team.
Then the team went to work, churning out preliminary reports and problem ana-
lyses.
Back at Consolidated, Charles spent some time thinking about the problem.
His fellow employees noticed that Charles often sat with his feet on the desk,
drinking coffee. He was occasionally seen at his computer terminal, but his
office mate could tell from the rhythmic striking of keys that he was actually
playing Space Invaders.
By now, the team at Automated was starting to write code. The programmers
were spending about half their time writing and compiling code, and the rest of
their time in conference, discussing the interfaces between the various modules.
His office mate noticed that Charles had finally given up on Space
Invaders. Instead he now divided his time between drinking coffee with his feet
on the table, and scribbling on little scraps of paper. His scribbling didn't
seem to be Tic Tac Toe, but it didn't exactly make much sense, either.
Two months have gone by. The team at Automated finally releases an imple-
mentation timetable. In another two months they will have a test version of the
program. Then a two month period of testing and enhancing should yield a com-
pleted version.
The manager of Charles has by now tired of seeing him goof off. He decides
to confront him. But as he walks into Charles's office, he is surprised to see
Charles busy entering code at his terminal. He decides to postpone the confron-
tation, so makes some small talk then leaves. However, he begins to keep a
closer watch on Charles, so that when the opportunity presents itself he can
confront him. Not looking forward to an unpleasant conversation, he is pleased
to notice that Charles seems to be busy most of the time. He has even been see
to delay his lunch, and to stay after work two or three days a week.
March 20, 1985
- 2 -
At the end of three months, Charles announces he has completed the project.
He submits a 500 line program. The program appears to be clearly written, and
when tested it does everything required in the specifications. In fact it even
has a few additional convenience features which might significantly improve the
usability of the program. The program is put into test, and, except for one
quickly corrected oversight, performs well.
The team at Automated has by now completed two of the four major modules
required for their program. These modules are now undergoing testing while the
other modules are completed.
After another three weeks, Alan announces that the preliminary version is
ready one week ahead of schedule. He supplies a list of the deficiencies that he
expects to correct. The program is placed under test. The users find a number of
bugs and deficiencies, other than those listed. As Alan explains, this is no
surprise. After all this is a preliminary version in which bugs were expected.
After about two more months, the team has completed its production version
of the program. It consists of about 2,500 lines of code. When tested it seems
to satisfy most of the original specifications. It has omitted one or two
features, and is very fussy about the format of its input data. However the
company decides to install the program. They can always train their data-entry
staff to enter data in the strict format required. The program is handed over
to some maintenance programmers to eventually incorporate the missing features.
Sequel:
At first Charles's supervisor was impressed. But as he read through the
source code, he realized that the project was really much simpler than he had
originally though. It now seemed apparent that this was not much of a challenge
even for a beginning programmer.
Charles did produce about 5 lines of code per day. This is perhaps a little
above average. However, considering the simplicity of the program, it was noth-
ing exceptional. Also his supervisor remembered his two months of goofing off.
At his next salary review Charles was given a raise which was about half
the inflation over the period. He was not given a promotion. After about a year
he became discouraged and left Consolidated.
At Automated, Alan was complimented for completing his project on schedule.
His supervisor looked over the program. With a few minutes of thumbing through
he saw that the company standards about structured programming were being
observed. He quickly gave up attempting to read the program however; it seemed
quite incomprehensible. He realized by now that the project was really much more
complex than he had originally assumed, and he congratulated Alan again on his
achievement.
The team had produced over 3 lines of code per programmer per day. This was
about average, but, considering the complexity of the problem, could be con-
sidered to be exceptional. Alan was given a hefty pay raise, and promoted to
Systems Analyst as a reward for his achievement.
March 20, 1985
