Category Archives: Product Innovation

Why user stories make sense?

User story is a popular mechanism used by most agile methodologies to communicate user requirements. Actually, this is only partially true. User stories are meant to be a placeholder to initiate an early conversation between the product owner and the team on key hypotheses so that a quick validation of them could be done to refine/confirm/reject our understanding of what the customer really wants. To that end, user stories are not anything like the requirements of yesterday – they are not even remotely meant to be complete/comprehensive and so on. 

The reason user stories (and not ‘well-formed’ requirements, if that is ever possible) makes sense is because we human beings are not experts in following the written word, and are likely to misinterpret requirements even when they are explicitly written down, especially when the communication is a one-time event and not an ongoing process. (if you don’t believe this, just visit this interesting site http://www.cakewrecks.com/ that celebrates real-life examples of how something as simple as icing on the cake can go horribly wrong despite really simple and absolutely clear instructions!). And we are talking about building complex mission-critical systems that must operate 24/7 with top speed and efficiency. If only the written word could be consistently understood by the receiver as intended by its author… 

On the other hand, if there is a continuous two-way dialog between the product owner and the agile team, such purposeful brevity leads to curiosity which then leads to a constantly improving and better shared understanding that refines as the product gets developed incrementally and gets periodic user feedback. 

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer's wants and needs.

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer’s wants and needs.

The key benefit of user stories is that instead of waiting for weeks (even months!) to get a fully-bloated and rather unprioritized PRD which is supposed to have fully-baked requirements while the development team sits idle all this time, is that identifying highest priority user stories and using them  to develop a prioritized product backlog allows the teams to get started much earlier and start developing features which could then be put out in front of customers to get real feedback (as opposed to individual ‘opinions’ that might/not best guide us in an uncertain environment). This is especially important because in the past, when the world was little less complex and much more underserved. I purposefully use this term ‘underserved’ because it is not that people have suddenly become much more demanding about what they like or not, but were just told there were exactly three carmakers to choose from, or just two operating systems to choose from, and so on. However, with rapid advancement of computing paradigms and constantly lowering cost of ubiquitous communication devices, they suddenly have the opportunity to demand what they want, and hence classical ‘forecast’ models of requirements elicitation, design or production (at least in the manufacturing sense) don’t work so effectively as much as the newer ‘feedback’ driven models that allow for developing key hypotheses (and not hard requirements carved in stone) which could then be quickly and cheaply delivered as ‘done’ features so that customers could tell us if they like them or not. Based on such valuable customer feedback, the team could iterate to either refine the feature, or to pivot, as the case might be. In the past, this might take the entire product gestation cycle, by which time, many, if not most, things might have undergone significant changes, and the entire development costs being sunk by that time, not to mention complete loss of any window of opportunity.

As Facebook says – Done is better than perfect. User stories allows developing a small slice of the product without really perfecting the entire product, but facilitates the process of validated learning that eventually helps develop a product with much higher chances of meeting customer needs.

In today’s world, you probably might not have the luxury of having investors wait multiple years for an exit, or customer waiting several quarters for a perfect product when the competition is willing to serve them faster (even letting them lay their hands on an earlier version and give feedback thus making customers a co-creator of the product), or employees working month after month without getting any meaningful feedback from customers. And we know that absence of any feedback eventually leads to erosion of trust. Incremental product development could help you bridge such trust deficit by delivering highest value to customers early and periodically, and user stories might help you get your project a quickstart.

Does your process help you preserve status quo, or deliver some kick-ass skunk works?

Problem-solving in the past has been dominated by methods involving rigorous and meticulous planning and flawless execution – something that has been questioned, largely by results (or rather the absence of it) in the recent years, if that is (still) the best approach when there are so many moving parts and the external world changes in a blink. We frequently ‘blame’ old practices of assembly plant-style waterfall days where it took years to get a project team to jump multiple hoops and just get a project done – in most cases, hopelessly delayed, unacceptable quality and overbudget. Building process frameworks was once thought to be the panacea for all these maladies, especially in mid- to late-nineties, as we say with a series of processes – CMM, ISO, BPR, and so on… And thus, birth of agile movement came as a big relief and promise to speed and improve things up a bit. The idea of starting out with just enough requirements and iterating along with way had an intuitive appeal in this VUCA world, where no one had complete information nor all the time to wait for that perfect moment of epiphany – because that epiphany was a moving target in reality. With more efforts to design a solution, we learnt a bit more about the problem and this became an unending spiral – which was not necessarily a bad thing, but the gated processes didn’t provide much guidance on how to address it effectively. Clearly, we needed nimble processes that allowed for more iterative development without making too much commitment upfront, especially that couldn’t be easily changed downstream, and a matching sociological process that allowed teams to build unconditional levels of trust among themselves that stimulated collaboration and made them operate at the speed of light. Many of these ideas have emerged from multiple disciplines such as software development, behavioral psychology, team dynamics, systems thinking and leadership, just to name a few, in the last ten to fifteen years, and have led to statistically significant successes in several domains. However, as we are learning, some of these practices have been around for decades – just that we haven’t ‘discovered’ them just yet. I just found out one such great example this weekend – the Skunk Works. Wikipedia defines it as blow:

skunkworks project is one typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation.[1] Everett Rogers defines skunkworks as follows: “[It] is an especially enriched environment that is intended to help a small group of individuals design a new idea by escaping routine organizational procedures. The R&D workers in a skunkworks are usually highly selected, given special resources, and work on a crash basis to create an innovation.” [2]

Clearly, developing skunk works is not a business as usual approach. It is a special quarantined environment created for the sole purpose to incubate a radically new idea under special conditions that catalyze teamwork and collaboration and accelerate innovation. Another definition describes it as:

A skunkworks (also known as Skunk Works) is a small group of people who work on a project in an unconventional way. The group’s purpose is to develop something quickly with minimal management constraints. Skunkworks are often used to initially roll out a product or service that thereafter will be developed according to usual business processes.

However, there is more to Skunk Works than this. Starting out in 1943, Skunk Works at Lockheed owes its foundation to a mantra of “quick, quiet and quality” that still continues after seventy years. The first project, XP-80 Shooting Star jet fighter was designed and built in only 143 days – seven days less than required and without any contract or an official submittal process! The formal contract for XP-80 did not arrive at Lockheed until Oct 16, 1943; four months after the work had already b

What is your skunk works process?

What is your skunk works process?

egun! However, when we look at its operational record, it was delayed – it was pressed into service only towards the end of WWII – something that clearly didn’t meet its original objective. There were many accidents, and several ace test pilots were killed on the test flights. Given that there were several innovation on this ‘product’ there seems to be a strong flavor of fail fast, fail cheap and keep iterating – even though the loss of human lives seems to be tragic and perhaps avoidable in some cases. However, this blog post is more about the underlying process and associated principles that led to such innovation in the first place. Upon reading further, I was impressed by its founder, Clarence “Kelly” L Johnson, who started it all. He broke the rules, challenging the then bureaucratic system that stifled innovation and hindered progress. I think these rules have never been so important ever before… Kelly’s 14 Rules and Practices Kelly wrote down these 14 rules that led to the successful culture of innovation at Skunk Works at Lockheed. Let’s study them and understand their context in today’s workplace, and if our practices address them effectively:

1. The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.

There must be a clear-cut responsibility, ownership and accountability lest there be diffusion of responsibility leading to confusion, chaos and associated symptoms of delays and poor quality. As much as we need self-organizing teams with democratic decision-making process, we still need to have a clearly defined ownership – someone who is tasked with breaking all rules to get the job done! Agile teams make the team responsible for delivering to its commitments, and agile thought process doesn’t generally support the notion of a ‘manager’ but a product owner is still responsible for eventual success of the product. Yes, the notion of what constitues work for a manager will keep changing with the times, but in some shape or form, I believe there has to be a sense of final responsibility for the outcome.

2. Strong but small project offices must be provided both by the military and industry.

There is no denying the importance of reducing management and administrative overheads but making them more effective. Bloated models that create large hierarchies are on a wane, and new-age program management is all about leadership by influence rather than using positional power to get the job done. Scrum takes a leaf from servent leadership to describe the role of scrummaster,  which is a significant departure from having a manager with positional power to get the job done.

3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

More than the ability to actually work with small teams is the recognition that having a small team is much more productive and effective compared to the “so-called normal systems”. Of course, not all problems can be solved by having small teams, especially if one is looking to complete them faster than the competition, but one needs to weigh-in all the factors, but definitely in favor of small teams. Agile makes a strong case for small teams.

4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.

This sees like making big commitments upfront is being deemphasized. This principle sounds very simple to what Lean Construction Institute, several decades later enunciated when it said, “…design decisions will be deferred until the last responsible moment if doing so offers an opportunity to increase customer value.” Agile thinking is very much aligned to avoid making heavyweight commitments upstream, especially when there is a heavy cost of change them later, and given the rapid pace of changes around us, it is certainly not a hypothetical and extremely rare situation for which we are delaying making the decision.

5. There must be a minimum number of reports required, but important work must be recorded thoroughly.

It’s so funny to imagine that in the era of typewriters too, they were sick of reports! I think there is nothing that can justify having a disproportionate number of reports under any circumstances. The old thinking was to increase the micromanagement when in crisis, or even otherwise (I fondly remember a General Manager in at an old job who would come to our cubicle every hour and check the status update on ‘design document’!). I think asking for a number of reports smacks of Theory X, where the underlying assumption is that unless you make people work, they won’t take initiative and most certainly won’t assume responsibility. So, the hierarchy gets created simply for asking for more frequent status updates, and since the higher levels wield considerable power in deciding renumeration and career progression for the ‘lowly underlings’, who do you think wins in the end? Certainly not the project, I guess!

6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.

I see no reason this doesn’t apply in any possible context. Any sponsor needs to know how is the team doing. The team owes it back to their stakeholders, management and customers to keep them posted of what is keeping them busy, and when are they likely to be finally done. When I look at agile thought movement, there was an almost anti-establishment feeling that was so palpable in numerous views on dozens of discussion forums, that it is not a surprise that agile didn’t find too many favors with ‘management’. I don’t think it is called prudent wisdom to take money from a project sponsor and tell them they are ‘chickens’ :). Thankfully, I see more maturity among agile thought leaders today, and any level of project team owes it to keep their first-level of ‘customers’ engaged through the development phase.

7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.

There was a time when people outsourced to save a few dollars. Not anymore. With such tight integration of your suppliers in your value chain, it is not about cost anymore – they need to have much more than their skin in the game. A strategic project can’t afford to have relationships that seldom go beyond conventional commercial considerations. Perhaps the best-known example is how Toyota treats its suppliers – “…we believe in developing mutually beneficial, long-term relationships based on mutual trust. To foster that trust, we pursue close and wide-ranging communication with suppliers.” and “…We at Toyota rely on outside suppliers for most of the parts and materials in the vehicles we make. Every step in making Toyotas, from development to production, consists of joint work with suppliers. The suppliers we seek are companies that have the will and the ability to become active partners with us. We are looking for suppliers who possess world-class competitiveness in terms of qualitycostdelivery, and technological capabilities.“. I don’t believe without such strong win-win mindset, a company can succeed in achieving the agility required to compete at big game.

8. The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection.

Inspection is essentially a waste. Deming was vociferous in his views on this “Principle#3Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”.  Clearly, there is no way we are ever going to completely do away with any form of inspections – there are far too many normal and special variations in any process to be able to run subsequent part of the process in autopilot. However, a more conscious effect to eliminate duplicacy in inspections not only improve the value stream but also fosters the culture of trust and interdependence among all players which can eventually help everyone run faster rather.

9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.

If you can test components of an aircraft in initial stages, what stops you from doing the same for, say, software? Some of the biggest opposition to early testing comes from enterprise software and from software platforms – that they can’t possibly test half-baked functionality? However, nothing could be further from truth. If we are not testing product and its components early enough, we are accumulating significant risks downstream that can force untold miseries during the big-bang integration. I don’t think anyone disputes it seriously today.

10. The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.

I think there is nothing wrong with this idea. However, there is a presumption of technological stability that doesn’t hold so well anymore. The pace at which newer technology gets productized is unprecedented, and one can’t sit comfortably having zeroed-into the hardware platform at the start of the project. However, there are surely classes of problems where for regulatory reasons, the technology cycles are much longer, and hence it makes sense to be cognizant of them. However, the advise is generic enough to be universally applicable for all class of problems.

11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.

Simply put, if you don’t pay your suppliers on-time, they will have less motivation to work on innovating the next big thing and more to worry about how to pay salaries to their staff! Perhaps this was a big deal in early 40s that Kelly has to write it down! However, lack of funds can surely cripple or kill a project and hence enough care must be exercised, commensurate to the project size and impact, that ensures this is not on critical path. 

12. There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

Again, Deming has some useful advise here too “Principle #4End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.“.  While one can debate if having one single supplier is a wise thing to do, there is no doubt that one needs to build a long-term relationship on a foundation of loyalty and trust. A relationship on short-term commercial interests might hold critical projects to ransom in times of crisis, and control or coercion might  backfire. However, trust will almost always be reciprocated with accountability.

13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.

This might be more relevant in military, but in true innovation projects where a mere whiff of what are the designers thinking is likely to be significant competitive intelligence in the hands of competitors, a sense of maintaining right amount of secrecy is not unusual. Apple is well-known to maintain absolute secrecy about its new products, and goes to any lengths to protect its competitive advantage. I also think it is not just about the secrecy due to competitive reasons, a little bit of ‘confidentiality’ might actually increase the amount of buy-in from team members and make them more ‘possessive’ about their work, making them all come together. However, it’s clearly a double-edged sword, and one must choose what works for them.

14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.

I think Kelly was either a battle-scarred veteran of performance appraisal systems (back then!) or a visionary to be able to call a spade a spade! Perhaps the conventional systems at that time rewarded people for the number of personnel supervised, which might have no bearing on ability to innovate or deliver performance. This might even be his pet peeve, because in an earlier principle, Kelly has called for smaller teams, and here he is asking for rewards to be performance-based and not based on the team size. As we have seen in last few decades, power-hungry managers have only worked towards building large self-serving empires with no relation to the nature of work. In the end, such pyramid structures has become just that pyramid-shaped ponzi schemes. However, today’s social norms and professional values don’t support such stone-age thinking, and hence, this is only a gentle reminder to today’s managers. However, it must have been very profound at the time Kelly jotted this down. While reading these 14 principles, I couldn’t help but admire the genius of the man behind it – Kelly was not only on the top of his game, he was willing to literally fight the establishment to get his job done. If he perceived his process as stifling innovation, he was willing to talk about it, and make necessary changes commensurate to what was expected of him. A lot of people take refuge under and behind the process frameworks without thinking if it meets their needs. The thought process is that you buy a certain level of performance with established processes, and hence if you fail, it must be due to the process and not entirely because of you. This gets aggravated in organizations that apportion praise on the process and management, and failure on the managers and the individuals. As a result, people stop sticking their necks out, and instead choose the trudge along the status quo. But think about it – are you paid to preserve status quo, or to push the thinking, bring about changes, break some china…in short, deliver some skunk works… So, does your process help you preserve status quo, or deliver some kick-ass skunk works?

Seeking submissions on New Product Development and Product Management in Agile world for #AgileIndia2012

Agile Alliance has announced Agile India 2012 in Bangalore, India in Feb 2012. First of all, Naresh deserves kudos for all his untiring efforts last several years bringing up and building a robust multi-city agile software community in India, and deserves all congratulations bringing the flagship Agile conference to India. As the Chair for Agile India 2012, we couldn’t have had anyone better than Naresh to lead this.

AgileIndia2012 comes to Bangalore, India in Feb 2012
AgileIndia2012 comes to Bangalore, India in Feb 2012

I had proposed the stage on Agile for New Product Development (NPD). Annu Augustine (@annua) proposed a stage on Product Management in Agile world. The organizing team proposed merging these two and we all agreed that was a great idea to create a stage on “New Product Development and Product Management in Agile world”. I believe the time is ripe to elevate agile thought process outside the software development team and apply it to the big picture – the end to end product development. We often see significant ‘productivity’ claims from software teams adopting agile practices. However, there are several other key functions involved in product development – product management, user design, marketing, sales, technical documentation, beta programs, manufacturing (at least for systems companies), and so on. If software team optimizes its software process, it is good. However, it is necessary but not sufficient to achieve end-to-end agility. If rest of the organization doesn’t change its thought process, we just end up moving the ‘constraint’ from software development to something else, and the true gains of agility might not get realized at the organization level.

In this stage, we are now seeking perspectives, experiences, insights and groundbreaking ideas from practitioners and thinkers on how they have applied the spirit of agility to create new products that have led to unprecedented and extraordinary market success compared to their previous conventional practices. Specifically, we are looking for proofpoints from the marketplace to demonstrate how software team’s agility was directly visible in business results. We want to know what you learnt from your experiences applying agility at every step of the new product development to create customer delight experiences. We want to know how did you manage to crash your time to market to deliver innovative solutions that delighted your customers, or made significant impact to their topline.

We are still working on setting up the infrastructure for submitting the ideas, but in true agile letter and spirit, we want to evolve this stage as we go. Write back to Annu or me to share your views and ideas so that we can co-evolve this stage. We want to dogfood the spirit of this session by incorporating your feedback to make this stage more useful to everyone. You can find more details on Agile India 2012 here.

Interest to submit a proposal? Click here.

Let’s get going…

How do you manage a Disruption ?

 

The world of new product development is (NPD) is an extremely challenging one, and while the output of such an endeavor is never a sureshot guarantee, the journey itself is immensely fulfilling. Edison was reportedly asked by his assistant on not being successful with his electric bulb work despite two years of efforts, something that Edison could not understand… “what failure…we have discovered so many ways how an electric bulb won’t work”.  In a corporate context, however, we all must work within boundaries of finite resources (time, resources, people, etc.) to create the next telephone, the next microwave, the next LCD television, the next Windows or the next Google. It is perhaps the dream of every professional to be part of such life-altering Greenfield projects (many times also referred to as the ‘Version One’ in software world) and make a lasting impact on world around us.

However, innovation doesn’t only happen in such large doses. It also happens in small doses: small-small daily changes, enhancements, modifications, improvements done in thousands and millions of places in a product such that the final impact is as breathtaking as the version one. In fact, some might consider such ‘brownfield’ effort as much, or even more, challenging than the Greenfield because in a brownfield effort, one must work around constraints and ground realities that are not up for change. Irrespective, there are adequate challenges and learning opportunities in any endeavor that creates, or improves upon an existing product or service. This is the opportunity for a technical professional to sometimes work as an artist and make her lasting impression on the canvas, while also working as a child building grand designs of lego building blocks. As a manager, the fun is little more challenging than for others J

While a traditional project manager applies all his knowledge and skills to synthesize all tasks, inputs, resources and constraints to build a plan to execute the project, a project manager working on a new product development endeavor must recognize that the work has innate challenges, and quite often the task is a wicked problem.  There is an element of risk, a certain amount of discovery that in fact makes working on such a project worthwhile. It is not by accident that the best talent in the world gets drawn to companies that routinely engage in such work. Welcome to the world where the only objective is to create disruption ! However, traditional project management is all about applying time-tested sound principles and practices to bring a project under control and achieve all its goals. However, managing a disruptive endeavor is much more than that – to begin with, not all goals might be known. Some risks might be completely immitigable, and one must simply learn to accept them. Many of the activities in an NPD project might actually be undertaken for the first time, and hence for all practical purposes is more of research work than a mere development.  In short, one might not be able to apply all practices of traditional project management in letter and spirit and yet be able to create the right disruption that is envisaged. However, it is not an impossible problem.

In PMI NPDSIG, we are working towards creating a community of researchers and practitioners and enrich the body of knowledge by learning newer and innovative methods of problem-solving, shortening the cycle times, improving product reliability, improving the ability to manage such a project and so on. While recognizing the inherent challenges such an endeavor poses, and to an extent might be at crossroads with a very straightjacket approach to project management, we strive to explore the middle path – how best to apply principles of project management to a new product development endeavor, and meet the dual objectives.

I am part of the NPDSIG team for 2009, and as Vice Chair for Communications, I have an extremely interesting and challenging role. Here is how I propose to work on them:

  • PMI NPDSIG publishes a newsletter, Project Management Innovations, for which I serve as the editor. It is published electronically four times a year. I propose to take up themes for each of those issues and scout for talent all over the world to share their opinion, experiences and trends in that area. The idea is to learn from different fields and understand how well practices from one area could be used to solve similar-looking problems in another. Some of the themes I am exploring are
  • Lean: how well Toyota’s Lean Production System is being used in creating other innovative products and services
  • Green: we often tend to associate green only with companies that consume hydrocarbons, but in a broader sense, several companies are making invaluable contributions by adopting green in their technologies
  • Innovation: while our field of work is all about innovation, how the process of innovation is managed, how are organizations able to reduce the risks and lead times, etc.
  • Human: we exist to serve the society, and so must our products. How do organizations create technologies that, for example, enable the poorest of the poor to become literates, acquire practical skills to earn a livelihood and become self-sufficient, how has mobile telephony changed the lives of millions of poor people around the world and empowered them as a first-class citizen of this world.

As an editor, I shall be working with potential authors and SIG administrator on planning the release, review and proof-read articles, etc.

  • The discussion list has over 900 members, but there is practically no activity on that list. We need to revive it by involving list members in various discussions, share thoughts and articles, etc. While this requires a team effort, the need is to identify subject experts who can initiate conversations, offer conflicting opinions, cross-pollinate ideas and involve list members by listening to their problems, their experiences. The idea is not to take the high road by proclaiming ourselves as ‘experts’ but by facilitating thought process, we aim to serve the listmembers.
  • I would like to conduct one or two events in 2009 with PMI Bangalore Chapter and also with IEEE Technology Management Council (TMC) Bangalore chapter of which, I am the Chair for 2009. IEEE celebrates 125th anniversary in 2009 and among eight global cities, Bangalore is chosen as one of them and will have major events (http://www.ieee125.org/). I propose to conduct some event along with IEEE TMC Bangalore chapter that helps us build bridges within IEEE community as well as (hopefully) open doors for more membership. I don’t know if that is possible, and if yes, what would be a budget for this, but I thought of sharing my thoughts here so that you could advise on what is possible.
  • On the lines of PDMA and our very own PMBoK, I would like our team to undertake an effort to codify the NPD knowledge in context of project management profession. This codification could also be a reflection of the state of art in this field, and serves as a quick-learning tool into the basic tenets of NPD, tools and resources, best practices and emerging trends. This could be made freely available resource for the advancement of our field.

If you are a professional involved in the exciting world of new product development, then join us for mutual learning.

What is wrong with Gmail ? …and why is LinkedIn going down the same path ?

Those on Gmail have my heartfelt sympathies. Additionally, if you also use LinkedIn, welcome to hell !

Let’s first talk about Gmail. Have you seen what’s happening off-late: gmail is getting painfully slower by the hour, it freezes every now and then,.. I am now seriously thinking of switching over to a ‘simple’ webmail (does anyone know any webmail without any GUI ?)..maybe back to my old Hotmail account 🙂 or one of those not-so-fancy mails that don’t compromise the basic functions of a webmail over its other commercial interests, howsoever seductive they might be.

When Gmail came, it wanted to create an ‘exclusive club’ of gmail users – if you were a nobody (like I was, and still am, but I was a bigger nobody back then), you just could not sign-up by yourself, unless invited by a kind friend ! The official reason was that they wanted to reduce spam – the logic being: friends will get their friends on gmail, and since friends won’t spam their friends, there won’t ever be any spam on gmail. How naive…rather, how stupid ! Today I have more mails in my  gmail spam than on all my other mails put together ! But then, I am getting ahead of myself. Let’s get back to the story. Gmail created this exclusive club which for a moment seemed to hold itself admirably well against spam. People thought the magic was working. However, nothing could be far from the truth. The spam was not there not because of this friends thingy, but because no one new those new email ids ! Once people came on gmail, they started flaunting their ‘exclusive’ mail ids, registering here and there on the net, and the next thing people woke up to was their inbox full of spam (ok, in gmail world, the ‘inbox’ would probably never be full, but then you do get the point). However, I must compliment gmail guys on the efficiency of their spam filter – it works pretty well.

However, spam is not the biggest problem plaguing gmail today. The biggest problem is its slow performance , and that you are paying for this slowness ! When you open an email, adrenalin starts flowing through gmail’s celebrated algorithms – they go through your entire mail (don’t be shocked by this machine-led invasion on your privacy) and try to match words in your email with those from their paid-search so that those paid ads / targetted ads could be directed at your screen. Gmail doesn’t do it because it loves you – they do it because popping every ad on your screen makes them some money, and if you happen to click on one of those annoying ads, google’s cash registers get few more cents 🙂

The final problem is a classic product management problem. To their credit, gmail has not fallen prey to that mindset yet, but it is still relevant for this discussion (and actually, the #1 reason behind LinkedIn problem discussed ahead). When Hotmail came, it appealed simply because it was the first one – it was a highly disruptive force. Very soon, we had the copycats marching down as fast as they could in the race to get other users on the net to sign up on their service. Mind you, a free service with no revenue model whatsoever. Over time, everyone started competing with each other, and today, almost every webmail looks very similar to any other webmail – so much so, that only the URL is different ! What started as a simple feature on product manager’s wishlist got diluted down so much that eventually there was no differentiation left anymore. Gmail does stand proudly on the victory stand so far (for who has seen tomorrow ?), having resisted the pressure to mimic other webmails. Why, even the simple concept of folders (other than inbox, sent and trash) have not yet been introduced in gmail. Instead, the concept of ‘labels’ is something that were are slowly getting used to live with. However, another notable product has fallen very cheaply to this sin.

So, what is LinkedIn doing these days. In the race to overnight lose its virginity to mainstream pulp features, it is working overtime to fast lose its billing as a no-nonsense social networking platform for professionals (did I say ‘senior professionals’). It is meekly surrendering to those wal-mart features that make it mimic the cheap Made-in-China fakes, in the sense that you can’t complain that LinkedIn doesn’t have this feature…anymore. But, and that is a big BUT…doesn LinkedIn have to do it ? I mean, does an average user on LinkedIn want those cheap features (he has several other options). The fact he is on LinkedIn is because of the ‘elite’ features that it offers. Now that it offers all orkut-ish features, it is indeed worth introspecting what is the value he is getting on LinkedIn, notwithstanding a free service. Now you can inform people of your travel plans, share your blogs,  events with people on your network…and the worst part is none of them work. The events app can’t still list events in Bangalore when I check that option. The blog app takes an eternity to list anything that looks like a blog for all of my 600+ connections and how much I wish I could ‘control’ what I wanted to see. The net result is that my LinkedIn is slower, never shows the right information, and shows me all information that I don’t care ! Could they please work those bugs and create a better way for me to control what I care to see…and did I say, I get to control it !

My feeling is what we saw in webmail warfare which them happened to browsers (and still continuing) has now entered next round with social networking platforms. All started with their own unique value preposition, but succumbed to roadside greed and are now copying features like maniac in a race to outsmart the one ahead in race. The all want to suddenly offer uploading pictures, sharing music, video, chat, travel information, where you have been on earth, books that you like, movies that you like, schools you have been to, and so on. What they don’t realize is that people who came to their site came and stayed because they liked something unique about their product and service. They might not like (or want to use) all those pulp features that were anyway available on other sites even when they came to this site in the first place. And to satisfy their urge to use those pulp features, they are most probably already on those sites as well. So, by bundling those pulp features, you are only probably diluting your offering. Also, it is depriving you of your precious R&D dollars who could have been doing something little more useful, like creating brand-new features out of thin air to continue maintaining your competitive advantage. But then, common sense is still not so common a commodity !

Here is my prediction: in next two to three years, every mainstream social networking platform will look the same. The innovation will gradually die, and the blind race to mimic other players will lead to further blunting of the axe. Of course, no one will still make any money from this service – for there are already so many free platforms a dime a dozen that if you even as much as dream to make your service a paid service, people will soon mass migrate and find another option. Copying the webmail product management approach in social networking platforms will make the suffering a little more painful…not for them…but for you as a user.