30 ms·

Yes! I have one! Where do you plan to get your 5 million PV's per month?

by wensing 13y ago

graycat 13y ago
Well, apparently Plenty of Fish did it! So, for a first answer to your question, have to 'plan', that is, think of a Web site that can attract that much traffic, at least from publicity, viral effects, other network effects, happy users, etc. How to do that? Well one way is just to think of a 'business idea' (John Doerr said that business ideas are easy and plentiful; bad business ideas are; maybe good ones are more difficult and rare!), develop a prototype, use 'lean' methodology and/or the Steve Blank approach of continually 'iterating' with the customers and revising the prototype to achieve 'product/market fit', 'pivot' if this doesn't work well, and keep trying. I have another approach in mind borrowed from project planning examples going back over 100 years. A joke version is, a good recipe for rabbit stew starts out, first catch a rabbit! More seriously think of what one venture partner calls a "big ass" problem. I would add detail: Want a problem that is 'big' in the sense that we are sure that the first good or a much better solution will be a very valuable 'must have' and not merely a 'nice to have'. To keep risk down, want no doubt about this. If there is any doubt, pick another problem. Another local, mobile, social, sharing app has too much doubt. Similarly for another 'social graph' recommendation site. From all I can see, mobile payments also have too much risk from regulations and need for 'critical mass'; if try this, then be ready to jump quickly on the first good acquisition offer. The obvious example of such a "big ass" problem, although not from information technology, is a safe, effective, inexpensive, patentable one pill cure for any cancer. Then don't have to worry about 'product/market fit'. Instead, a sad reality and not at all a joke, have to hire security guards to keep desperate customers from breaking down the doors to the lab and trying to steal the pills. Why don't we have such a pill? No one knows how to make one. But the first person or group that figures out how to make one and patents it will have a low risk, first good or much better very valuable solution and a very successful business. So, right, we are getting a hint: For the success we want, it might help to do some original research! So, for step (1), think of a suitable "big ass" problem. Step(2). For this "big ass" problem, want to find the first good or much better solution that will clearly be a very valuable 'must have'. For the very valuable part, in part want a barrier to entry. For a cancer pill, could use patents. For information technology might use Fred Wilson's "large network of engaged users" (but apparently now he is moving into mobile payments instead!), a network effect (everyone uses it because everyone else uses it, e.g., LinkedIn; nice to have; usually tough to get started), a brand name, etc. Or have a technological barrier to entry, that is, have a solution too difficult to duplicate or equal. The common claim that there is nothing new to permit such is just not true. Uh, the technology might be original and not on the shelves of the research libraries -- right, that's commonly called 'research' and venture capital won't fund it, evaluate it, review it, or even think about it and instead will throw it into the bit bucket because their backgrounds in bizdev, marketing, and selling made them afraid and jealous of it; also they want always to be "the smartest guys in the room" which raises a risk of the other guys not being smart enough to make money! So, to get this solution, do something different for recent information technology entrepreneurship but nearly standard for much of engineering going back over 100 years: For our step (2), faithfully convert the real problem into a mathematical problem, e.g., as in the applied mathematics in each of most of the fields of engineering. E.g., notice that the wings don't fall off Boeing 747 airplanes. Why? A major part of the reason is the applied mathematics of mechanical engineering. So, from our step (2), we now have a clearly stated mathematical problem. Although we are in information technology, notice I didn't say we have a computer science problem. We're talking applied math, complete with theorems and proofs and possibly with some advanced pure math prerequisites, common in engineering going back over 100 years, e.g., to Maxwell's equations, but recently rare in information technology startups. Step (3). Get a solid mathematical solution to the mathematical problem. Have two advantages here: (A) Generally it is relatively easy to check such math for math correctness. So, get lower project risk. (B) The math approach can yield solution techniques more powerful and too difficult to think of otherwise. So, get a better shot at the first good or much better valuable solution with a technological barrier to entry. Step (4). Write software to do the data manipulations specified by the mathematical solution. There are two advantages here: (A) The math really should provide a precise, usually succinct, specification of what the software needs to do. E.g., we are not trying to write an 'artificial intelligence' application based on, say, 'rules' and Forgy's RETE algorithm where have to keep 'tweaking' the rules until they appear to work, i.e., keep throwing the software against the wall to see if it appears to stick. We don't have to keep trying maximum likelihood estimation of 'machine learning' to see if it appears to stick. Similarly for neural networks. Instead, if the software just does the data manipulations specified by the prior math, then likely the software is essentially correct, has done its job. So we lower project risk. And such software tends to be easier to write than the common, elaborate user interface software. (B) Such software is relatively easy to check for correctness because of the fundamental advantage that we have a precise, and usually succinct, specification of what the software is supposed to do (the lack of such a specification is the main problem in establishing software correctness). Step (5). Deploy the solution. Get publicity. Likely have built into the problem specification that want a lot of virality. The steps (2) through (4) typically are challenging and high risk. But there are two advantages: (A) Typically these steps can be done essentially just on paper, e.g., as an applied math Ph.D. dissertation or engineering project planning document. And, as for most applied math research, the work usually needs just one person. So, the cost, 'burn rate', is low. (B) The work, the applied math and software, are relatively easy to check for correctness thus lowering project risk. If can't get through the fourth step, then return to step (1) and another problem. Back to step (1), picking the big ass problem: Here definitely want no doubt. But 'social' is not well understood so that for highly 'social' applications we will usually have too much doubt. More generally this 'way' of doing projects won't work for all projects and would not have worked for all successful projects in the past. Right. But the intention that, once step (4) had been completed successfully, the 'way' gives high financial return at low risk for an appropriate project and enough, broadly, to get the business progress we have in mind. So, that's the plan to get the page views!
- morgante 13y ago
  All I get from this is: 1) You can use buzzwords. 2) If I can cure cancer, I'll be rich. Great insights there.
  - graycat 13y ago
    What "buzzwords"? You need to read again. What's there is great stuff, far beyond what you described, that I largely borrowed from the past 100 years of engineering and technology history. The bottom line points are: Getting through step (4) is comparatively cheap, when can do it. So, didn't spend much money. Then in step (5) get to deploy a solution that has high promise of big financial gains with low risk. That's not good news? The 'secret' is that by the time get through step (4), really have something valuable. So, well before launch or traction, are quite confident will get major success. That's big, huge stuff. There are many examples from the past 100 years. Now, note, that after step (1), steps (2)-(4) are just technical. So, we want to know if my claims for those steps are supported by history. Well, for an example, at one time the US wanted to do photo reconnaissance of the USSR. We tried the U-2, but it flew too low and too slow and got shot down. So, Kelly Johnson proposed an airplane that would fly at Mach 3+, at 80,000+ feet, for 2000+ miles without refueling, be relatively difficult to see on radar, and not get shot down. His design and proposal were essentially just on paper. The project was approved, and he delivered as promised. So, the lesson is, really can remove nearly all the technology risk just by work on paper. Then with the 'big' problem as in my step (1) and solid technical work in my steps (2)-(4), enter step (5) in really good shape. This is good news. Sorry you don't see this. If you want to insist, just insist, against all evidence keep just insisting that the usual wildly unpredictable, super high risk work of Silicon Valley venture funded information technology startups is just the best possible with all the risk necessary and impossible to remove, go ahead.

Yes! I have one! Where do you plan to get your 5 million PV's per month?

by wensing 13y ago

Yes! I have one! Where do you plan to get your 5 million PV's per month?

Well, apparently Plenty of Fish did it! So, for a first answer to your question, have to 'plan', that is, think of a Web site that can attract that much traffic, at least from publicity, viral effects, other network effects, happy users, etc. How to do that? Well one way is just to think of a 'business idea' (John Doerr said that business ideas are easy and plentiful; bad business ideas are; maybe good ones are more difficult and rare!), develop a prototype, use 'lean' methodology and/or the Steve Blank approach of continually 'iterating' with the customers and revising the prototype to achieve 'product/market fit', 'pivot' if this doesn't work well, and keep trying. I have another approach in mind borrowed from project planning examples going back over 100 years. A joke version is, a good recipe for rabbit stew starts out, first catch a rabbit! More seriously think of what one venture partner calls a "big ass" problem. I would add detail: Want a problem that is 'big' in the sense that we are sure that the first good or a much better solution will be a very valuable 'must have' and not merely a 'nice to have'. To keep risk down, want no doubt about this. If there is any doubt, pick another problem. Another local, mobile, social, sharing app has too much doubt. Similarly for another 'social graph' recommendation site. From all I can see, mobile payments also have too much risk from regulations and need for 'critical mass'; if try this, then be ready to jump quickly on the first good acquisition offer. The obvious example of such a "big ass" problem, although not from information technology, is a safe, effective, inexpensive, patentable one pill cure for any cancer. Then don't have to worry about 'product/market fit'. Instead, a sad reality and not at all a joke, have to hire security guards to keep desperate customers from breaking down the doors to the lab and trying to steal the pills. Why don't we have such a pill? No one knows how to make one. But the first person or group that figures out how to make one and patents it will have a low risk, first good or much better very valuable solution and a very successful business. So, right, we are getting a hint: For the success we want, it might help to do some original research! So, for step (1), think of a suitable "big ass" problem. Step(2). For this "big ass" problem, want to find the first good or much better solution that will clearly be a very valuable 'must have'. For the very valuable part, in part want a barrier to entry. For a cancer pill, could use patents. For information technology might use Fred Wilson's "large network of engaged users" (but apparently now he is moving into mobile payments instead!), a network effect (everyone uses it because everyone else uses it, e.g., LinkedIn; nice to have; usually tough to get started), a brand name, etc. Or have a technological barrier to entry, that is, have a solution too difficult to duplicate or equal. The common claim that there is nothing new to permit such is just not true. Uh, the technology might be original and not on the shelves of the research libraries -- right, that's commonly called 'research' and venture capital won't fund it, evaluate it, review it, or even think about it and instead will throw it into the bit bucket because their backgrounds in bizdev, marketing, and selling made them afraid and jealous of it; also they want always to be "the smartest guys in the room" which raises a risk of the other guys not being smart enough to make money! So, to get this solution, do something different for recent information technology entrepreneurship but nearly standard for much of engineering going back over 100 years: For our step (2), faithfully convert the real problem into a mathematical problem, e.g., as in the applied mathematics in each of most of the fields of engineering. E.g., notice that the wings don't fall off Boeing 747 airplanes. Why? A major part of the reason is the applied mathematics of mechanical engineering. So, from our step (2), we now have a clearly stated mathematical problem. Although we are in information technology, notice I didn't say we have a computer science problem. We're talking applied math, complete with theorems and proofs and possibly with some advanced pure math prerequisites, common in engineering going back over 100 years, e.g., to Maxwell's equations, but recently rare in information technology startups. Step (3). Get a solid mathematical solution to the mathematical problem. Have two advantages here: (A) Generally it is relatively easy to check such math for math correctness. So, get lower project risk. (B) The math approach can yield solution techniques more powerful and too difficult to think of otherwise. So, get a better shot at the first good or much better valuable solution with a technological barrier to entry. Step (4). Write software to do the data manipulations specified by the mathematical solution. There are two advantages here: (A) The math really should provide a precise, usually succinct, specification of what the software needs to do. E.g., we are not trying to write an 'artificial intelligence' application based on, say, 'rules' and Forgy's RETE algorithm where have to keep 'tweaking' the rules until they appear to work, i.e., keep throwing the software against the wall to see if it appears to stick. We don't have to keep trying maximum likelihood estimation of 'machine learning' to see if it appears to stick. Similarly for neural networks. Instead, if the software just does the data manipulations specified by the prior math, then likely the software is essentially correct, has done its job. So we lower project risk. And such software tends to be easier to write than the common, elaborate user interface software. (B) Such software is relatively easy to check for correctness because of the fundamental advantage that we have a precise, and usually succinct, specification of what the software is supposed to do (the lack of such a specification is the main problem in establishing software correctness). Step (5). Deploy the solution. Get publicity. Likely have built into the problem specification that want a lot of virality. The steps (2) through (4) typically are challenging and high risk. But there are two advantages: (A) Typically these steps can be done essentially just on paper, e.g., as an applied math Ph.D. dissertation or engineering project planning document. And, as for most applied math research, the work usually needs just one person. So, the cost, 'burn rate', is low. (B) The work, the applied math and software, are relatively easy to check for correctness thus lowering project risk. If can't get through the fourth step, then return to step (1) and another problem. Back to step (1), picking the big ass problem: Here definitely want no doubt. But 'social' is not well understood so that for highly 'social' applications we will usually have too much doubt. More generally this 'way' of doing projects won't work for all projects and would not have worked for all successful projects in the past. Right. But the intention that, once step (4) had been completed successfully, the 'way' gives high financial return at low risk for an appropriate project and enough, broadly, to get the business progress we have in mind. So, that's the plan to get the page views!

morgante 13y ago
All I get from this is: 1) You can use buzzwords. 2) If I can cure cancer, I'll be rich. Great insights there.
- graycat 13y ago
  What "buzzwords"? You need to read again. What's there is great stuff, far beyond what you described, that I largely borrowed from the past 100 years of engineering and technology history. The bottom line points are: Getting through step (4) is comparatively cheap, when can do it. So, didn't spend much money. Then in step (5) get to deploy a solution that has high promise of big financial gains with low risk. That's not good news? The 'secret' is that by the time get through step (4), really have something valuable. So, well before launch or traction, are quite confident will get major success. That's big, huge stuff. There are many examples from the past 100 years. Now, note, that after step (1), steps (2)-(4) are just technical. So, we want to know if my claims for those steps are supported by history. Well, for an example, at one time the US wanted to do photo reconnaissance of the USSR. We tried the U-2, but it flew too low and too slow and got shot down. So, Kelly Johnson proposed an airplane that would fly at Mach 3+, at 80,000+ feet, for 2000+ miles without refueling, be relatively difficult to see on radar, and not get shot down. His design and proposal were essentially just on paper. The project was approved, and he delivered as promised. So, the lesson is, really can remove nearly all the technology risk just by work on paper. Then with the 'big' problem as in my step (1) and solid technical work in my steps (2)-(4), enter step (5) in really good shape. This is good news. Sorry you don't see this. If you want to insist, just insist, against all evidence keep just insisting that the usual wildly unpredictable, super high risk work of Silicon Valley venture funded information technology startups is just the best possible with all the risk necessary and impossible to remove, go ahead.