4 ms·

Is any of that true? Are ideas really that easy? Also these people aren't being paid for ideas. They're being paid for vision and the ability to guide that visi

by enjo 9y ago

Is any of that true? Are ideas really that easy? Also these people aren't being paid for ideas. They're being paid for vision and the ability to guide that vision through to completion. I've met FAR more competent implementers in my life than I have product owners. You seem (and others) seem to be arguing that there is some sort of market inefficiency here, but I don't see that. And I say that as an implementer.

graycat 9y ago
A common remark from VCs, e.g., John Doerr at KPCB (e.g., quoted at AVC.com) is that "Ideas are easy and plentiful. Execution is hard and everything." Well, bad ideas are easy and plentiful, and then execution is hard and everything. But good ideas are hard, and then execution is routine. By an "idea" Doerr meant just some short, off-hand statement, say, at a party or over the family Sunday dinner table, some summary might tell a neighbor over a back fence. A good idea, however, may come with a stack of solid background research on the market, the problem to be solved, and a really good solution, say, the first good or a much better solution, with good barriers to entry, etc. Here's an approach: Pick a problem that so far is solved at best poorly but where the first good solution will be close to a must have for enough people and revenue per person to make a successful business. Then find a good solution. The solution might have secret sauce which was needed to solve the problem (why the problem wasn't solved 10 years ago) and that can also be a big barrier to entry. It would help a lot to exploit current, comparatively dirt cheap, computing. If you write all your own code, then likely you don't need co-founders. Venture capital won't much help because by the time you have enough for the VCs to write you a check, you will already have enough in traction that you can monetize to have enough revenue that you no longer need, want, or will accept their check, BoD, term sheet, vesting of what you already own 100% of, etc. The checkbooks of the VCs were important when a Web site startup needed to spend big bucks with Sun Micro Systems, Oracle, Cisco, etc., but those days are over. Now the prices for such things are WAY down and the checkbooks of the VCs much less important.
dgreensp 9y ago
At one level, “idea person” is a misunderstanding of the founder’s role; founders must execute, all day long. It’s not just the programmmers who “implement,” either. At another level, I’ll admit that most founders I’ve worked for have excelled more at promoting their ideas, raising money, and hiring talent — top talent, no small feat! — than product ownership. In this case, the lieutenants who make the gears mesh and not jam are the heroes to me.
btilly 9y ago
There is a discipline of actually doing the work that rewards competence. If you take a competent implementor, give them the title of "architect", and have them tell everyone else how their programs should be designed, the natural tendency is downhill in competency. I've met brilliant architects. I've never met an architect who impressed me that didn't code a lot. But still, even among implementors there are frequently disagreements on the design that should be followed. And you see the same pattern. The person who wins the disagreement tends to get a lion's share of the credit for improvements, and often gets to skip blame if it fails. If you win several of these in a row you may get offered a raise and title of architect.

by enjo 9y ago

graycat 9y ago

A common remark from VCs, e.g., John Doerr at KPCB (e.g., quoted at AVC.com) is that "Ideas are easy and plentiful. Execution is hard and everything." Well, bad ideas are easy and plentiful, and then execution is hard and everything. But good ideas are hard, and then execution is routine. By an "idea" Doerr meant just some short, off-hand statement, say, at a party or over the family Sunday dinner table, some summary might tell a neighbor over a back fence. A good idea, however, may come with a stack of solid background research on the market, the problem to be solved, and a really good solution, say, the first good or a much better solution, with good barriers to entry, etc. Here's an approach: Pick a problem that so far is solved at best poorly but where the first good solution will be close to a must have for enough people and revenue per person to make a successful business. Then find a good solution. The solution might have secret sauce which was needed to solve the problem (why the problem wasn't solved 10 years ago) and that can also be a big barrier to entry. It would help a lot to exploit current, comparatively dirt cheap, computing. If you write all your own code, then likely you don't need co-founders. Venture capital won't much help because by the time you have enough for the VCs to write you a check, you will already have enough in traction that you can monetize to have enough revenue that you no longer need, want, or will accept their check, BoD, term sheet, vesting of what you already own 100% of, etc. The checkbooks of the VCs were important when a Web site startup needed to spend big bucks with Sun Micro Systems, Oracle, Cisco, etc., but those days are over. Now the prices for such things are WAY down and the checkbooks of the VCs much less important.

dgreensp 9y ago

At one level, “idea person” is a misunderstanding of the founder’s role; founders must execute, all day long. It’s not just the programmmers who “implement,” either. At another level, I’ll admit that most founders I’ve worked for have excelled more at promoting their ideas, raising money, and hiring talent — top talent, no small feat! — than product ownership. In this case, the lieutenants who make the gears mesh and not jam are the heroes to me.

btilly 9y ago

There is a discipline of actually doing the work that rewards competence. If you take a competent implementor, give them the title of "architect", and have them tell everyone else how their programs should be designed, the natural tendency is downhill in competency. I've met brilliant architects. I've never met an architect who impressed me that didn't code a lot. But still, even among implementors there are frequently disagreements on the design that should be followed. And you see the same pattern. The person who wins the disagreement tends to get a lion's share of the credit for improvements, and often gets to skip blame if it fails. If you win several of these in a row you may get offered a raise and title of architect.