(from TDD entry on Wikipedia)
In the programming world there's this school of thought called Test Driven Development. The idea is basically that if you were going to write a piece of a program you'd start first by writing a test that would verify that it works. Then, you'd write the code and try to get it to pass the test. Let's say it's an adding calculator, so the first thing you'd write is not the code that adds two numbers together, but a test that would verify the results of what you are about to write. Your test is that you'll pass it "1" and "2" and expect the result to come back as "3". Next, you go and write the code that does this. The advantage of this approach is that the test cases drive the implementation. Plus, you continue to use all the tests you write. So anytime you make a change anywhere in the app, all the tests fire as verifiers that you didn't break anything you weren't aware that you broke.
It's a good practice in programming, but I think this is also a great metaphor for startups (and even goals and ambitions elsewhere in life). I've just started working out of a great new co-working space called 3rd Space and have the pleasure of being around some great people, some doing startups, some doing apps, design, marketing, etc. I met a new friend here, Kevin from Fashioning Change, who has solid startup failure and success experience. He engaged me in a great line of questioning the other day. I was showing him a quick proof-of-concept of an app idea that I had made just to test out where the rough parts of developing it might be. I'm integrating 3 services in 3 different programming languages, so I just wanted a quick test if all that was going to work.
Kevin looked at me, excited to show him the programming, and focused me back on the product design. "OK, so back to the idea -- what are your unknowns? What do you need to know in order to say that this is going to work?". Hmmm, I thought about it for a second. I listed a few things that the users would do with this app, over a period of weeks and months. If they did it, that's a success. "OK", he said, so I think you have enough here to test that, don't you?" I resisted a little and let the excuses fly: "The UI is almost non-existent, the color scheme is black on white, the layout makes no sense, the authentication flow is terrible....", I continued. "Well, then just get 5 people you know. If you can't get 5 friends to use it, whom you can show it to and explain it, then a better UI for people you don't know isn't going to help. You just need to test the idea".
Wow, this caught me totally off guard. In my mind what I was showing him was just scratch-paper quality code. This is the napkin doodle before the sketch, before the color markers, before you open the box of brushes and paints. But he's right, and he helped me define the test cases that my idea needs to pass. If it doesn't, then it needs to be tweaked until it does pass. I made him a deal, I wasn't ready to just release this version, but I'd focus for 2 weeks after the new year to have something testable and semi-presentable. Then, with the feedback, decide the next move.
There are lots of names for this process, and lots of existing wisdom out there to test early and often, but for the programmers and programmer-minded, 'test driven idea development' is the way to think about it. If you have an idea for something, write the test case first, then do what you can to try to pass it. Will your user come back X number of times per week and do Y number of actions a month? Will they pay Z dollars for products A, B, and C? You don't need a lot of code to test that out. In fact, you could even hand-write emails and web pages that mimic what a bigger system would do once you build it out. Or, just a really crude proof-of-concept web app that you're scared out of your mind to release with your name on it.