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?

Marketing 101 for Developers

It's 3AM when I went home from a party but I couldn't sleep so i picked up one of my fiancee's book which she left titled "Marketing Magic" by Don Debelak, It's a good book for those who's into small-medium enterprises which teaches you the basics about marketing. Note: I also identified a lot of BS stuff on it which is typical since most marketing people won't share their trade secrets.

You might find it weird that a system engineer/programmer like me would read such books but IMHO after finishing the first 5 chapters I'm persuaded that this should have been part of our BSCS college curriculum in the first place.

So I tried applying what I read so far from the book to my work.

I equated stores to webapps, and likes stores there are those who sell products and those who sell services -- which is true for webapps as well. There are sites whose main purpose is to promote products and there are also tons of sites who sell services like Digg, Google, and YouTube.

According to the book, one of the basics in marketing is finding costumers and for shops these which is ain't just all about ads. The author noted that he is not a believer in advertising anyway.

Boutique owners for example must layout their store in such a way that it's easy for potential customers to find all the products -- this may be done by arranging clothes by gender, sizes and lifestyle, same goes for supermarket, book stores and convenient stores like 7eleven and Ministop where each product is arranged by categories. This basically applies to webapps as well, we must categorize all the contents and functions then render them into link hierarchies and site maps where in it's easy for users to find and navigate the site. The easier it is to navigate the site; the more uses will browse your site. This is basically the same idea why malls has spacious corridors and wide open store window to allow people to window-shop easily.

Now imagine if you walk into a bookstore where all the books stacked randomly together and most of the shelves are blocking your path? IMHO I wouldn't last 5 seconds inside because its basically just takes to much effort to find the book that I'm looking so I might as well better off finding another bookstore.

As you see, these aspects has been inherent in those so called killer webapps as well.

Gmail made it easier to read and search threaded mails, Digg made it easy to categorize and rank stories, Flicker made it easy to categorize, browse and search pictures, Picasa made it easier to share Photos while Google Maps made it easier to navigate streets, give directions, and find places.

Another basics of marketing is how to make what you offer better than others, this can be done is many ways and one of my favorite is specialization. Basically a store can sell almost any product and target a broad audience, this is basically what we also do with webapps. We want traffic -- tons of traffic to our site.

Which is wrong.

Not all traffic is good because if we attract the wrong type of users, we will be spending more resources serving them than serving those target users that generates our revenue. For example malls attract people but not all of them would buy and they would take up space which would have been used by potential buyers -- people who are actively looking for the products they want.

Here is from my own experience. I went to All-Flip-Flops to buy my fiancee a pair of their latest slippers but when I got there, a crowd has already filled the store so most of us have to fall in line to enter the shop. As I observe, around 1 out to 30 people would buy a pair while others were just attracted to go there due to the crowd and they would stay there inside the shop for 5-15 minutes just browsing and trying out pairs. The rest of us who were in line got impatient in waiting and we decided to go somewhere else and get back later after the crown subsides (I went for lunch ^_^). When I got back the crowd were gone which gave enough room to browse call my fiancee without having to shout against the crowd noise and in the end I bought 3 pairs because I know I'm lousy when buying gifts for women -- which was a good thing I it did because my fiancee only liked 1 out of the 3 pairs I bought.

Same applies for webapps, you would rather have users in your site which contributes contents and pro-actively interact with users and refer other users to the site rather than attract hordes of lurkers whose attention span last only for a month. Also attracting the right users makes sure they would refer your site to their friends which would have similar pro-active tendencies. This is the new rule of Web2.0 -- subscriber base size isn't good enough anymore.

Therefore if you look at all of these, It is not just about programming skills anymore -- that trend is only true during dot com era.

Today a junior programmer can out perform a senior programmer given the right framework and the right attitude to actually use those framework and follow pseudo codes and standards.

Developers and engineers has also evolved, reaching beyond the system analysis and design -- we must also have proper knowledge of the business the models. Designers shouldn't just make nice layout's and graphics, they must understand the impact of those design decisions in the overall marketing strategy.

Jollibee "Sex" Scandal

Jollibee responds to PR nightmare on YouTube.