7 ms·

Lead Bullets (2011)

123 points by zbravo 13y ago

norswap 13y ago
Perhaps I am not getting the point, but it seemed that the silver bullet was to fix the performance issue.
- kcorbitt 13y ago
  I think the connotation of "silver bullet" in this post is an extraordinary idea that solves the problem definitively by changing the rules. A lead bullet, by contrast, acknowledges the current field of play and just plays it better. Less glamorous, but still plenty deadly.
  - mturmon 13y ago
    These elemental analogies are reminding me of the Manhattan project. One silver bullet (E = m c^2 and Einstein's letter to Roosevelt) and some lead bullets (the long slog of building huge industrial plants to purify the uranium). Maybe sometimes you need both.
- narag 13y ago
  The alledged siver bullets, as I understood it, where the set of partnerships and acquisitions that would broaden the product line and surround the web server with enough functionality that we would be able survive the attack. I wonder if this story is related: http://www.jwz.org/doc/groupware.html http://www.jwz.org/doc/groupware.html
- saalweachter 13y ago
  The point was that there was no easy fix to the performance issue (a silver bullet). They just had to buckle down and apply a myriad of optimizations, innovations, and hacks to slowly, incrementally get the performance where it needed to be (lots of lead bullets).
obviouslygreen 13y ago
This seems like a couple of nice anecdotes thrown together due to an unfortunate preoccupation with a barely-related cliche. The way I'm reading it, the point is to concentrate on your product and making it, in reality, better than the product(s) of your competitor(s) rather than... pivoting? Building a different product? Making your product into something else? Changing your target audience? I guess the only real lesson I'm taking away here is that "if you have product, sell it; if it sucks, make it better." Not exactly groundbreaking, though certainly true. If the desire was to communicate something more general, taking it out of the context of existing product-based businesses with market share and competitors would probably be necessary (but would have probably killed the anecdotes... which is why I'm guessing the article didn't really get off the ground in this regard). So yeah, it's mostly true... but where it is, it's sort of trivially so.
- tomblomfield 13y ago
  As you suggest, I think the point was that there's often no brilliant idea that will provide a magical solution to a hard business problem - be that a product pivot or a new sales/marketing gimic. Instead, you often know what you need to do - it's a long, hard slog, and it's about sticking at it longer than your competitors. It's a recurring theme in Ben's blog: >> Mediocre CEOs point to their brilliant strategic moves or their intuitive business sense or a variety of other self-congratulatory explanations. The great CEOs tend to be remarkably consistent in their answers. They all say: “I didn’t quit.” http://bhorowitz.com/2011/04/01/what%E2%80%99s-the-most-difficult-ceo-skill-managing-your-own-psychology/ http://bhorowitz.com/2011/04/01/what%E2%80%99s-the-most-diff...
aresant 13y ago
Reminds me of one of my favorite quotes from Admiral Stockdale: "You must never confuse faith that you will prevail in the end, which you can never afford to lose, with the discipline to confront the most brutal facts of your current reality, whatever they might be."
saurik 13y ago
related: https://news.ycombinator.com/item?id=3155358 https://news.ycombinator.com/item?id=3155358
wilfra 13y ago
Sounds like the Microsoft strategy (Bing, Windows Phone etc) - and now what G+ is trying to do to Facebook. What are some examples of startups doing it (or not doing it)?
- SatvikBeri 13y ago
  Perhaps duckduckgo?
  - orangethirty 13y ago
    Not to take a cheap shot at ddg ( user), but they are a more consumer focused company. Google on the other hand is more b2b.
    - dredmorbius 13y ago
      Google started with a consumer focus. And a large portion of their traffic remains consumer.
      - orangethirty 13y ago
        It started consumer, but it is now B2B. The consumer traffic is what they sell.
        dredmorbius 13y ago
        My point is that if you want to start to get traction, B2C isn't a bad place to start. That assumes you can either translate that to revenues, make a B2B pivot, or shim a B2B service in place at a later date.
        orangethirty 13y ago
        Why would you even target a market you wont profit in? Makes no sense. What Google did is simple: They saw that there is no money in search (ask around), and saw that there was a lot of money in lead generation (advertising). They copied overture, and it grew.
lifeisstillgood 13y ago
The customers were buying; they just weren’t buying our product. This was not a time to pivot. Carve this into the tabletops in every Starbucks in San Francisco
malkia 13y ago
silver bullets are actually much less efficient than lead (vampires or not)
- RandallBrown 13y ago
  but if it's a werewolf, it's the only way to kill them.
aaronbrethorst 13y ago
Semi-related: http://www.paulgraham.com/schlep.html http://www.paulgraham.com/schlep.html Too many people are unwilling to do the hard thing. Probably because their "goal [is] business for the sake of business (http://al3x.net/2013/05/23/letter-to-a-young-programmer.html http://al3x.net/2013/05/23/letter-to-a-young-programmer.html)
coffeemug 13y ago
That's a great post. There is also the opposite problem (one much more common in newbie founders IMO) -- seing lead bullets everywhere when a silver bullet would do. I used to believe I can just outthink and outwork other people by sheer force of will. I still believe I can, but I would have saved myself (and my team) a lot of effort if I learned to look for silver bullets when they fit the problem. Telling lead from silver requires some learnin'.
cl8ton 13y ago
Netscape towards the end was pitching to business and not consumer. Consumers like touchy-feely-hip things (Silver Bullets), business wants things that work. Price, Performance and Support are all that counts at the end of the day. (Lead Bullets)
- artsrc 13y ago
  Our business spent a fortune on a very poor performing, piece of junk, software. Maybe the support is OK, but the real world stability sucks too. Sometimes hookers, expensive lunches, tickets to sporting events and being golf buddies with managers are what counts. And if those are what counts, then those are the lead bullets.
TheBiv 13y ago
This was a lessons-learned post, but I would LOVE to read a "How we made those lead bullets" post. Because his post goes like "guy says lets use lead bullets." -> "We hunker down and use lead bullets" -> magic -> "Boom. $1.6 billion company"
- marcosdumay 13y ago
  > "How we made those lead bullets" Optimize something, reduce the running time by a few ms, optimize something else, reduce by some more ms, repeat 8 hours a day, with several people in paralel for a few months. The concept of a "lead bullet" implies that the history won't be interesting to read, just some repetitive boring hard work.
  - TheBiv 13y ago
    > "Optimize something" I may be the only one, but knowing what the 'something' was is incredibly valuable bc we all, as people, pick 'something' and not everything in any sort of bullet is created equal.
    - stephengillie 13y ago
      Pick one of the "somethings" which is having the biggest impact to your product or service. Repeat.
    - dredmorbius 13y ago
      In performance tuning, this is actually pretty straightforward: - Processes which run many times. - Processes which run long time (and block other processing). - If at all possible: both. The more subtle approach is to identify things you don't need to do (needless initializations, "settle" delays, doing (or allowing to be done) the _wrong_ thing requiring both unwinding that operation _and_ doing the right one, and anything you don't have to wait for (if it's an ancillary process, spin it off and handle it out-of-sequence). Redesigning a process to avoid sorting data. Eliminating global locks. Spinning off tasks to parallelized processing (especially if you have multiple cores/systems available. Pipelining data to avoid writing/reading from disk multiple times. Handling data in memory rather than on disk. Realizing you _can_ handle data in-memory, and that disk-seeks will kill you, so sorting or bucketing output. Swapping spinning rust for SSD. Specific tools such as COW, snapshots, or the like can be very useful in such cases. Algorithms (or methods invoking algorithms) can be another big win. I've seen processes fall in time requirements by 90% following such an optimization process.
graycat 13y ago
I see some lessons in the OP, but not the ones Ben intended. Ben is saying that at times need to work very hard? Okay. Ben is saying that if a competitor has a much better product that is selling well and threatening own business, then likely just must do the work needed for a competitive product. Okay. But after that I lose it with Ben: His "lead bullets" are defeatist, close to luddite, look like he is trying to degrade himself and his company, to fight by getting down, dirty, simplistic, nose to the grindstone, shoulder to the wheel, and ear to the ground and trying to be successful in that position, to suffer first and count on that being the path to success. Not good. Indeed, one of the things we're supposed to be doing is innovating, which likely also means being creative, original, maybe even mathematical or scientific. Ben reminds me of Edison sending yet another team to the Amazon jungle to look for more plants that he could bake into carbon and try for a light bulb filament that wouldn't burn out so soon. The real solution was to borrow the idea of a tungsten filament from the chemist Swan in England and to use a really good vacuum pump from a guy in Germany. Edison could have had his teams slogging through jungles for 1000 years without finding anything. But, eventually Edison did go with tungsten and the German vacuum pump. For Windows' first version of IIS being as much as five times faster, tough to believe that just a 'lead bullet' approach would yield what was missing from what Ben had. Instead, look at the architecture and think a little about what the heck the poor computer is being asked to do. Then look at where the computer resources are going. Likely then, tweak the architecture: So, if are spending time walking down arrays or linked lists in O(n), then consider using an AVL tree in O( ln(n) ). If executing the code for a page when know that the output will be the same as the last 10 times, then cache the output and don't run the code again. If caching the output in main memory, i.e., virtual memory with page faults, then consider just using disk file for each page to be cached and save on page faults. If are connecting to a database, then have a pool of connections. Etc. I.e., think a little. Looks like Ben doesn't like thinking, more likely has, really, a low regard for his people and doesn't trust them to be productive if asked to think. Ben wants to measure hard work by sweat, long hours, and suffering and not good work with good results. Here's a lesson I draw: I agree with Ben that a business that has been going along well might suddenly encounter some problems, e.g., a five times faster competitive product given away for free. First, such problems should have been expected. If Ben had inefficient software, then he should have known that and not had to learn it from a Microsoft product. Or, how and why did the Microsoft people do a much better job? Sure: They wanted something fast, at least not wildly inefficient, thought some about the architecture, and did a decently efficient implementation. Why? Because they cared enough. Then before Microsoft's work, Ben hadn't cared enough. Second, Ben should have done much better trying for, expecting, counting on, working toward silver bullets. I sense that Ben doesn't much believe in silver bullets, suspects that any efforts toward silver bullets will be just time and effort wasted. Bluntly, I seriously doubt if Ben knows how to direct a productive, creative, effective little applied research project. Ben reminds me of the remark in the movie about the auto guy Tucker "A well run company doesn't waste time on research". Yes, some research is close to intellectual self-abuse, but it's the job of a good CEO and a good Board to know that this is not always true (e.g., SR-71, 22 nm line widths) and how to make applied research productive, not just throw out the baby and drink the bathwater. Third, any entrepreneur with a good chance of doing well has to ask himself at least 10^10th times if he wants anyone like Ben on his Board of Directors. Why? Sure: The CEO and his team have seen an area where they might do better. With the CTO, the CEO outlines an applied research project to get the coveted better results. So, for the next Board meeting the CEO includes some foils on the applied research project. Then in the Board meeting Ben wakes up and starts asking questions: How long will the project take? How much will it cost? How good will the results be? What will be the milestones during the project? What is the project schedule, step by step? Or if an experienced auto mechanic can do a brake job on a Ford F150 truck in the time in the book, why not this 'research' project? So, the CEO has to tell Ben and the Board that for all of the questions, at present he is comfortable with the situation, will continue to review the situation during the work, but otherwise really has no answers at all for the more specific questions. Presto: Ben gets torqued, brings out his fiduciary powers, fires the CEO, before his stock is vested, and 'gets the company back on a business like, bottom line basis' and just blows it. Even worse, maybe the applied research has already been successful, and at the Board meeting the CEO introduces the CTO who explains the work and, then, the next step, converting the applied research to production software. Again, just over the software work, Ben does an upchuck. I just don't see Ben being able to work effectively with things that are new, powerful, valuable, innovative, etc. NSF, NIH, and DARPA problem sponsors can. Ph.D. supervisors can. Successful Ph.D. students can. Research professors can. But I don't see Ben as able.
CurtMonash 13y ago
I think I can summarize that post in three words: "Thou shalt execute".
rubinelli 13y ago
Here is another lesson buried in the post: in most cases, faster is better than better. It doesn't matter if you have a much more stable product, with hot swaps, integrated monitoring, auto-balancing, the whole works. If your competitor is five times faster, you are toast. If you look at the past decade and compare the technologies that "won", you will see that in almost every case, they were faster than the alternatives, and had performance as a major selling point. The notable exception is Ruby on Rails, but it was sold so well (the original Rails screencast was ground-breaking) and it solved such a huge pain point (XML hell) that, in this case, it didn't matter (though even they had to answer the question "but does it scale?" at some point).
6d0debc071 13y ago
Let's be realistic here - worst case that you can do anything about: it's possible the other side just hopelessly outmatches you in some area, and likely always will (they've better programmers, they're allowed to use more powerful software, they've better connections, they have enough money to put you out of business by undercutting) - and 'maybe you don't deserve to exist' is not a good answer to 'perhaps we should focus somewhere where we've a competitive advantage.' Maybe you'd be really good at something else, or maybe not - but you've the resources there and you may as well make a go of it if you look to be totally screwed otherwise. You need to have some realistic assessment of how badly you're losing. Gungho "Yay effort!" is not a worthwhile risk analysis.
mikescoffield 13y ago
This reminds me of a product features framework I saw once. It mapped features to a 2x2, which categorized features into 4 buckets. The lead bullets were considered "table stakes" (core features that were necessary and everyone had) and silver bullets are probably "fool's gold" (features that are distinctive, but don't necessarily drive adoption).

Lead Bullets (2011)

123 points by zbravo 13y ago

norswap 13y ago

Perhaps I am not getting the point, but it seemed that the silver bullet was to fix the performance issue.

kcorbitt 13y ago
I think the connotation of "silver bullet" in this post is an extraordinary idea that solves the problem definitively by changing the rules. A lead bullet, by contrast, acknowledges the current field of play and just plays it better. Less glamorous, but still plenty deadly.
- mturmon 13y ago
  These elemental analogies are reminding me of the Manhattan project. One silver bullet (E = m c^2 and Einstein's letter to Roosevelt) and some lead bullets (the long slog of building huge industrial plants to purify the uranium). Maybe sometimes you need both.
narag 13y ago
The alledged siver bullets, as I understood it, where the set of partnerships and acquisitions that would broaden the product line and surround the web server with enough functionality that we would be able survive the attack. I wonder if this story is related: http://www.jwz.org/doc/groupware.html http://www.jwz.org/doc/groupware.html
saalweachter 13y ago
The point was that there was no easy fix to the performance issue (a silver bullet). They just had to buckle down and apply a myriad of optimizations, innovations, and hacks to slowly, incrementally get the performance where it needed to be (lots of lead bullets).

obviouslygreen 13y ago

This seems like a couple of nice anecdotes thrown together due to an unfortunate preoccupation with a barely-related cliche. The way I'm reading it, the point is to concentrate on your product and making it, in reality, better than the product(s) of your competitor(s) rather than... pivoting? Building a different product? Making your product into something else? Changing your target audience? I guess the only real lesson I'm taking away here is that "if you have product, sell it; if it sucks, make it better." Not exactly groundbreaking, though certainly true. If the desire was to communicate something more general, taking it out of the context of existing product-based businesses with market share and competitors would probably be necessary (but would have probably killed the anecdotes... which is why I'm guessing the article didn't really get off the ground in this regard). So yeah, it's mostly true... but where it is, it's sort of trivially so.

tomblomfield 13y ago
As you suggest, I think the point was that there's often no brilliant idea that will provide a magical solution to a hard business problem - be that a product pivot or a new sales/marketing gimic. Instead, you often know what you need to do - it's a long, hard slog, and it's about sticking at it longer than your competitors. It's a recurring theme in Ben's blog: >> Mediocre CEOs point to their brilliant strategic moves or their intuitive business sense or a variety of other self-congratulatory explanations. The great CEOs tend to be remarkably consistent in their answers. They all say: “I didn’t quit.” http://bhorowitz.com/2011/04/01/what%E2%80%99s-the-most-difficult-ceo-skill-managing-your-own-psychology/ http://bhorowitz.com/2011/04/01/what%E2%80%99s-the-most-diff...

aresant 13y ago

Reminds me of one of my favorite quotes from Admiral Stockdale: "You must never confuse faith that you will prevail in the end, which you can never afford to lose, with the discipline to confront the most brutal facts of your current reality, whatever they might be."

saurik 13y ago

related: https://news.ycombinator.com/item?id=3155358 https://news.ycombinator.com/item?id=3155358

wilfra 13y ago

Sounds like the Microsoft strategy (Bing, Windows Phone etc) - and now what G+ is trying to do to Facebook. What are some examples of startups doing it (or not doing it)?

SatvikBeri 13y ago
Perhaps duckduckgo?
- orangethirty 13y ago
  Not to take a cheap shot at ddg ( user), but they are a more consumer focused company. Google on the other hand is more b2b.
  - dredmorbius 13y ago
    Google started with a consumer focus. And a large portion of their traffic remains consumer.
    - orangethirty 13y ago
      It started consumer, but it is now B2B. The consumer traffic is what they sell.
      - dredmorbius 13y ago
        My point is that if you want to start to get traction, B2C isn't a bad place to start. That assumes you can either translate that to revenues, make a B2B pivot, or shim a B2B service in place at a later date.
        orangethirty 13y ago
        Why would you even target a market you wont profit in? Makes no sense. What Google did is simple: They saw that there is no money in search (ask around), and saw that there was a lot of money in lead generation (advertising). They copied overture, and it grew.

lifeisstillgood 13y ago

The customers were buying; they just weren’t buying our product. This was not a time to pivot. Carve this into the tabletops in every Starbucks in San Francisco

malkia 13y ago

silver bullets are actually much less efficient than lead (vampires or not)

RandallBrown 13y ago
but if it's a werewolf, it's the only way to kill them.

aaronbrethorst 13y ago

Semi-related: http://www.paulgraham.com/schlep.html http://www.paulgraham.com/schlep.html Too many people are unwilling to do the hard thing. Probably because their "goal [is] business for the sake of business (http://al3x.net/2013/05/23/letter-to-a-young-programmer.html http://al3x.net/2013/05/23/letter-to-a-young-programmer.html)

coffeemug 13y ago

That's a great post. There is also the opposite problem (one much more common in newbie founders IMO) -- seing lead bullets everywhere when a silver bullet would do. I used to believe I can just outthink and outwork other people by sheer force of will. I still believe I can, but I would have saved myself (and my team) a lot of effort if I learned to look for silver bullets when they fit the problem. Telling lead from silver requires some learnin'.

cl8ton 13y ago

Netscape towards the end was pitching to business and not consumer. Consumers like touchy-feely-hip things (Silver Bullets), business wants things that work. Price, Performance and Support are all that counts at the end of the day. (Lead Bullets)

artsrc 13y ago
Our business spent a fortune on a very poor performing, piece of junk, software. Maybe the support is OK, but the real world stability sucks too. Sometimes hookers, expensive lunches, tickets to sporting events and being golf buddies with managers are what counts. And if those are what counts, then those are the lead bullets.

TheBiv 13y ago

This was a lessons-learned post, but I would LOVE to read a "How we made those lead bullets" post. Because his post goes like "guy says lets use lead bullets." -> "We hunker down and use lead bullets" -> magic -> "Boom. $1.6 billion company"

marcosdumay 13y ago
> "How we made those lead bullets" Optimize something, reduce the running time by a few ms, optimize something else, reduce by some more ms, repeat 8 hours a day, with several people in paralel for a few months. The concept of a "lead bullet" implies that the history won't be interesting to read, just some repetitive boring hard work.
- TheBiv 13y ago
  > "Optimize something" I may be the only one, but knowing what the 'something' was is incredibly valuable bc we all, as people, pick 'something' and not everything in any sort of bullet is created equal.
  - stephengillie 13y ago
    Pick one of the "somethings" which is having the biggest impact to your product or service. Repeat.
  - dredmorbius 13y ago
    In performance tuning, this is actually pretty straightforward: - Processes which run many times. - Processes which run long time (and block other processing). - If at all possible: both. The more subtle approach is to identify things you don't need to do (needless initializations, "settle" delays, doing (or allowing to be done) the _wrong_ thing requiring both unwinding that operation _and_ doing the right one, and anything you don't have to wait for (if it's an ancillary process, spin it off and handle it out-of-sequence). Redesigning a process to avoid sorting data. Eliminating global locks. Spinning off tasks to parallelized processing (especially if you have multiple cores/systems available. Pipelining data to avoid writing/reading from disk multiple times. Handling data in memory rather than on disk. Realizing you _can_ handle data in-memory, and that disk-seeks will kill you, so sorting or bucketing output. Swapping spinning rust for SSD. Specific tools such as COW, snapshots, or the like can be very useful in such cases. Algorithms (or methods invoking algorithms) can be another big win. I've seen processes fall in time requirements by 90% following such an optimization process.

graycat 13y ago

I see some lessons in the OP, but not the ones Ben intended. Ben is saying that at times need to work very hard? Okay. Ben is saying that if a competitor has a much better product that is selling well and threatening own business, then likely just must do the work needed for a competitive product. Okay. But after that I lose it with Ben: His "lead bullets" are defeatist, close to luddite, look like he is trying to degrade himself and his company, to fight by getting down, dirty, simplistic, nose to the grindstone, shoulder to the wheel, and ear to the ground and trying to be successful in that position, to suffer first and count on that being the path to success. Not good. Indeed, one of the things we're supposed to be doing is innovating, which likely also means being creative, original, maybe even mathematical or scientific. Ben reminds me of Edison sending yet another team to the Amazon jungle to look for more plants that he could bake into carbon and try for a light bulb filament that wouldn't burn out so soon. The real solution was to borrow the idea of a tungsten filament from the chemist Swan in England and to use a really good vacuum pump from a guy in Germany. Edison could have had his teams slogging through jungles for 1000 years without finding anything. But, eventually Edison did go with tungsten and the German vacuum pump. For Windows' first version of IIS being as much as five times faster, tough to believe that just a 'lead bullet' approach would yield what was missing from what Ben had. Instead, look at the architecture and think a little about what the heck the poor computer is being asked to do. Then look at where the computer resources are going. Likely then, tweak the architecture: So, if are spending time walking down arrays or linked lists in O(n), then consider using an AVL tree in O( ln(n) ). If executing the code for a page when know that the output will be the same as the last 10 times, then cache the output and don't run the code again. If caching the output in main memory, i.e., virtual memory with page faults, then consider just using disk file for each page to be cached and save on page faults. If are connecting to a database, then have a pool of connections. Etc. I.e., think a little. Looks like Ben doesn't like thinking, more likely has, really, a low regard for his people and doesn't trust them to be productive if asked to think. Ben wants to measure hard work by sweat, long hours, and suffering and not good work with good results. Here's a lesson I draw: I agree with Ben that a business that has been going along well might suddenly encounter some problems, e.g., a five times faster competitive product given away for free. First, such problems should have been expected. If Ben had inefficient software, then he should have known that and not had to learn it from a Microsoft product. Or, how and why did the Microsoft people do a much better job? Sure: They wanted something fast, at least not wildly inefficient, thought some about the architecture, and did a decently efficient implementation. Why? Because they cared enough. Then before Microsoft's work, Ben hadn't cared enough. Second, Ben should have done much better trying for, expecting, counting on, working toward silver bullets. I sense that Ben doesn't much believe in silver bullets, suspects that any efforts toward silver bullets will be just time and effort wasted. Bluntly, I seriously doubt if Ben knows how to direct a productive, creative, effective little applied research project. Ben reminds me of the remark in the movie about the auto guy Tucker "A well run company doesn't waste time on research". Yes, some research is close to intellectual self-abuse, but it's the job of a good CEO and a good Board to know that this is not always true (e.g., SR-71, 22 nm line widths) and how to make applied research productive, not just throw out the baby and drink the bathwater. Third, any entrepreneur with a good chance of doing well has to ask himself at least 10^10th times if he wants anyone like Ben on his Board of Directors. Why? Sure: The CEO and his team have seen an area where they might do better. With the CTO, the CEO outlines an applied research project to get the coveted better results. So, for the next Board meeting the CEO includes some foils on the applied research project. Then in the Board meeting Ben wakes up and starts asking questions: How long will the project take? How much will it cost? How good will the results be? What will be the milestones during the project? What is the project schedule, step by step? Or if an experienced auto mechanic can do a brake job on a Ford F150 truck in the time in the book, why not this 'research' project? So, the CEO has to tell Ben and the Board that for all of the questions, at present he is comfortable with the situation, will continue to review the situation during the work, but otherwise really has no answers at all for the more specific questions. Presto: Ben gets torqued, brings out his fiduciary powers, fires the CEO, before his stock is vested, and 'gets the company back on a business like, bottom line basis' and just blows it. Even worse, maybe the applied research has already been successful, and at the Board meeting the CEO introduces the CTO who explains the work and, then, the next step, converting the applied research to production software. Again, just over the software work, Ben does an upchuck. I just don't see Ben being able to work effectively with things that are new, powerful, valuable, innovative, etc. NSF, NIH, and DARPA problem sponsors can. Ph.D. supervisors can. Successful Ph.D. students can. Research professors can. But I don't see Ben as able.

CurtMonash 13y ago

I think I can summarize that post in three words: "Thou shalt execute".

rubinelli 13y ago

Here is another lesson buried in the post: in most cases, faster is better than better. It doesn't matter if you have a much more stable product, with hot swaps, integrated monitoring, auto-balancing, the whole works. If your competitor is five times faster, you are toast. If you look at the past decade and compare the technologies that "won", you will see that in almost every case, they were faster than the alternatives, and had performance as a major selling point. The notable exception is Ruby on Rails, but it was sold so well (the original Rails screencast was ground-breaking) and it solved such a huge pain point (XML hell) that, in this case, it didn't matter (though even they had to answer the question "but does it scale?" at some point).

6d0debc071 13y ago

Let's be realistic here - worst case that you can do anything about: it's possible the other side just hopelessly outmatches you in some area, and likely always will (they've better programmers, they're allowed to use more powerful software, they've better connections, they have enough money to put you out of business by undercutting) - and 'maybe you don't deserve to exist' is not a good answer to 'perhaps we should focus somewhere where we've a competitive advantage.' Maybe you'd be really good at something else, or maybe not - but you've the resources there and you may as well make a go of it if you look to be totally screwed otherwise. You need to have some realistic assessment of how badly you're losing. Gungho "Yay effort!" is not a worthwhile risk analysis.

mikescoffield 13y ago

This reminds me of a product features framework I saw once. It mapped features to a 2x2, which categorized features into 4 buckets. The lead bullets were considered "table stakes" (core features that were necessary and everyone had) and silver bullets are probably "fool's gold" (features that are distinctive, but don't necessarily drive adoption).