Lead Bullets (2011)

Reminds me of one of my favorite quotes from Admiral Stockdale:<p>"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."

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

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

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

This seems like a couple of nice anecdotes thrown together due to an unfortunate preoccupation with a barely-related cliche.<p>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.<p>If the desire was to communicate something more general, taking it out of the context of existing product-based businesses with market share <i>and</i> 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).<p>So yeah, it's mostly true... but where it is, it's sort of trivially so.

That's a great post.<p>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 <i>still</i> 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.<p>Telling lead from silver requires some learnin'.

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.<p>You need to have some realistic assessment of how badly you're losing. Gungho "Yay effort!" is not a worthwhile risk analysis.

Here is another lesson buried in the post: in most cases, <i>faster is better than better.</i> 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.<p>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).

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).

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)

related: <a href="https://news.ycombinator.com/item?id=3155358" rel="nofollow">https://news.ycombinator.com/item?id=3155358</a>

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

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

I see some lessons in the OP, but not the ones Ben intended.<p>Ben is saying that at times need to work very hard? Okay.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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?<p>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.<p>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.<p>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.

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

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