I thought I understood think/make. But I didn’t really understand think/make.
For the last few weeks, we have been working on marketing plan, crunching financial spreadsheets, moving pixels, and entering the matrix doing a lot of git push heroku. You know, the nuts and bolts of starting a business and building a product. The things that will give our potential customers an actual site to use and let investors know how much we have thought through this stuff.
All the right stuff to do. But a conversation with Justin yesterday reminded me of how “we still don’t have anything to show”. After internalizing more, I think the larger point being, if we’re really building on existing behavior, really meeting an actual need, really making our customers’ lives easier – we should be able to show demand with or without technology. If it takes the two of us manually coordinating classes, then that’s what it’ll take. When it becomes too much, we’ll move to a spreadsheet in order to keep track. When that becomes too much, then we’ll figure out something else. But until we get to that point, it feels rather empty that we’re sitting in front of a computer projecting revenue.
Fast Co.Design had an article posted on Monday on “Wanna Solve Impossible Problems? Find Ways to Fail Quicker“:
MacCready’s insight was that everyone who was working on solving human-powered flight would spend upwards of a year building an airplane on conjecture and theory without a base of knowledge based on empirical tests. Triumphantly, they would complete their plane and wheel it out for a test flight. Minutes later, a year’s worth of work would smash into the ground.
Again, nothing we don’t know already, nothing we haven’t been taught. But what stuck out to me in the article was when the author said:
Progress was slow for obvious reasons, but that was to be expected in pursuit of such a difficult vision. That’s just how it was, went the common thinking.
We’re looking to address wicked problems – the large-scale ill-defined complex social problems that have been around for decades and centuries. We expect things to move slowly. We expect not to solve things overnight. But a little re-framing will get the momentum going, like when Paul MacCready built that airplane in half a year after nobody could for 18 years:
He came up with a new problem that he set out to solve: How can you build a plane that could be rebuilt in hours, not months?
So lesson learned (for the nth time):
When you are solving a difficult problem, re-frame the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.
This morning I sent a bunch of emails to people who have previously expressed their interests in holding/taking classes so we can start having real customers. Fundamentally, our idea holds true with or without Facebook Connect on Rails.
I think I understand think/make a little better today than I did yesterday.1 Comment »