> Some startups could be entirely manual at first.
> If you can find someone with a problem that
> needs solving and you can solve it manually, go
> ahead and do that for as long as you can, and
> then gradually automate the bottlenecks. It
> would be a little frightening to be solving
> users’ problems in a way that wasn’t yet
> automatic, but less frightening than the far
> more common case of having something automatic
> that doesn’t yet solve anyone’s problems.
Generalizing that slighly, here’s what I call the Shirk & Turk Principle: When writing any new app or website or feature, implement as little of it as you can get away with and manually fake the rest behind the scenes.
I have a fondness for what McKinsey called "crude instruments", something that is almost certainly good enough, and will stop you trying to get ever more precise data.
There will always be an epsilon to conquer; most of them aren't worth the effort after the first couple approximations, and I value accuracy over precision.
5 comments
[ 6.0 ms ] story [ 21.3 ms ] thread"A crude instrument like this is a pretty good start. It begins to shake things up and overcome the internal inertia." http://www.mckinsey.com/insights/strategy/breaking_down_the_...
There will always be an epsilon to conquer; most of them aren't worth the effort after the first couple approximations, and I value accuracy over precision.
"It's better to be vaguely right than exactly wrong" — Carveth Read (1920, predates Keynesian equivalent, q.v. https://en.wikipedia.org/wiki/Carveth_Read )
Thanks to Beeminder, my dental cleanings have gotten to be quite a bit more friendly: https://www.beeminder.com/bostonenginerd/floss