Evolve or die: The Business 2.0 Model

Let me start with my own experience. I have worked in many companies for the past 7 years, I started around year 2000 just after the dot com burst; from research, start-ups, medium size, virtual, to international. I even did freelancing.

During my early years, doing business is very traditional; you need to have proper contacts as well as endorsers. When you get a good feedback that’s the time to set up the initial meetings and you have to make a proposal which includes a hefty amount of case studies to cite, roll-out plans, ROI projections, costing, etc.

If you’re lucky or the bribes paid off, the proposal will be accepted and the contract will be signed; then the planning stage begins. This is when you get to meet all the key people that are going to manage and develop the product. You will have to talk about the designs and resources to be allocated; it does help if you throw a lot of jargons and hype-words. Make sure to study in advance and know what kind of developers the company has. If it’s a company with Microsoft developers throw words like dot Net, VSS, XML, Web services, IIS, and MSSQL. For example: “How are we going to manage the project, do you guys use VSS? We can integrate our system using the Web services that we built on dot Net framework which runs on IIS”. If its Java based development team then just substitute the equivalent hype-words for Java. Its funny how everyone in the room will nod whenever you use their hype-words, I guess it’s like the hearing holy words for them.

The development phase usually takes months but always ends in “almost there” state, everyone will unanimously say: “Let’s compromise; release what we have and deal with what’s missing as a second phase”. If your product ends up like this then celebrate because that’s the best thing that can happen. That’s better off than hearing: “We have to change the way you use it because the original workflow is technically impossible” or the worst is hearing “We need more resources, we have to extend the timeline, outsource parts of it or let’s scratch it then just buy this platform and built on top of it”. Someone must have fallen off the chair reading this by now.

Today this is still practiced here in the Philippines but soon it will need to come to past because there is a new way for doing business.

Welcome to the age of Business 2.0; I call it that way because this strategy is derived from engaging with project that deals heavily on web 2.0 or mobile 2.0 concepts. How does it work?

First think of what you have; what services you run or products you sell then look how this is being done in other countries. Check the “hot” services or products especially the ones with a developer community. Why? Because it’s most probable that service or product has an open API. Now check which service they have that can be duplicated or are not accessible here in the Philippines and at the same time it can be done via their API. Finally check the Terms of Service, If you can’t understand most of then it’s not really important because TOS mostly covers what kind of content is acceptable; the API will most certainly cover only what’s acceptable by TOS.

Just like any business, it’s either the product is copied, extended or integrated with your own. Extending and integrating is the easiest to do since there is an open API and a developer community that can help you. After the development phase you can offer the product as a “Beta”, it’s a way of saying we want you to start using it but expect bugs. Users love bleeding edge and they love it more when they know they can influence how your product will be when it comes out of “Beta”. It gives out that sense of a personalized touch but of course it will probably run for ages that way and even if it’s already rock solid, you will keep it in “Beta” because of its desired effect.

Now let’s go back into the planning phase, on which you won’t need the hype-words anymore. The ins and outs of the API will be clearly stated on the documentation and manual. Bugs are reported promptly then fixed while a road-map of enhancements is available in the forums, developer blogs or wikis so you can think ahead and consider your designs to fit the future.

The development will be smooth because you will be learning how to do it the right way using tutorials and demo application codes you can download. The open API will most probably follow a standardized scheme so most of the guess work is done plus a lot of code libraries and classes would be available to ease your code management.

Even if you’re still on development stage you can invite Beta users to evaluate and help find bugs, make early and frequent releases as much as possible before adding a new feature. You will probably get stuck in this cycle since users will continually contribute ideas but it’s Ok since this is our desired effect.

Finally you will need to grow your number of user’s until the provider of the original service notices you and that’s when you can talk with them about partnership, ROI, etc. It’s usually a short negotiation since your product already supports your claim.

As you can see the difference; Business 2.0 is safer and produces the desired results. No need to for contacts, exclusivity, Non-compete or NDAs or minimum guarantees to toss out from your pocket. It is also the shortest way for local businesses to engage the global market.

The success of your product depends on its mind share, where users continually contribute ideas to your service. This is contrary to the concept of user base; where success is due to the large number of users using it but does not concern them when it comes to improving your product. It’s a battle of quality versus quantity so think well on which type of users your product or service will be best suited for.

If you have a good mind share but you cannot implement their ideas and suggestion then they think that you do not value them and they will move into the next thing that will want to take in their ideas. On the other hand; if you grow your user base too fast you will run out of resources faster than what you can provide to them thus your users will have to contend with a slow service. Because of this you will be more preoccupied in maintaining you product than enhancing it so eventually users will move on to the next newest one they can find.

There is another way where you can try balancing having both type of users; the ones with ideas will belong to a special type or group such as a developers group, this distinction between ordinary users will give them more enthusiasm to contribute ideas which in turn you can implement to suffice the needs of ordinary users for something that’s always new.
Now that’s only some examples of successful Business 2.0, but there are other challenges left like how do you deal with local business partners that refuse to evolve their methods? If they are unwilling to evolve; how to decrease dependency to them? And finally when is the right time to cut the knot?