Yesterday, myself, Ramu, Thiru, Rashmin and Nitin were all at the breezy “outdoor smoke zone ” where Ramu is puffing off his smoke as usual and the rest of us have tea in our hands. It was our casual break time and we happened to hop into the discussion about why some companies like Apple are so successful and some other companies fail in shaping their future, despite lot of talent at both ground and higher management levels. While we knew nothing about Apple’s internal methodologies and practices, we did speculate what they might be doing to poise themselves for success.
There were general observations about Apple in that they don’t do 3 releases in a quarter and that they keep iterating or have strict specifications to be met to release one “worthy for the wait” product. And this product is great in usability, has great value for money and something that the customer would feel proud and love to possess it. I noted that this is in sharp contrast to the “agile” product strategy that most companies shout off — where you iterate and keep releasing often imperfect product features until they become nearly perfect, worthy enough of a release.
My thinking is that while this strategy of “iterate and release fast” works well for startups and companies with lesser customer base, this is not a very suitable option for companies with larger customer base, where you need to be creating traction amongst the user community and offer them a “high quality“, “fit-well-into-the-system“, “fully working” kind of releases. Agile proponents at work, push and stay pressed for the notion that you *should* release a product in disciplined intervals even if the product is incomplete. My opinion is that folks degraded the quality levels in their minds from “imperfect” to “nearly working” to suit the agile propaganda. Settling down on a “nearly” working solution is OK as it looks in the first go but gets worse when “nearly working” degrades to “somethings work and somethings don’t”. This is an inappropriate strategy for bigger companies where people look for value; they wouldn’t recommend or feel high of what they are using if the new features do not work well within the product.
In any case, we all seemed to agree upon one thing – “do not release something that does not have value in it“.
Thiru rightly pointed out that there are no shortage to ideas in any atmosphere, there are 100 ideas and we do the right thing to get into the next phase of prototyping some 30 of the glimmering ideas out of the 100. The problem is with how they get absorbed in the product, they get absorbed or pushed into the product as 30 different small modules/features – often in ways that they do not fit well into the ecosystem of something that is already working well; while companies like Apple should have been practising the art of keeping the user and whole product’s purpose in mind whenever they go through the rigorous process of assimilating ideas and pruning and incorporating them for use. This aspect is very important and essential for success.
Nitin brought out one more very important aspect that often occurs in bigger companies is the concept of “department”, popularly known as “departmentalization”. If you are told that your area of focus is only this small unit on the right side and the unit that is right below it belongs to some other department, then you literally have two different set of interests on the same page and likely to miss out on how the unification of these units together provide value to the user of the product. Factual! Companies like Apple are likely to not have such separation of job concerns and most likely that they do not operate as small individual companies within the larger company itself. It would be very interesting to know how they break their department walls in their day-to-day jobs and prime themselves for the “wholesome”ness.
Overall, assess and go back to the drawing board until there is a gestalt feel of the product that — the whole is larger than the sum of its parts.