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.