Wednesday, 4 December 2013

Divide or Conquer

I've seen three approaches recently to the generic problem of reaching as many smartphone users as possible. I should start by saying that Windows 8 has not really made enough of an impact to make it a contender as a distinct delivery platform, & Blackberry seems to be a complete market failure, so I will limit this discussion to the big two - Android & iOS - & leave it to the reader to imagine a world where there are four platforms to worry about.
  1. Outsource. If you don't have the skills in-house, then farm out the development to experts who do. If you're going to go to that trouble, then you farm out the development to distinct experts, effectively solving one problem twice, & hope that they magically come up with the same solution.
  2. Insource. Some organisations think it's better to bring the experts in-house, either by hiring people to work on the project long-term, or else getting in contractors who are experts. If you rely on new people to define & develop your solutions, you will end up in a position no different to the above - two solutions taking twice as much energy with the hope that they will be the same.
  3. No-source. When a solution (or prototype) for each platform exists, scrap both & start from scratch with a cross-platform solution that guarantees consistency of UX. Although this makes sense on the surface, jumping into this position from the get-go is not the answer - you first need to determine if it can be done that way.
Fundamentally, there are no easy answers. Anyone who thinks that is kidding themselves, & probably will make regrettable decisions in the not-too-distant future. A mobile solution needs first to be a deliverable that provides the UX appropriate to the brand & the product being developed. That has to be the primary concern.

Technology decisions should be almost an after-thought because, in an agile environment, these things can change. Next year, there might be a fantastic cross-platform environment suitable for another product or the next release - or the providers of the current platform could discontinue support of their product or make the conditions of use commercially non-viable.

The important thing is not to become the expert in a technology, but to be able to define your business needs for a technologist to implement - & for those same needs to be implemented by another technologist next time, if need be. That technologist could be an external contractor or the internal development team.

The definition of the product needs to be conveyed in terms of end-user value (why would they use our product), brand alignment (why would they want our product), functionality (how would they use our product), & product direction (what is our product - or user base - going to be tomorrow). The acceptance of the marketable product needs to reflect this, regardless of how it was created.

You could say at this point - "So, what's changed?"

Having to support multiple platforms does not change the fundamentals of product development. To create good product - even in the mobile space - you have to want to create good product. Once you've worked out what that is, the rest is just a matter of implementation - easy :)


No comments:

Post a Comment