- 3 min read
We had some hot debates about our beta program. We were seriously considering limiting access to the program and discussed various ways of implementing it, but the final show of hands pointed towards making the program public. The driving force behind this decision was the argument that Wrike's power is in its collaborative abilities. It's not a single-person to-do list. It was created to help people work together to get things done. We want our earliest users to be able to have the full-blown Wrike experience. Limiting registration would mean limiting people's social networks, thus restricting Wrike's entire effect. So we took the risk, decided to skip wasting our time on building a restrictive system and to pool our efforts into preparing the release of a top-quality program. We also bought substantial supplies of coffee to get us through the sleepless nights.
The web 2.0 world is use to public betas. A company builds a product, makes it live, starts promoting it and polishes things on the way (on the way to where). Its a good approach, but sometimes it might be painful for users. You can allow this to happen if you have a strong brand that has an army of raving fans. This practice allows you the ability to make mistakes. We operate conservatively and don't want our customers or ourselves to experience any hardships, so we adopted a different concept. Wrike.com is already live, but we did not publish any news about the product yet and will not at least for the next few months. We will use this breathing space to fix the bugs, stabilize the product and add some handy details, which shift the application from good to great. We will also slowly invite people to join the community of Wrike early users and let us know their thoughts. And when they feel that the product is great, they will start to invite their friends making the evolutionary transition from semi-public to public. How do you like this approach?
The web 2.0 world is use to public betas. A company builds a product, makes it live, starts promoting it and polishes things on the way (on the way to where). Its a good approach, but sometimes it might be painful for users. You can allow this to happen if you have a strong brand that has an army of raving fans. This practice allows you the ability to make mistakes. We operate conservatively and don't want our customers or ourselves to experience any hardships, so we adopted a different concept. Wrike.com is already live, but we did not publish any news about the product yet and will not at least for the next few months. We will use this breathing space to fix the bugs, stabilize the product and add some handy details, which shift the application from good to great. We will also slowly invite people to join the community of Wrike early users and let us know their thoughts. And when they feel that the product is great, they will start to invite their friends making the evolutionary transition from semi-public to public. How do you like this approach?