Matching Expectations
I want to brag about one of our clients and use their main product as a micro case study in product identification and whole product definition.
Mobile Complete provides a unique service called DeviceAnywhere (which I don’t think is a great name for the service, but Silicon Strategies Marketing was not engaged with Mobile Complete during their initial branding efforts). What DeviceAnywhere does is allow you to remotely use real, live mobile handsets for testing mobile applications. They give you access to hundreds of popular devices, in regions all around the world, and the ability to test every aspect of the device and your application.
Before DeviceAnywhere, the market had two options: use emulators for testing or buy one of each phone, for each carrier, in every country and carry monthly service charges for all of them. The later is an extremely expensive option, and even wealthy companies like Google were unhappy with outlaying that much lucre. And as anyone in software knows that emulators don’t.
Thus the expected outcomes for a mobile application developer were:
- I need to test on real devices
- I need to test with all the popular devices, and a few orphans
- I need to test cell phones in London even when I work in San Francisco
- I need full access to carrier telephony and data services
- I don’t want to invest a lot of capital in handsets
- I don’t want to pay for monthly service contracts for hundreds of phone
Mobile Complete did what any good company — software or otherwise — should do, and that was to first understand the expected outcomes, then design the product accordingly. By matching customer expected outcomes to product realities, they have satisfied a large and growing number of customers. At the recent CTIA event in San Francisco, they informally estimated that 60% of exhibitors on the show floor with either customers or partners (click on these photos for a larger image).
One aspect of their customer’s expected outcomes (or the whole product definition) is that testing of mobile applications had to have no emulation. Some vendors load software agents onto devices for remote controls. The problem is that any software agent has limitations on functionality (try to pull a battery out of a cell phone remotely using an embedded software agent) and typically induce problems. Mobile Complete actually hard-wires each mobile device and makes every function (like opening and closing a flip phone) a physical or electrical connection, so the device responds as if it were in the developers hands.
Their approach was not easy to implement, but it delivered what the market wanted, and that is what really matters.