SMEs and SaaS

Everyone is talking about the Small and Medium Enterprise (SME) and the Software as a Service (SaaS) space today. But is there enough understanding on what IT means for the SMEs and more importantly, if the market is really that huge, then why aren’t we seeing enough SaaS adoption in this space already?

For consistency’s sake, we need to define what a SME in India is given that there is no legal definition in the country to this yet. Let’s assume this to be an entity that has a turnover of under 1 billion (100 crores) INR. SMEs then by this definition contribute in terms of value to over 50% of the county’s total exports and account for over 95% of industrial units.  Secondly, they are growing in leaps and bounds across all sectors and have been instrumental to India’s growth story. Conservative estimates have put annual growth in the SME space at over 20% across all sectors for the last 2 years.

To serve this space means to play the volumes game. The typical client will require about 11-15 licenses of the software in question. Next, the SME requires a complete pay-as-you- go model with minimal upfront investment, minimal installation time, minimal training and a solution that is completely outsourced and managed by the software provider.  They don’t want the overhead of managing an IT department. Additionally the software should be able to integrate with third party customer software as required and data migration (both in-out and out-in) should be extremely simple.

Not enough IT players understand the SMB sector completely and therefore this also makes this an underserved market.  This is mainly because most players today don’t have a SME version of their software. Their version of software is the enterprise type that is traditionally heavyweight, expensive with large upfront fees and requires a try-to-implement-forever approach.  Also what is lacking is the SME’s ability to prioritize & understand what IT can do to facilitate their growth.  Therefore there is some amount of educating required in this space.

Of Contact Centers and CRM Evolution

A contact center’s objective is to combine all customer communications to provide a consistent and complete customer experience. Irrespective of the channel that the customer chooses to pursue: whether it is via a website or a discussion forum, a chat message, a short message service (SMS) or even a telephone call, the agent needs to be empowered to experience the customer request.

The contact center today is not there with this yet and will therefore have to develop multichannel capabilities that will need to be delivered as a standard feature and not as a complex customization. Online communities support need to proliferate. Blogs, discussion boards, social networking (with special emphasis on feedback management), wikis and collaboration tools to enable customer self service. And knowledge solutions, real-time analytics and decision support to enable the agent better serve the customer.  Customer data integration is an important requirement here that will enable a 360 degree view of the customer and her/his experiences.

Lets take a look at what technology, a contact center needs. A contact center has essentially the following components to it and some of them can be rather tightly coupled with the others.

   1. The Customer Interaction Management (CIM) suite of business applications that will manage the customer interaction process. Some amount of Business Process Management (BPM) will have to be inbuilt into the CRM for workflow management.
   2. Contact Center infrastructure, not restricted to Interactive Voice Response (IVR) systems, Computer Telephony Integration (CTI), SMS and Payment gateways alone.
   3. Optimization tools for the Contact Center such as call recording solutions, back-office software, training and quality assurance tools.
   4. Analytics tools to gather business intelligence and customer insight.

CRM applications are increasingly becoming more complex. Automated proactive alerts, BPM and integration support for multiple interfaces are now becoming standard features. While most CRMs today are primarily being used for handling service requests and as knowledge-base solutions, social networking support and predictive analytics are fast catching up.

Though it is a well known fact that any hosted CRM needs to have some sort of SaaS support for it to be successful, pure-play SaaS-based CRMs still have a long way to go before they can start dominating the CRM market. Today, Salesforce CRM is available only as SaaS. Microsoft Dynamics has now gone online and offers a cloud version as well. However, SaaS based CRMs have historically worked great for low-volume and simple contact centers and therefore there is a dying need for SaaS CRMs to have more complex and customizable features.

A paradigm shift is therefore waiting to happen with SaaS based CRM solutions. Gone are the days when the contact center was only about blended solutions, simple CRMs that primarily handled service requests, and IVRs. The market is out there and the future is waiting. After all, the objective of a good Contact Center is always to enhance the customer experience, isn’t it?

Why Do Indian Tech Product Companies Struggle?

This was in the news last week: technology product companies are coming of age in India. I was just wondering, we have been a software services powerhouse for quite some time and Bangalore is even known as India’s Silicon Valley. Hell, I even worked in one of the World’s largest software services company for almost 8 years. But how come, we don’t have a lot of technology product companies that are famous enough to be recognized worldwide? I then took up a stab at this and came up with the following:

The first and most obvious answer has to do with talent. While we have some of the best and brightest engineers all right, most of them would rather work at a large software services provider than work at a small unknown product startup. As if hiring wasn’t difficult enough already, the typical Indian mentality is to progress up to a non-technical path very quickly. After all, if I as a software programmer ever told my to-be in-laws that 10 years into my job, I am still into software programming and working for an unknown product startup, then it would simply be a matter of shock to them.  After all wasn’t I good enough to become an account manager or delivery manager at a TCS, Infosys or Wipro by then, or at least a project manager at one of these companies perhaps?

Having experienced and great software programmers in your technology product company is extremely critical to building good products. While not everyone has to be a superstar, you have to have the right mix of them.  Product companies also have a very strong engineering led approach that is missing in most service companies that typical have a very strong marketing driven approach.

Secondly, we never quite had the Steve Jobs, the Bill Gates and the Larry Elisions. These visionaries were extremely important in the advocacy that was required for a market to be created. The software services industry on the other hand had people such as a Narayana Murthy and a FC Kohli.

Thirdly, Indians also exhibit another typical behavior. We are more to do with think small and then scale up. We are true conformists to tradition. So therefore most of us have never been trained to think disruptively. This is essential to building a successful global products company and Zoho has done this so well with their SaaS strategy which they did much before Google and Microsoft could launch their office products online.

Fourthly, regulation and infrastructure has still catching up to do. A 512 Kbps Internet bandwidth connection is still un-available in some of India’s tier 2 and 3 cities and even if it is, it is either not extremely affordable or reliable. On the telephony front, regulations have been a constant inhibitor to inhibition. Coming from a customer services solutioning standpoint, these 2 stand out to me first: 3G is yet to take off on a serious note and VoIP calling to telephones are still a strict no-no.

However for people who understand all this, India clearly has the cost advantage. Much lesser capital is required to launch a product startup today in India than in most other developed countries. Also if you are launching a product company in India that Is specific to Indian requirements only, which is actually a great idea to pursue given that the Indian economy is doing better than any other developed countries currently, then you need to make the markets work for you in India by adding localization to your products.

Agile for Startups

This is a simple theory: A "process" is merely the way one does their tasks. A process improvement then simply is about doing them better. Agile processes simply put are ways of working better and the iterative process enables responding to changes quickly using a business approach that aligns product development with customer need.

However, this may not be as simple to implement in the startup context. For one, most startups have the single most pressing need when they begin: they need their first client. Money talks and revenues are the clearest evidence that the startup is tackling the correct problem. Therefore the early phase startup often struggles with innovation as building to sell often takes precedence over building it well. Secondly demo-able working software is damn important and therefore shorter the sprint cycle, the better it works. A recommended sprint cycle for startups is under a week where-in feature releases are done on a weekly basis at maximum. Longer sprint cycles have been shown to actually impact flexibility. Apparently pair programming doesn't work too well for startups either, simply because it’s too expensive. Pair programming for sure brings up the quality of code to much higher levels than without it. However this comes at a cost to startups given the apparent loss in productivity amid their desperation to ship out a product and recognize revenues as soon as possible.

The importance of communication in an agile process cannot be under-emphasized and this remains an issue even for small start-ups. More so, collaboration has been a challenge for the startup that isn't naturally ready to quite adopt the agile culture which brings us to another moot point: agile processes are being introduced in startups without any attention having being given to the fundamental need for a culture shift.

A mix of the following factors typically indicates the best environment for adopting agile: a team of mature/senior developers, small teams (there are potential problems to scaling agile) and a culture that thrives on some amount of disorder.  On the other hand, a waterfall approach is best where a project is mission critical, has huge teams with a large proportion of junior developers and where the working culture is such that it requires order.

Lean Startup is a new methodology typically being practiced by the new startup and this technique combines the offerings of Agile Software Development and Customer Development using already existing software platforms that are usually of the free-and-open-source-software (FOSS) type.

This technique falls back on quick prototyping that are designed to evaluate market assumptions, and uses regular and frequent customer response to evolve faster (by evaluating and avoiding erroneous market assumptions as early as possible). It is rather common to see Lean Startups deploy code multiple times a day, using a practice that has come to be known as Continuous Deployment. One startup out there does as many as 50 deployments a day.  Focus is then thrown on the minimum viable product which then is a collection of only those features that allows for a product to be deployed (and no more).

Organizational Design For Product Companies

A good and effective organizational structure enables an organization to function more effectively and with greater efficiency. Also organizational structure differs from industry to industry and per Edwards Demming, organizational design depends not only on what the organization is doing today but also upon what the organization will be doing tomorrow.
 

For software product organizations, the organization can be divided along 3 major tracks: the marketing track (market research & marketing analysis), the product management and design track (information architecture, interaction design, visual design & usability engineering) and the actual product development track (architecture, engineering, project management, SaaS delivery & even operations).  In product companies, there is also often conflict between the marketing/product managers group and the product development group. While the former typically pushes for early releases, the other focuses on the technical integrity of the product more than anything.  Therefore conflict is built into the design of the organization itself and the absence of conflict may actually give rise to sub-optimal results.
 

Startup organizations are a little different in that they are typically smaller in size and that the personalities and individual skill sets involved actually matter more than the organization structure itself. So therefore roles and responsibilities here are even more important than the right organization structure. In fact, with good intentions aka strong organization culture, any organizational structure is workable and the organization can be designed around the strengths of individual leaders.
 

An organization template I have seen for organizations with focus on innovation and problem solving (as it is with product organizations) is team based. The management style is participative, goals are set mutually and the reward system is in the form of a team bonus. In fact, organizations that go as far as to allow their employees to self-organize and form teams have actually become much more effective and efficient. One company I know of goes as far as to have uniform mobile workstations with state-of-the-art networked computers. People here are always mobile and their office has become an environment that maximizes collaboration and execution.  Remember the ‘skunk works’ concept whose origins lies in at Lockheed Burbank? This concept is now widely used in product organizations and describes an organization that is given a high degree of autonomy and is unhampered by bureaucracy.

Of Lateral Thinking and 6 Hats

Creativity should be producible on demand and should not be left to mere chance or so is what Dr. Edward De Bono truly believes in. The creator of lateral thinking and various other thinking tools has given to the World today what has now been adopted by schools from over 20 countries as part of the their curriculum. Large organizations such as Prudential, Boeing, Siemens, Honeywell, Motorola, Eli Lily, Fidelity, NASA, IBM and Texas Instruments are wide users of the 6 hats methodology that I will briefly outline here.

Per De Bono, critical thinking has core limitations in the sense that it is more concerned with discovering what is right and wrong and less to do with movement of ideas and their creation. He takes on the Great Gang of 3: Socrates, Aristotle and Plato and speaks about idea generating tools such as random entry, provocation, challenge, concept fan and disproving. In a random entry approach, an object can be chosen at random and associated with the problem at hand. Say for example, we can choose a fax machine for designing a website better. Since a fax machine sends content to cell-phones directly perhaps the same can be done for websites that can directly send content to users via RSS feeds. The challenge idea generation tool asks why in order to generate fresh ideas. To illustrate using an example, why can't we have planes land on their heads? Though the idea may seem outrageous at the onset, it has its benefits: for one everybody would also have their seat belts on. For another, the pilots always would be able to see where they land. In fact the latter was incorporated as a design in one of the fighter plans deployed for the Vietnam War.

Lateral Thinking and 6 Hats have to do with exploration: exploration of subjects where all participants can contribute with facts, new ideas and feelings. As per the 6 hats thinking framework, there are 5 distinct states in which the brain can be sensitized that correspond to 5 hats and 1 hat is used for moderating all of these 5 states. Why hat? Because, putting on a hat is a very deliberate process. Because it is part of a uniform (a woman wears the hat of a homemaker, a mother, an executive at different times of the day). And most importantly the ego goes on vacation when you deliberately in one of these states and nobody can call you crazy anymore. Each of the hats has been given a distinct color and functionality is expressed via this.

The 6 hats are white, black, yellow, green, red and blue. White stands for paper. It concerns information or key absences of information and is used to segregate facts from opinions. Black is the color of the robe that a stern judge wears. Participants identify barriers, hazards, risks and other negative connotations when wearing this hat. This is the most powerful of all the hats but should never be overused. Yellow is the color of sunshine & optimism. It Identifies benefits and is the opposite of black. Green stands for fertility. Wearing this, participants think new thoughts for the sake of identifying new possibilities itself. Red is color of fire and warmth. Participants state their feelings and gut instincts when wearing this hat and this hat is used as a quick system of voting. Generally this hat is never used for more than a minute at a time. Blue, the last hat, is the color of the Sky. This is the hat under which all participants discuss the thinking process. The facilitator will generally wear it throughout the 6 hats discussion.

There is no hard and fast rule in hat selection and their pacing for meetings. Adapt as necessary. Meetings generally start with Blue and end with Blue. While same hats can be used multiple times in a single discussion, there are some hats which may never be chosen for a particular type of meeting. Also one can do a hat on a hat. Here are some examples of hat selections. Pace and sequence hats rather carefully. Time limits prevent participants from rambling off.
Initial Ideas - Blue, White, Green, Blue
Choosing between alternatives - Blue, White, Yellow, Black, Red, Blue
Quick Feedback - Blue, Black, Green, Blue
Process Improvement - Blue, White, Yellow, Black, Green, Red, Blue
Solving Problems - Blue, White, Green, Red, Yellow, Black, Green, Blue
Performance Review - Blue, Red, White, Yellow, Black, Green, Red, Blue

The entire idea is to go beyond criticism, pessimistic or argumentative thinking. Going beyond this is right v/s this is wrong or beyond gut feel and emotion. The objective here is to focus your thinking by using 1 hat at a time and it serves as a convenient Mechanism for ‘Switching Gears'. The framework aims to create awareness that there are multiple perspectives at hand and not be worried about speaking one's mind.

It is to be noted that the 6 hats framework is not an end in itself. Often, there are multiple iterations and detailed reports are the outcome of a session which are then further analyzed to solve the problem at hand.