Continuous Feature Release — Business at the Speed of the Internet

Escher's Drawing Hands We have been thinking about how we’ve structured things here at Bscopes. Several recent exchanges with bloggers like April Dunford and Seth Godin have been helping us to articulate our philosophy of product creation.

Our Fundamental Business Rule

For a Web 2.0 startup, IONSHO, the fundamental thing is to be prepared to move at the speed of the Internet. No matter what your size. It’s not like dog years, it’s worse. This is a direct contrast to how we spent 25 or 30 years in the product and services industry. 18 – 24 month product cycles were common there. On the web, people talk about 60 or 90 day cycles. We disagree. We say that a continuous approach to product development is required. Product creation both drives and is driven by the business needs and goals. Our new name proposal: The Escher Business Product Model. Let’s be clear here, if you are Microsoft or Oracle, then you do what you want. When you are two guys in your garage you are much more constrained. This model is based on that situation and those constraints. If you already have VC funding, you can stop reading now.

Constraints Of Small Companies (Two Guys in a Garage)

Many people view the lack of resources as a hindrance, we see it as an advantage. Things that used to cost a lot of money and take a lot of time and expertise are now able to be obtained for a few dollars a month with just a few clicks of the mouse. The services available on the Internet provide enough leverage to enable an entire company be built and launched in a few days. And then continuously evolved over nights and weekends. There were two books that helped to reinforce this Escher Business Product Model. Seth Godin’s Purple Cow and Guy Kawasaki’s The Art of the Start. Both provided vision and helped us formulate our ideas. We had a product idea and Purple Cow helped us understand that such a unique idea could be successful and was an advantage. Guy’s book reinforced our notion that two guys could bootstrap the entire operation. This approach came with constraints:

Reach Exceeds Grasp: We couldn’t build even a fraction of our vision for Bscopes up front
No Users: We couldn’t spend months building hype with some secret “invitation only” private beta test period
Can’t Wait: We couldn’t wait two years to release version 2.0 — improvements would have to come quickly and continuously
No Revenue: We couldn’t wait until the site was “done” to provide enough value to attract a user base

This brought us to the understanding that we had to have a continuous development and release model to turn our constraints into advantages.

Build a little. Build a lot.

Bscopes couldn’t afford to be wrong in a big way. But we could afford to be wrong in a small way. And wrong a lot of times. As long as we learned and grew. We have a vision of what we want. One key to turning these business constraints into product advantages is to ensure that we bound all feature investments. This means breaking our big ideas into small pieces. Incrementally building and releasing them. And then, getting feedback on them ASAP. This is not possible when it takes 18-24 months to go from v1.0 to v2.0.

You Can’t Always Drink Your Own Bathwater

From the Tuned In guys and the product management blog of Steve Johnson, we developed a better understanding of where we were right and where we were wrong. And, more importantly, that sometimes it is not relevant if we are right or wrong: “Your opinion, while interesting, is irrelevant”. This became our mantra and we use it to beat each other up on a regular basis. Part of the juggling act in Escher Business Product Model is to provide the user with enough capabilities so that they can use the product and give feedback, while not over-investing time in the development of any feature. The feature might be rejected, so keep sunk costs small. The key to doing this is to break everything that needs user feedback into mini-functionality releases. It’s like Einstein said, “Make everything as simple as possible, but no simpler.” It’s a continuous effort to maintain the discipline of breaking multi-month cycles into week or two features. And to make sure that week or two long features are supplemented by a number of even smaller tweaks, improvements, and bug fixes. An hour here improving the clarity of one window based on feedback from Twitter. An hour there clarifying the structure of the Bscope graph based on email responses. Continuous small investments, continuously released, yield big results for the users.

Rules For Small Startups

Develop and release continuously: Don’t go a week without some changes.
Keep time investments small: Be prepared to abandon ideas that don’t work.
Get some feedback: Release to the community and listen to what they think.

This is our approach to Web 2.0 development. We are very interested in your approaches or thoughts on our Escher based approach. Please leave some comments below.

If you enjoyed this post, then make sure you subscribe to the Bscopes RSS Feed.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Share:

Bscopes Blog