The Mighty Apple

'Apple' has become a common consumer brand here. According to the report by CNBC more than 50% household in United States own at least one Apple product. What a penetration!

When I look at 5 years back almost everyone in my friend circle said, "Apple is a niche product. It sells its products at a higher price band. Who would buy Apple if already devices are available at more than 50% cheaper rates". People also speculated that Apple can't grow beyond a few percentage of the entire market. So what happened? Apple sold 35 million phones last quarter (Q1 2012). More precisely Apple is the 3rd largest Mobile Phone maker in the world according to IDC. Find the detailed report here.

Some say that Apple does a good marketing. But then why can't others? Well I agree that marketing is essential however there is more towards product making. Here are some of my points.

A wow product
Every product company says that they must make a wow product. Apple told them how to make it. Falling prices of semiconductor memories suddenly made MP3 players affordable. The market saw a surge of large number of mp3/ mp4 players available at affordable rates. Apple entered the market with iPod. Sold it at a very high price. However the iPod had a hard disk of much higher capacity in 50GB range (now at 160GB!). The iPod also had a very unique touch based circular wheel input as well as a very fast UI. One can scroll songs nicely by making a circular gesture.

People liked it because of iTunes (simple way of purchasing and transferring music), unique interface (circular), fast music scroll (powerful hardware).

If you closely look at it, to make such a product a very careful hardware and software design needs to be done which can fully utilize the hardware response as well as tune the UI effects seamlessly. The processor needs to be chosen suitably.

The point is Apple never compromised on design be it hardware or software when offering the end use case scenario. It includes choosing the right Processor, memory configuration, Graphics hardware, software stack. All are rightly placed to get fast user interaction and fluid style user interface (magical touch).

Since then iPod has undergone several phases (iPod classic, iPod Nano, iPod Touch etc). Apple also positioned each iPod into a different category and marketed them well.

iPod Classic - High data intensive user
iPod Nano    - For Joggers and Travelers  (Any generation)
iPod Touch  - For Gamer (Younger generation mostly)

The Best iPod is the iPhone.

The iPhone
Apple was never interested to make a device for common man at a very low cost. Instead they chose a product which does things in a simpler manner and whatever it does, it does them with the best performance. When first generation iPhone was launched in 2007 almost every mobile phone felt slow compared to it. Why? Because the processor was rightly chosen with a CPU frequency higher than other Mobiles' and it had one of the most powerful graphics hardware available at that point in time.

No Fragmentation across iPad, iPhone, iPod Touch
Apple never fragmented its platform by venturing into Low cost hardware, different screen resolution, multiple form factor products (slide screen, flip etc.). Absence of fragmentation makes designing the software extremely well. The API offering is good due to single product platform portfolio and guaranteed response time  of the Applications which the competitors could not match.

So in reality Apple attracted the developers.

Ecosystem (App Store, iTunes)
Developers always wanted things simple and wanted many ways to handle the devices
e.g. getting the device GPS position, getting current device 3D state in space
a good Development environment, a good developer support system etc.

and more precisely a good way to make money

The App Store gave them all. Apple made sure that the developers make money by launching their Apps in the Apple App store. In principle Apple also made a huge profit out of it by splitting the revenue with the developers.

Small companies made a fortune out of it (e.g. Rovio/ Angry Birds). They liked Apple and continued developing their Apps for Apple products.

At the same time Nokia/Symbian and Java developers also moved towards Apple by seeing slower growth in the respective products.

It was a cycle basically.

Apple always made sure that API offering is consistent across its device portfolio and that made the App design easier and also consistency across products like iPad, iPhone and iPod Touch.

This strategy internally made sure that the App developer has a higher reach across different segments thereby increasing profit and also it offered customers a seamless experience across multiple usage points. Customers felt they are interacting with same device be it their iPods or iMac. This reduced their paint points of sharing digital contents across devices they own. Credit goes to iTunes and iCloud.

Reduced pain points means customer delight and more device purchase.

Apple has now created a massive ecosystem.

In addition to is due to its standard connector across multiple devices it has a number of hardware accessories available viz. car accessories, music docks, backup battery dock, blood pressure docks, radar detection systems, heart rate monitor, Sports kit with Nike Shoes etc. This has delivered the customers an integrated user experience at multiple points of their lifestyle. 


A Standard connector facilitates wide reach of product portfolio (iPad, iPod, iPhone etc) and ensures that the manufactures sell them profitably by investing once on development and selling for multiple devices.


Unfortunately its competitors could almost never made their interfaces standard across their devices portfolio in older days. However now a lot of competitors are also adapting the same strategy using USB interface.

According to a recent report Apple has almost 73% of industry profit share while having 8% market share.

Apple taught the world how a large ecosystem drives more profit.


The next challenge for Apple to penetrate its brand across developing markets. In china Apple already has grabbed a large portion of Smart phone market share.

Can they do it for other markets as well? Lets wait and watch.

Smart Phone Worldwide Market Share

Following my previous post I got a feeling that a Smart Phone Market Share analysis would provide a clear picture.

Here it is. 2012 figure only consists of the Q1 results.

It can be seen how Apple and Samsung have grown almost a whopping 300% and 900% respectively between 2008 to 2012.




Source

The Nokia Story

The story needs no introduction about Nokia as a consumer brand. However when I saw the latest quarterly financial report of Nokia I was not at all surprised. The point is the market share is declining as well as the profit. One would assume it all happening because of Apple and Android OEMs. I feel there is more to it.

The story goes back in 2007 when Nokia had the highest market share in Mobile phone segment. It had a variety of devices to offer.

• clam shell (flip phones)
• sliding 
• phone with many degrees of freedom (N93 remember?)
• candy bar phones
• Symbian phones with multitasking ability
• S40 phones with low cost

It was a large company. It had to manage multiple platforms with many form factors. It used to license Symbian OS from Symbian Ltd. which was owned by multiple handset vendors [Nokia (>50%), Samsung, sony ericsson etc (<50%)].

Backward Integration

Nokia wanted to strengthen its focus on Smartphone and acquired Symbian. Nokia also acquired QT (Trolltech) which was doing UI development in a platform agnostic way. Nokia wanted to integrate Maps and navigation into the devices and acquired Navteq.

Nokia made a strategy to build devices with multiple platforms but with a common UI (QT).

However Nokia was not sure that it was dealing with too much complexity. Due to multi platform strategy and supporting a large type of devices Symbian software code became terribly complex.  Making a product out of Symbian OS + S60 UI layer of Nokia was arduous.

QT Apps

-----------------------------

QT

-----------------------------

S60 UI 

-----------------------------

Symbian OS

-----------------------------

Hardware Variation

A comparison internally made revealed that Symbian had almost 10 times code size as compared to Android! Lots of developers complained about the API inconsistency and Usage style. (Blame it on different CPU speed and screen size of Nokia phones!)

I was very much a part of Nokia then and witnessed humongous effort spent on sanitizing the bugs and also interfacing with the 3rd party Applications.

Every developer can understand what happens when you have too many layers and the processing power is low.

Decision making and execution was slow due to complex organisation structure leading to accountability vacuum. Making a phone was a great pain. 

Meego

Nokia also was doing Maemo (Linux variant) development to offer PC like computing on mobile devices. Plan was also there to put QT on top of it. Nokia also partnered with Intel's Moblin platform and created Meego!

However the execution was slow. Even if the products were well appreciated (N800, N9) they could not compete with the Apples and Androids due to small no. of 3rd party  applications availability and more precisely a small ecosystem.

Nokia event tried to make NetBook. Not sure if anybody remembers Nokia's Booklet.

The solution strategy

Nokia also came up with OVI store for the developers to launch Applications. Nokia tried to venture into other products like Ovi Music, Ovi Share etc. However they were badly managed. It took a long time to get Single Sign on working seamlessly. Mostly they didn't work. 

People were used to Google products then and telling them a different story was too naive to convince them to use OVI products.

Recently Nokia has announced to discontinue OVI branding. You can read it here.

Playing with APIs

API (Application Programming Interface) is very important to develop Applications. Nokia had a large set to varying APIs to attract developers.

• Java
• Symbian C++
• QT
• Posix
• flash
• java script

Maintaining each API adds to new set of complexity. What really developers wanted is a simple API which could work with all set of phones. Note that even Android can suffer from this issue due to large form factor variation of hardware. For instance HTC wildfire is too slow to run and can't run many Android Apps which run smoothly in HTC One S.

However Apple doesn't suffer from this due to one platform strategy.

The point here is due to simplicity nature of APIs a lots of developers migrated to Apple and Android resulting a smaller Symbian - Nokia ecosystem and larger Apple/ Android ecosystem.

Less Apps means Less Handset future usage. Customers didn't like this.

Nokia continually lost market share from 2008 till date.

People liked N8 but they liked Samsung galaxy more and iPhone even more.

Hardware Story

After 2007 several hardware vendors evolved and came up with great platforms. viz. Qualcomm and Nvidia. Nokia didn't make any single device with them even if they were having power packed performances. However Nokia wanted to launch multi-core platform on Symbian partnering with ST-Ericsson. Nokia invested a large chunk developing SMP enabled Symbian OS and UI layers however failed to launch any products in time. When every other player launched muti-core products Nokia had none to offer. Customers were disappointed.

The Comeback Strategy

Nokia hired a new CEO Stephen Elop in 2010 and decided to cut down the fat. Since then the company is under major restructuring including selling Symbian Unit to Accenture. It Partnered with Microsoft to use Windows Phone OS for the future smart phone devices. S40 is still alive catering to low cost devices and is getting better browser updates to penetrate mass consumers. 

The recent launches N800, N900 are quite appreciated in the market. The struggle continues to regain the lost market share.

The struggle story teaches a lot of lesson on Product making. Watch for my forthcoming post on Apple.

Image Source

Update:
The Smart Phone Market Share figure is found here.

Part 3: Understand Your Customer

In my previous blog I have talked about how the organisation layout is followed in most Product Startups. Often a lot of Product Startups dive into product making and forget the essence of market knowledge. This doesn't mean that the company should focus only on those requirements that are coming from the market. Sometimes there are some unexplored areas.

Lets closely look at the Product itself. It is basically a combination of Software and Hardware if we consider Information Technology based Business. During initial days companies generally focus on product making only. This involves designing the software and hardware and manufacturing it. Initially the requirements on which the Product is made is derived from the potential customers or market opportunity as seen by the founders. Once the product is made with the limited set of requirements it is marketed to potential customers. This is the time when ground realities hit.

I wanted chocolate in a Nice Box but you are selling it in a polythene

Often the engineering team focuses on making the software and hardware the most reliable. However is it desired. If one closely look at any software product, there are certain parameters that define quality. They are,

- Reliability (No issue on long run)

- Robustness  (No issue on bad input)

- Efficiency   (Fast and optimized)

- Maintainable

It is often very hard to follow all the parameters. Often engineering teams use all there energy to focus on increasing quality of the Product. But is it necessary at all ?

Here is the real case study of a Consumer Product Company X. When the marketing team comes up with the proposal to make a product, the Engineering team decides that it must make the software so secure that no one can crack it. However that makes it a tight product and enforces the Customer to use it in a special way. On the other hand market research reveals that similar product is already available in the open market and that has no protection. The company X marketing wants to simply sell the Product to promote it across variety of Customer spread across different regions.

There is a gap here between Engineering and Marketing teams of Company X.

The Company X must understand what is the purpose and what must be offered. In this case the marketing simply wants to promote and hence the focus should be on Branding and Communicating with the Customers. Investing on secure software offers no advantage over the competitor's product since the customers of Company X can get the unsecured Products in open market anyways and with simpler usability. Customers want this Product because they want to start a healthy Business relationship with the Company X not to buy a secure product with tighter control on usability. Basically they don't want security. They simply want the product to work. That's all. Sometimes it is not very intuitive but true.

The message is plain and simple, make the one that sells.

Part 2: Organization Layout and Conflicts

Yes it is important to manage people otherwise be ready for a disaster. It is always about "people factory" as Jack Welch says. Unless right kind of people are at the Job it is difficult to gain success. This is tackled by laying out a clear roles and responsibility structure in the company.

There could be deviations in org structure of startups with varied product areas. However most technology startups have similar role distributions. A typical organisation structure looks like this.

Although some roles overlap with each other during initial days, they become more and more important once company runs in its full pace.

One of the most important aspect is the way the organisation functions. It is essential for a startup in its initial days to be extremely agile since it needs to learn the way to make a successful product. That means having clarity in communication and taking leadership in problem solving inside the entire org. However once the startup forms a good base of customers and starts selling products sometimes these values dilute. 

There are times when the org goes through conflicts. The most observed ones are

• among developers
• between marketing and engineering

The senior developers generally play roles of architects/ designers. Due to the layered structure of software (assuming software products area) there tend to be multiple designers who possess conflict of opinion. The negative impact of this results a poor quality of software. Often it is ignored by the management who tends to incline towards few senior developers who has joined the company during initial days and hence get more respect. However the management is unaware of the situation that is building due to tension among the developers. Unless the problem is solved the quality is degraded.

It is the onus of the CTO or the VP engineering to identify and understand such issues and promptly address it. Often a good practice is to set up a process guideline for engineering development and ensure that it is followed religiously. An example is making a software design review with review guidelines. This ensures that the design is done correctly and also undesirable clash doesn't happen between the developer and the reviewer (generally a senior architect); thereby ensuring the quality.

There are also conflicts of interest between the Marketing and Engineering org. Very often the Marketing org functions in a sales driven way and the Engineering org functions in a optimized development (lazy but efficient; there is a point I'll clarify in another blog why I chose this). Sometimes optimized development hinders the sales demands. For instance the sales would require the product to implement a feature. However the Engineering is not ready to do that as it leads to improper hack or improper customization or poor maintainability which is difficult to comprehend for the Sales org.

This is classical problem but there is a solution to it. The respective heads must have the mandate to manage product. Product Management means making as well as selling the products profitably. Often there exists a product management org separately. The crux is there should be an effort to find out the cost vs profit of product features. Essentially a profitable (which could be a short or a long term benefit) feature is what a product needs. Hence it should serve as a guideline for prioritizing its development.

There are a lot of unanswered questions here. How to handle feature requirements etc. The upcoming post mentions them.