Skip to main content

start up talk

In today's daily blog hunt I came across this posting:

http://www.dmwmedia.com/news/2007/06/25/guy-kawasaki-markus-frind-founder-of-plentyoffish-is-my-hero

which has a link to a google video on some start up stories. It really is amazing how varied the stories are. Now that I've finished watching the whole thing I can say a bit more about what I think about it. First, a common sentiment that seemed to weave through most of the panel members was the claim that they started from "zero", now as much as I'd like to believe that I can't. No one starts from zero, if these kids were doing this stuff while college students, where did the money come from to pay for college, and for the ones who were already out of college , how did they acquire the capital needed to get the development software and servers? I have been developing my framework for 6 years now, in that time I needed a great deal of money just to provide for the software and hardware to fund my work. I have a hard time believing that the ones that claimed they started with "zero" really meant zero. Then there is the issue of , where did you live and how did you pay for it while you did this thing??? I was fortunate enough to set out a plan after graduating to save as much money as possible precisely because I knew I would be starting a business in 5 years. It in fact was a vow to myself as I stook in cap and gown, but that sacrifice required that I could not move out (then living at my parents home) I had to stay and pay no rent (I paid a few bills but no real rent) again, if I were to add in the true costs of living that were required to sustain me through my development period it would be a heck of a lot more than "zero", because my parents helped me doesn't allow me to discount the assistance. I am not saying that any on the panel had this invisible assistance but I think it is very likely they did.

Another interesting trait that they seemed to have in common was the realization that they could do more with less and the fact they relentlessly went after ways to do it. I think this is very important to not dreaming beyond your ability to succeed. Often we have to measure our imagination in order to ground it along with reality, you can't start out with 15 servers anticipating wild growth. The smart move is to start with the bare minimum, using as little of your financial resources as possible and through good design a great business and some marketing , ensure your chances of rapid and scalable growth. I differ on them , and many of the newer companies on the idea that you should get your idea into an implementation as soon as possible. I think this is too risky, better to master your area of focus , guarantee that you are doing it better than anyone else, protect your innovations with patents that will be difficult to get around efficiently and then come out with your product. Perfect examples of companies that didn't release the first iteration or "prototype" of their idea is one of the largest internet companies today, Google. The story of google is one of two smart guys, looking at a problem that everyone else had considered solved. Search was a veritable backwater, there were several large search engines and they all were "good enough" it seemed for user needs. Then Google comes along with their innovative page rank system, which in hindsight is one of those "of course" ideas... and sure enough that idea has allowed Google to be in a position not only to dominate search as it does today, but to have achieved enough power as to give even mighty Microsoft a bit of trepidation. So there are two polar extremes in the styles of attack for successful internet companies, one is to go the hit em hard and fast route, get the idea implemented and using first mover status and good viral marketing make it big, the other , is analyze a particular area, see what could be done better and if done better could change the game, and then do it better than anyone else is doing it or is able to do it. Then you hit a grandslam instead of just a homerun, just like google did. However this takes us back to the "zero" money point mentioned in the first section. Larry Page and Sergei Brin both were able to raise $1,000,000 to launch their site. I can tell you straight out , this is not easy to do if you don't know the right people. They had existing contacts in Yahoo and other contacts from Stanford faculty who were able to get eyes on the product and see its potential. This is the hard part for the ordinary joe entrepreneur, "getting eyes on the product". Unless you have a set of contacts who would even care to look at your product, it won't be going anywhere...the other option is to fund it yourself. As mentioned in the google story, Sergei and Larry did go into debt just building their data center at a time where site hosting services didn't really exist as they do today, you had to colocate or build your farm yourself. So on the one hand they had the difficulty of building their own datacenter but the ease of access to potential angels and investors who gave them the start up capital they needed to launch their work. I think today, the barriers to entry are smaller for technologies with great and unique implementations behind them like google's, server hosting is much cheaper than colocation or building your own data center, so money can be devoted to the actual development cycle rather than the build cycle later. This is why I say this method of attacking the problem is optimal for today's web 2.0 environment. We are in an ocean of social networks and chat communities, link aggregators and mash up sites, hundreds of flash video sites...to stand out , new players have to target a market or feature, do it better (cheaper/faster) than anyone out now and then continue to feed the beast with their passion.

As their stable and scalable system plugs along , efficiently growing with little effort due to the longer development cycle for the software; the competitors will be having lots of late nights, retooling their software , building cludges to get scalability and generally breaking their backs (and wallets) just to keep up. The classic turtle and the hair story played out. In this increasingly competitive landscape it is only by taking design view toward long term efficiency that we will see the "next google" emerge from the current ocean of web 2.0 companies.


Google story

Comments

Popular posts from this blog

Highly targeted Cpg vaccine immunotherapy for a range of cancer

Significance?


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache
The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the…