Absorb as much of the customer's risk in giving you a chance as possible

Nice advice from Hacker News today: MasterScrat 2 hours ago [-] I am working on a long-term project (an app for collaborative voice translation). Since I will be running out of funding for this project by the end of the month I tried spinning up an "easier" side business: selling websites to veterinary clinics.The idea is that I know well about webdev, and my gf is a vet, so together we could provide a good quality service to vets. Turned out, there was nothing "easy" about that! We discovered about the danger of trying to sell what you are able to build instead of what people wants. We discovered the pains of cold calling. It was a quite formative experience so I did a quick write up yesterday. Feedback is very welcome since we still intend to keep pushing a bit in that direction before we give up! reply

sharemywin 1 hour ago [-] You need to sell the sizzle not the steak. Nobody needs a website. some business need new business. some need ways for existing customers to more easily schedule appointments, etc...Also, the more risk you can absorb the better. don't sell websites sell appointments. or take a commission.

Can bit rot be quantified and minimized?

Bit rot is the name of the fact that software is written for a particular context.  When the context changes, if the software doesn't change then it gradually dies.

I suppose that the same principle can apply to other things. Fashions change.  Ecosystems change as well.  A car or a computer part that was useful 40 years ago may not find uses any more.

It might be interesting to quantify vulnerability to bit rot.  Can it be measured?  Can your vulnerability to it be minimized?

4 classes of metrics

• How many people use your stuff
• How deeply to they use your stuff
• How good is it at doing the thing you say it's supposed to do
• How much money do you make

Avichal Garg during Ycombinator Startup School office hours

Some things are hard to think about but easy to do. So just do them.

There are some things that are much more difficult when you're considering them than when you actually do them.

For me, writing is one of those things, especially if it's writing fiction.  But then, if I can get myself to actually start writing, I end up having fun, almost as though I'm reading the book that I'm writing.

So the key for me is to have the courage to open the text editor and read the last little bit that I've written and then to let the story come.  It's a fear thing, I think.  When I'm not writing, it seems like there will be nothing to write.  But then when I'm actually writing the story comes.

Maximize awesomeness, minimize attack surface

When you place something out into the world for general consumption, suddenly you are asked to do a bunch of different things.

But here's the trick: if you do all the things you are asked to do, you'll likely increase of the complexity of your product.  This increases the number of things that people will want to customize or have their way, which will actually increase the number of things you are asked for.  It's a never ending cycle.

Alex Schultz' Summary

• Move fast (good plan violently executed today better than great plan later)
• Focus on retention
• Have one key metric that you care about for your companies' growth

(https://youtu.be/URiIsrdplbo at about 47:45)

Data, when used in the right way, gives you empathy about your users

It's a nice quote from Alex Schultz (https://youtu.be/URiIsrdplbo at about 28:17)

Why guess when you can measure?

Think of this as a draft.  I'm trying to test out and discover my thoughts here on guessing versus measurement:

I think that your profession can affect the way that you think and interact with people in your every day life.

For example, my mother was trained in analytical chemistry and did a fair amount of work for her doctorate as a C++ coder.  Conversing with her was (and still is) always fun.  But there was one pattern kept popping up in our conversation that took me some time to adapt to: if I ever asked my mother to guess at something, she would refuse to do it.  Why guess at a quantity?  The appropriate response to an empirical question is to make a measurement or look up a previous measurement.

Of course, I then went into physics where the art of guessing is honed and celebrated.  I learned to use dimensional analysis and to do back-of-the-envelope calculations.  I learned to calculate lower bounds and upper bounds.  I learned to estimate my probable error in terms of factors of 2 or 10.  This training made the difference between my mother's refusal to estimate and my love of estimating stronger.

But while I was completing my doctorate and then during my post doctorate and as a full scientist, two things happened.  First, I started to move from theoretical physics to applied physics.  I started working on material science problems.  Just as importantly, I began to spend more and more time coding. 

 In our material science applications, guessing was worth while.  But it was always based on simplifying assumptions.  So guessing was just a first stab.  Truth would reveal itself as we actually performed experiments.

If you were guessing, you might guess that programming would be one place where theory and practice are the same.  The computer does what you tell it to do, no?

In practice, programming is an experimental science.  You write code and then you check to make sure that it does what you hoped it would.  You make a guess, and then you check that guess.  If it was wrong, you tweak things and try again.

In other words, a programmer is constantly applying the scientific method.  They form a hypothesis.  Then they check that hypothesis.  They form a new hypothesis and test that one.

So both scientists and coders are professional practitioners of the scientific method.  The difference is that coders perform many iterations of the method per hour.  Scientists, because they're interacting more closely with nature, are often forced to iterate much, much more slowly.

But the power of both science and programming is that they tell you when you're wrong.  And you find out that you're wrong, or at least missing part of the picture, often.  In programming it might be 100 times a day or more.  If learning that you're wrong 100 times a day and then going back to fix the issue doesn't teach you mental humility, what does?

I actually still believe in guessing, but not as the right way to answer questions.  Guessing is powerful as a way to measure your current state of knowledge.  If you make a measurement without a guess, then you can't be wrong.  And being wrong helps you learn.  So oddly I believe in guessing as a way to find out if you're wrong.

Fine.  But what does being wrong all the time have to do with BrightHike?

BrightHike is built upon the assumption that we can and will be wrong.  It's built on the idea that assumptions need to be checked.

In other words, rather than assume that a person is at a certain point in their understanding, test that.  Rather than assume that a video helps someone understand a particular concept, test its effectiveness.  Every interaction gives us information about our system and about where the user is.  Every interaction can be used to check our assumptions and improve our process.  Rather than assume that a best practice is a best practice, find out. 

The end user is your real customer

I've just been listening to Aaron Levie of Box.com speak about how his team has been approaching working with enterprise software.  One element stuck out to me in the context of building educational products.  He said that his team has had a rule that if there's ever a choice to be made between meeting enterprise requirements and pleasing the end user, they've prioritized the end user, even if it meant turning down millions of dollars:

http://www.youtube.com/watch?v=qRt7mFuKwQY&t=39m49s

This addresses one of my biggest concerns with the idea of working with schools or governments as opposed to individual families.  If you optimize for someone who isn't the end user, you end up gradually with a crummy product that focuses on the wrong thing.  But with a web-based system, you naturally have a direct connection with the end user.  You can see how engaged they are.  You can see what they're spending time on and what's working and not.  So maybe now it's possible to make an end run around optimizing your product for the wrong thing will still selling at an enterprise level.