Previous month:
January 2012
Next month:
March 2012

February 2012

Squeezing the Elephant

If you are a small company going after a big market, customer awareness is worth a lot to you.  If you have a great app (or web service) but are frustrated it’s so hard to get customers to know you are there, you should pursue using your commitment to a single platform to your advantage.  Elephants are always on the lookout for great cool apps that leverage their platform unique capabilities and that demo well.  Don’t be bashful talking to the elephant on how committed you are to their platform, how you have taken advantage of all the latest and greatest unique features of their platform, and how flashy your app demos.  Did I say don’t be bashful?  I really meant you need to be very very aggressive promoting your app to the elephant.  You need to stick that bundle of banana’s right under his nose.

Elephants are always on the lookout for great flashy apps unique to their platform that they can demo at customer events, in advertising, feature in blogs, and promote on their web site or app store.  Though the elephant may be forced to show some multi-platform apps in their marketing activities (a la Angry Birds) – you can be sure they are looking for apps that differentiate their platform from others. 

Again it gets back to how important the platform provider is to your sales and marketing efforts.  If getting exposure from the platform provider is very important, going with one platform, and squeezing the elephant for all its worth (given your “sole source” commitment to them), is an effective way for a small company to get known.   But as I said at the beginning, you need a great flashy app to really “work” the elephant effectively – and you need to be aggressive. 

If/when you create some real market presence and sales are rolling in, than is the time to think about maybe trying to ride that second elephant – when you have the cash flow to build a great app tailored to the capabilities and strengths of the two different platforms.  And when the elephant is starting to feel like having your support is important to them (not just important to you) – regardless of the fact you are riding multiple platforms.


Dancing with Two (or more) Elephants? Part 2 – Sales and Marketing Costs

A few partners I work with have recently developed their first mobile apps.  They tell me they find Apple being slow or refusing to accept their app in Apple’s App Store when they have already made the app available in the Android Marketplace.  I have heard similar fears from partners with apps that run with both Autodesk Inventor and SolidWorks.  Is getting marketing and sales support from your platform providers an important consideration when considering supporting multiple platforms?

It depends.

First, is getting sales and marketing support from the platform provider important to you?  If we are talking a mobile app, it is absolutely important given your primary sales channel is 100% dependent on the platform provider giving you space – and better yet prominent location – in their store (today, Apple’s App Store and the Android Marketplace).   You very much need to know each platform providers behavior when you support multiple platforms.  We know the Android Marketplace doesn’t care if you support iOS too – but are you sure Apple has the same behavior?  Maybe?

At Autodesk, we “programmatically” support partners that support multiple platforms – providing access to development software, support and basic company and app information on http://partnerproducts.autodesk.com. But what about working closely with Autodesk Sales Reps and Resellers?  If you support a competitive platform, they will assume you are “suspect” – which means they will rarely call you to help fill a customer need.  The one exception is where you have taken the time to develop a personal face to face trusting relationship with an Autodesk Sales Rep or Reseller.  Of course these types of personal relationships take time to develop, time to maintain, and don’t scale beyond a small number of people.  Is this Autodesk policy?  No it’s not.  This is a human emotional response that most sales reps and resellers for a platform provider will have. “They work with the enemy so cannot be trusted.”

Do you care? 

If your app is for a specific group of customers that the platform provider doesn’t target – or may not even be aware of – you likely don’t care about having a meaningful sales and marketing relationship with the platform provider.  You rarely if ever run into the platform provider’s sales reps or resellers – and more importantly your customers don’t either. Your relationship with the platform provider is primarily technical in nature – the platform makes it quicker and easier for you to develop and deliver a state of the art compelling competitive app.  Per my prior blog post, supporting multiple platforms is about getting the most capability from each platform – not worrying about sales and marketing relationships.

On the other hand, if your target customers do regularly touch the platform provider’s sales reps or resellers, you very much care what these folks are telling your customers.  This is where supporting multiple platforms is a real hurdle/obstacle to getting a platform provider’s sales team to recommend – or at least not discourage – customers from working with you.  If you need the platform providers sales team’s support for your business to grow and succeed, you either need to support just one platform, or take the time to develop personal trusting relationships with the individual sales people of each platform provider (a whole lot of quality time with the platform sales reps and resellers). As you can now imagine, supporting multiple platforms does add a real and significant cost of sales. Again this assumes you have an app targeted at customers that are likely frequently talked with by the platform provider’s sales reps and resellers.

So you have an app and business that could really benefit from a close relationship with the platform providers sales reps and resellers.  Developing and maintaining a strong sales relationship with the platform provider’s sales team means supporting just one platform. 

Isn’t that very risky – being dependent on a single platform provider for success? 

The platform provider could fail to maintain their market leadership position, neglect development of APIs, compete with you, or just decide your partnership is no longer important to them.  Are there exceptions to supporting just one platform - when a close relationship with the platform provider’s sales reps and resellers is important? 

We’ll look at the business risk of supporting a single platform, how to minimize the risk of a single platform business strategy, and the rare exception to the “single platform if sales relationship is important” rule, in my next post.  A thought experiment.  Do you think it’s safer or riskier to dance with one (real) elephant at a time (tusks, trunk and all)?  Or is it safer or riskier to dance with a few elephants at one time? Why?


Dancing with Two (or More) Elephants?

At some point almost every software company will need to make a decision on how many elephants to dance with (platforms to support).  Just one, two or more? Should I dance with Apple (iOS) and Google (Android)?  Should I dance with Microsoft (Windows) and Apple?  How about three elephants – Xbox, PS/3 and Wii?  Closer to home, how about dancing with both Autodesk and SolidWorks?  Autodesk at one point - many years ago – “tried” to dance with nine elephants all at once.  Is there a right or wrong answer to supporting multiple platforms?

The easy question to answer is you definitely can dance with too many elephants at the same time.  It costs real money to support multiple platforms – and direct software development costs are typically one of the smaller costs of supporting multiple platforms. 

Short Term

Quality and support are near the top of the added cost of supporting multiple platforms.  Trying to maintain a single code base that runs on multiple platforms invariably leads to quality problems as one stumbles upon platform specific behavior that you won’t find in any documentation or sample code.  Adding a new feature or fixing a bug for one platform will at times create instability in another platform that has to be sorted out.  If you are good, you might be able to manage this quality juggle for two or three platforms, but quality and the cost of quality increase more than linearly as you add platforms. And then there are the extra support costs for multiple platforms – having to deal with customer problems that may or may not be platform specific and the complexity of ongoing platform updates which each platform releasing updates at different times.  May I suggest quality and support costs go up exponentially as you increase platforms supported?

Long Term

Dancing with several elephants drives you to make “lowest common denominator” app design decisions.  Do you add a new feature that only works on one platform but not another?  Different capabilities on different platforms make everything harder to do – app design, coding, testing, documentation, sales and marketing materials, and so on.  This gets way complicated way fast – so you feel compelled to keep your app the same on all platforms – leading to only using lowest common denominator platform capabilities.  What happens when you have a competitor that only supports one platform, takes advantage of all the capabilities of the platform, and builds a superior application?  Let me say that again. What happens when you have a competitor that only supports one platform, takes advantage of all the capabilities of the platform, and builds a superior application?  I have seen this scenario play out a number of times over the years.  Trying to build one app that runs the same on multiple platforms (platforms that are competing to differentiate themselves from other platforms) fails in the long term – and the more competitive the market, the quicker it fails.  

So does that mean you cannot support multiple platforms?  No – you can.  But you need to start with the assumption each app on each platform is a different and unique application.  You need to make the investment in development, quality, support and so on assuming you are really developing two (or more) unique apps that have the freedom to take advantage of the platform they are designed for (not limited to lowest common denominator design).  Sure you can likely share a bit (even quite a bit) of code between these similar but different apps on the different platforms – but product design and engineering needs to have the freedom to do their best taking advantage of the strengths of each platform.

Net Net

You need to be sure each platform you are considering supporting presents you with a large enough business opportunity to build the best app you can on the platform – and not make the false assumption its mostly the same code so supporting multiple platforms is cheap and easy.  A lowest common denominator app design strategy is a strategy for failure.

Dancing with more than one elephant will also impact your ability to leverage the platform provider’s sales and marketing resources. That may or may not be important to you. We’ll save that discussion for another day.


What the Academics Think of Elephants - and Dancing with Them

As promised for a few posts now, let’s take a look at some academic research around the dynamics of elephants, elephant herds, dancing with elephants and more.  There are some real gold nuggets in this pile of research that can really help start-ups think through how to best dance with elephants (and not lose sight of the environment you are building a business in).  I must warn you the terminology used by researchers in academia can be a “bit much” at times with terms like “multi-sided platforms”, “two sided platforms”, and “social efficiency” taking some time to get your head wrapped around.  On the plus side, academia just loves researching “platforms” so there is plenty to learn. 

So here is a list of academic papers on platforms and partnering  - what we’ve been calling dancing with elephants – with my elevator description on what I believe are important conclusions – as well as at risk of embarrassing myself – my occasional disagreement.

Why Dance with an Elephant?  Why Not Go It Alone?

Invisible Engines: How Software Platforms Drive Innovation and Transform Industries

Video games.  Social networks. Operating systems. Smart phones.  Buying networks. Music services.  This is one of the classic books on platforms (elephants) .  Though it is starting to feel a bit dated, it covers most of the basics on why there are elephants, why dancing with elephants makes sense (and frankly is a necessity unless you have a number of wealthy friends), and how elephants plus riders and myriad other dancers together are a major source of innovation in our world. 

The Elephant’s Dance

Platform Rules: Multi-Sided Platforms as Regulators

Using Facebook, TopCoder, Roppongi Hills (a retail center in Japan no less!) and more as foundations to develop their platform concepts, these academics create a simplified (for an academic but not for me!) framework for looking at and thinking about how a platform provider develops and manages their ecosystem.  We all know the way a platform provider make information available, technical limitations they apply (that at times feel arbitrary), use of social media, contests, conferences, license agreements and so on impacts development of partnerships and an overall ecosystem.  But can you imagine trying to create a framework that make objective sense about the effectiveness of all this? Do I sound skeptical?  So I don’t fully buy into the model – but this research does give someone dancing with an elephant (or two) some insights on what the elephant might do – and why they might do it (that is sometimes very much not obvious).  If you know more about what the elephant is considering and might do – you are more likely to get a ride on top of him instead of dodging his steps.

Handicapping Elephants

Dynamics of Platform Competition: Exploring the Role of Installed Base, Platform Quality and Consumer Expectations

This is a video game industry based research effort – so beware applying to other industries.  If you are having to make a hard decision about what platform (elephant) to ride, this paper provides a wee bit of insights into factors to consider when trying to “pick the winner” in an elephant race.  Nothing is uglier than building your business riding - or running with - the elephant that stumbles before the race is over (taking much of your sweat equity investment down with it).  The paper uncovers the interplay of indirect network effects - more people with the platform leads to more apps for the platform which leads to more people with the platform circling skyward - with customer expectations - does a customer want/need more than a few apps? Also is poor quality in a platform (sort of like n with a drunken elephant) a mortal or surface wound? Unless you are a math major (I am surly not), I suggest skipping the development of the differential equations that try to model and predict the growth or failure of a platform.

What About “Open” Platforms?

Opening Platforms: How, When and Why

Why work with “proprietary” platforms such as from Adobe, Apple, Microsoft or Autodesk?  Why not stick to open platforms like HTML, WebGL, and SVG?  Platforms have a lot of different stakeholders – it’s not just the platform provider, customer and ISV.  There are various forms of complementors including service providers, hardware providers, educators, and others – all with their individual needs, wants and unique motivations (mostly they are all trying to make a living and have the occasional chance to do better than just make a living).  This paper comes to the conclusion that successful platforms naturally evolve into a hybrid mix of proprietary (the platform) and areas of “shared responsibility” (open).  This paper covers a lot of ground – and makes observations and draws conclusions that mirror a lot of what I have seen personally in the development of ecosystems in CAD industry over the last 20 years.  It evens talks about what I would rephrase as the dancers putting the elephant(s) in a cage!

It’s Not Just About the Elephant’s Dancing Skills – Yours Too (The Most Common Strategy Mistakes)

Understanding Michael Porter: The Essential Guide to Competition and Strategy

This is not about dancing with elephants – but valuable anyone pointing out key strategy mistakes that kill companies – such as the need to make tradeoffs – the necessity of deciding who your customers are and are not.  We all avoid making tradeoffs that might limit the number of customers we could have.  Yet all too often fewer tradeoffs mean less focus and fewer sales.  More tradeoffs mean more focus and more sales.  Counter intuitive?  Sort of.  Themes similar to Geoffrey Moore’s classic “Crossing  the Chasm” and “Inside the Tornado”.  On a tangent, I fondly remember well over a decade ago purchasing a few hundred copies of “Crossing the Chasm” and giving them out to hundreds of Autodesk partners – as well as many many senior managers at Autodesk.

Had enough of academic papers about platforms?  Want to hear about more research that applies to building a new business dancing with elephants?  Let me know – as I have a lot more (and just may do one more post).  On the other hand, I suspect I may be putting too many of you asleep and it’s time to move on to more stimulating discussions. If you are having trouble dancing with an elephant or deciding what elephant to dance with, tell me a little bit about it - and I'll attempt to do justice to "Ask Abby".