Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Just watched the lecture.

The first part of the lecture was on the "Idea", and I want to give an alternative approach.

First, do I believe that what Altman describes can work and is what he has seen has worked? Definitely yes.

Second, is that all that can work? I don't think so.

Third, do I suggest that the alternative approach I describe here will be common and/or always better than what Altman describes? No. Sometimes better? I do believe so. But even if the alternative approach is rare, that should not be a huge obstacle since the success Altman is talking about, the goal, is also rare. That is, for the rare successes, we should expect that some of the means will also be rare and not common.

But for the alternative approach, given that it is rare, we should have some solid evidence of its effectiveness, and I believe that we can.

I want to propose that it can be possible to have an idea, test it, essentially just on paper, and, if it passes the test, be quite sure the resulting product will be good and fairly sure the resulting company will be successful.

Yes, I'm proposing that the alternative approach provides a way to have the idea be by far the most important part of the work and the rest, e.g., the execution, be routine.

Or I would say that a good idea is one that makes it through the filters of my alternative approach. Then I am claiming that with a bad idea, yes, execution is everything but with a good idea execution is routine.

Yes, to me, the ideas like Altman describes look to me as far too unpromising to be taken seriously and promise that, yes, indeed, execution will be many times more difficult than the idea. Indeed, Altman is admitting that many start ups fail, that building a successful start up is difficult. I would agree that, starting with a bad idea, building a successful start up is difficult.

Now, for the alternative approach for finding a good idea for a start up:

First, the alternative approach is very selective, that is, rejects a lot of ideas. Some of the ideas the approach rejects will be able to be the basis of successful companies. The alternative approach rejects ideas when it just cannot build a rock solid case that the idea is good. E.g., the alternative does not know how to conclude that the ideas for Facebook or Twitter would lead to success. The alternative wants to accept only good ideas and in doing so will reject a lot of good ideas. The alternative approach asks for a lot from an idea, and many good ideas will not have that much.

Second, Altman does emphasize that a need and a corresponding solution one person sees in their own life can be relevant. Okay, I've been there and done that, that is, I've seen needs and solutions.

Third, what I'm proposing for an alternative is, at least in broad terms, and compared with what Altman describes, much older, much more thoroughly tested, and with a much better, really excellent, track record.

Actually, we all know at least something, maybe a lot, about the alternative and its track record. I learned about the alternative early in my career doing mostly US DoD projects around DC and also some other experiences, but there is much more information about the alternative readily available far from me.

So:

(1) Need.

To make the alternative work, we have to start with a suitable need, i.e., market need, that is, a suitable problem to solve. We want the first good or a much better solution to be, obviously, no doubt, a "must have" and not just a "nice to have".

Next, for this need, we want to find the first good or a much better solution, presented just on paper.

Then we want to evaluate the solution, also just on paper. Sorry, no, we don't "get out of the building" and talk to other people.

Big example of such a need? Okay, we'd like to have a safe, effective, inexpensive one pill taken once to cure any cancer. So, yes, early on, for Facebook, Twitter, Snapchat, a lot of doubt. For such a cancer pill, we have "no doubt"; to know this we don't have to "get out of the building", ask people, throw trial solutions against a wall to see if there is interest, etc.

(2) Solution.

Given the need from (1), we try to find a solution. If we fail here, and likely we will, we return to (1) and find another need. E.g., clearly so far the one pill cure for any cancer will fail here for at least a long time.

We want a solution that we are sure, "no doubt", will be the first good or much better.

Here's a way: Start with the real problem and see what about it we can assume. Then convert this problem and its assumptions into a mathematical problem. So, we are limiting ourselves to needs that lead faithfully to mathematical problems. Sorry, no intuitive heuristics need apply.

Next find a mathematical solution.

Develop the mathematical solution just on paper, as carefully done theorems and proofs, and then severely check the proofs.

Then observe that it is totally clear that the mathematical solution will be fully close enough to the first good or much better solution we want for the need.

If any of the work here in step (2) fails, then return to step (1)

(3) Product.

Write software to do the data manipulations specified by the mathematical solution. Severely check the software. That's essentially the product.

If fail here, then return to (1).

Track record? Okay:

(A) GPS.

(B) The version of GPS done first by the US Navy for the SSBNs.

(C) Beam forming in passive sonar.

(D) The A-bomb of WWII -- all three exploded just as planned.

(E) The H-bomb of the 1950s -- first test, 15 million tons of TNT.

(F) The SR-71, for Mach 3+, 80,000+ feet, 2000+ miles without refueling; proposed by Kelly Johnson just on paper; built and flown just as proposed.

(G) Keyhole satellite, essential a Hubble, before Hubble, but aimed at earth instead of space.

(H) The F-117 stealth, essentially a modified F-16, flew as planned, through Saddam's anti-aircraft artillery without a scratch.

(I) The airplane the Wright brothers took to Kitty Hawk, NC.

(J) Phased array radar for Aegis class ships.

(K) High bypass turbofan engines.

(L) RSA encryption.

(M) Hubble.

(N) LHC.

(O) COBE, WMAP, and Planck.

And there are many more. Such projects that failed in execution? Tough to find. Batting average? Near 1000.

Right: Projects A-O are all just technical projects. Right. But in each case they provided the intended solution for the need. As we have explained, to have a successful technical solution lead to a successful solution in business, we want such a solution to be a "must have"; else we return to (1).

The high bypass turbofan jet engine a commercial "must have"? Darned right: It saves an ocean of expensive jet fuel. How? Simple: Burning jet fuel releases energy. Want to convert that energy to kinetic energy and get the resulting momentum. But for mass m and velocity v, kinetic energy is (1/2) mv^2 and momentum is just mv. So, we pay in energy (1/2) mv^2 and get in the momentum we want mv.

So, since in kinetic energy we have v^2 but in momentum have just v, to get more of our desired momentum from our given, available energy, we want m to be large and v to be small. So, mostly we want to use the hot gasses from the combustion to turn a big ducted propeller that moves a huge mass of air at a low velocity. Instead, the military jet engines intended for supersonic speeds, and long used in commercial aviation because they were available, move a smaller mass at high velocity. So, for commercial, subsonic flight, a high bypass turbofan is a "must have". Then have the first good one or a much better one, as we have assumed, and very much should have a successful business.



This was kind of hard to read, but I think you've missed the point.

You seem to be talking about developing new technologies. Sam is talking about commercialising them. There's a big difference. In almost every of the cases you listed the technology was built in response to customer demand.


Yes, there are differences, and you mentioned some. But I believe that the alternative approach I described can work for commercial products and where the founder observes the need. Indeed, as I mentioned, the approach has a severe filter; if the founder can't observe a need where the first good or a much better solution will be a "must have", then back to (1) and try again.

Getting an idea all the way through the filter might be challenging. But, it seems to me that for an idea that does get through the filter, execution should be routine and project success quite likely.


Your way of thinking is interesting, but in all of the examples you give, the execution was vastly more difficult than the idea. Furthermore, most of them weren't commercial products and couldn't have been done by a startup.


It appears that we are not considering the same issues, i.e., we are not communicating,

E.g., right up front in my post I said, as a summary, and overview, and a statement of my purpose in my post:

> I want to propose that it can be possible to have an idea, test it, essentially just on paper, and, if it passes the test, be quite sure the resulting product will be good and fairly sure the resulting company will be successful.

To me, this statement of mine about the idea is very different from what Altman said and very different for the plan and the resulting execution and business. Here I will avoid taking enough words to quote enough from Altman's lecture to show these differences; I assume we agree that, on the idea Altman and I are saying very different things.

For your

> in all of the examples you give, the execution was vastly more difficult than the idea.

Sure, but if you are concerned about this then you are not really responding to what I wrote.

All the examples (A)-(O) do illustrate what I said about the idea.

For execution I said that with a good idea, execution should be routine and low risk. Projects (A)-(O) also illustrate this point -- routine and low risk -- about execution. So, with a sufficiently good idea, execution can be routine and low risk. Here, too, what I am saying is different from what Altman said.

You are also concerned about the amount of effort in the execution. Right. And, right, mostly the projects (A)-(O) do not illustrate low effort. Okay. But we can't use those projects to conclude that there are no projects, start ups, that follow what I said about ideas and that have have low execution effort.

So, for effort in execution, can we also have projects that have low execution effort and, thus, are suitable for start ups? Well, except maybe for the project (L) RSA I listed, the projects in (A)-(O) do not illustrate low effort.

But I do believe that, as we select projects, we can also have some that follow what I described and also have low execution effort. How? Broadly, just do what is the focus of Hacker News -- Information technology that exploits Moore's law and current infrastructure software.

E.g., in

The Happy Demise of the 10X Engineer By Sam Gerstenzang at

http://a16z.com/2014/07/30/the-happy-demise-of-the-10x-engin...

is a discussion of the question:

"How long before we have a billion-dollar acquisition offer for a one-engineer startup?"

So, this is from A16Z: They are guessing that the issue you raised about "effort", we should be able to have a "billion-dollar ... one-engineer startup".

So, A16Z and I agree that now, in information technology start ups, low effort in execution is reasonable to expect.

The A16Z arguments add to mine and do not conflict. I would suggest that my arguments help show the way to the A16Z information technology "billion-dollar ... one-engineer startup" with low risk and low effort.

Why don't we have a lot of examples of projects that followed my arguments, and were "billion-dollar start ups" with low effort? Sure: What I am saying is. so far in practice, mostly new for information technology start ups -- instead of what I described people have followed what Altman described in his lecture. I'm saying that there is a better way, heavily in the planning.

That what I am saying seems new for information technology start up can seem good news unless find the thinking wrong.

Nutshell View: I'm claiming that we can do good planning and with a good plan execution can be routine and the intended success low risk. A key to a reliable path from plan to success is some math for the core of the product. Another key is a problem where the first good or a much better solution is a "must have". My project examples (A)-(O) illustrated that such planning, the role of math, routine execution with low risk, and "must have" solutions are possible. Yes, nearly all the project examples (A)-(O) had high effort. For effort, there's evidence, e.g., from A16Z, that now, due to Moore's law, etc., that for some information technology start ups we might get all of these project attributes along with low effort.

Here what I'm saying is very different from what Altman said and maybe good news.


> the execution was vastly more difficult than the idea

But the execution was fully routine, that is, low risk.

> couldn't have been done by a startup

Right. But maybe in the future, and because of my main point: It's fully possible for the planning to be rock solid and lead to a successful product with low risk. That's the main point -- it really is possible, indeed, in applied science and engineering, nearly standard.

That the examples were not commercial products need not detract much from the main point -- again, we can plan just on paper and have a low risk, high payoff project.

But now we have enhanced opportunities: The math I assumed can be cheap, for someone with an appropriate math background, dirt cheap, fast, fun, easy, and low risk. Then for the product, I assumed that that is just software. So the guy who does the math also does the software -- we're still in the low budget area. Next, the product needs computer hardware, but now enough computer hardware to execute 100,000 lines of code can be less than $2000.

If the product is just a Web site supported by ads, then for just a focused start, where I agree with Altman, might do quite well: E.g., maybe the start up sends Web pages of 400,000 bits per page. Each page has on average 5 ads. From the Mary Meeker data at KPCB, maybe get paid $2 per 1000 ads displayed (CPM = $2). Maybe have an Internet connection with 25 million bits per second upload bandwidth. Maybe half fill that 24 x 7. Then the monthly revenue would be

2 * 5 * 25 * 106 * 3600 * 24 * 30 / ( 2 * 400,000 * 1000 ) = 810,000

dollars. That's enough to fuel organic growth.

So, on average, how many Web pages sent per second?

25 * 106 / ( 2 * 400,000 ) = 31.25

Depending on the project, that might take several computers at $2000 each, but if early on send just 1 page a second, and for some projects early on one computer could do that, and get monthly revenue of

1 * 2 * 5 * 3600 * 24 * 30 / ( 1000 ) = 25,920

dollars so that in one month have free cash flow enough to buy computers enough to send 31.25 Web pages a second.

The 31.25 Web pages a second is a lot of Web pages per month, is

31.25 * 3600 * 24 * 30 = 81,000,000

So how to justify this? Well, as we assumed, the first good or a much better solution for the problem is a "must have". The problem has been selected so that we can attack it essentially just with math. We do the math, as theorems and proofs, and check the proofs carefully -- fairly routine and low chances of errors for a well trained pure/applied mathematician. We convert the math to software and check the software -- again, fairly routine with low risk of errors. Now we have the product, and it is a "must have". Then we go to Altman's lecture and use what he said about viral growth. And we use the assumption that the problem is such that many people want the solution (I hope I made that assumption clear also). What's left to do? Get the checks from the ad networks. Yes, very much do need to meet the assumptions, find the solution, write the software, etc., and if can't then return to (1) and try again.

Once I had a project that looked pretty good on the alternative approach, but the software was going to be too much work because I'd need to write a lot of code for a lot of data collection and with too little information about what the APIs and interfaces were or would be. So, I dropped the project. That is, back to step (1).

You are correct that nearly all the successful, famous projects I listed were, yes, routine, but expensive to execute. And for a start up, we need projects that are cheap to execute. Do such projects exist? I believe so.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: