One of the most important things we need to do as a start-up is learn. Actually at the core, the most important thing we need to do is survive, and the best way to survive as a start-up is to grow, and to grow as fast and as big as possible. After all, when you aim for the stars, you usually end up hitting a treetop once reality settles in, so don't aim for just the treetop, or you'll just hit the weeds. So how do you grow as a start-up? The best answer: you don't know! That's where the learning comes in. Exactly how you best grow depends on the precise problem you are trying to solve. No two business problems have exactly the same solution. Each time you get a new feature or change into your users' hands, you get to learn. Did the change successfully generate increased revenue? Do they need it tweaked a certain way? Do they need something different? What do we need to build next? It's experimentation. In fact this is the whole premise of the Lean Start-Up Methodology and its core "Build, Measure, Learn" cycle. And the faster you turn through that cycle, the faster you can learn, the faster you can grow.
But enough theory for now. Yesterday I re-released the "experiment" version of our product, in order to add a key new feature that my partner felt we really need before piano teachers will want to help us run a formal experiment with their students. The experiment will formally validate the pedagogical value of our product! And also help to steer us in what to try next. No we're not selling it yet; we're running at a loss right now to find our launching pad. Our particular product treads new ground and is consequently somewhat research and development. This also puts us in a different, and in a sense more risky, position than a lot of start-ups. Also, the prototype required a lot of complex code and algorithms, so it wasn't the ideal "I'll whip up a prototype over the weekend!" scenario by any means. Nevertheless, now we finally start the "measure" phase of our first cycle!
I do think we could have done some basic user experimentation earlier. Just casually sitting down with individual users as they try it out, watch them, see how the product helps them or misses out on helping them, see the user's delights and frustrations, etc. I want to try to focus harder on this, rather than just the software development. There is a dump truck load of stuff for this solo developer here to build, so my tendency has been to focus solely on the development. Yet, if I build the wrong thing, I'm wasting precious time. At the same time there are some features we know for sure we need in order to have a minimum, viable product, like the ability to purchase--yeah, kinda important. But we do have what we need to see some user interaction and get some valuable feedback.
My partner is unfortunately swamped with his responsibilities as a piano professor until the end of the semester, but is hoping to meet with some teachers this weekend about running the experiment. So hopefully we'll be hearing some user feedback soon!