Mobile Codes Motivation

The email briefs on wireless are reported today that Sprint will spend $5B on WiMAX "buildout"($2.5B in '08!).
Hearing such a number I halt for a second: $5B... Not that it is so dissimilar from other infrastructure investments like IMS, 3G, LBS and many more, but still an impressive number. Specifically in this case, they are building the wireless IP network for services and content, which will require further development and marketing budgets. You would find all over the web different quotes on the (lack of) returns on wireless IP network investments because there weren't enough compelling services and content to drive subscriber adoption: "The Current State Of The Mobile Internet Is Disappointing For All Stakeholders" (Source).
(As a side, with a promise of "Sprint has stated that it intends to deliver service at 2 Mbps to 4 Mbps to its customers with Mobile WiMAX." (Source), we can begin thinking of WVOIP, but lets leave that aside, I can't believe Sprint are making the investment based on WVOIP alone).

So the network will be available, the pipes will be wide enough, and the NFL games will just be waiting to be seen. What would motivate subscribers to actually consume the services? or rather, what would change things from the subscriber standpoint??
I suggest that what could change is the accessibility to those services and content, simplified by mobile code scanning. These can bring the returns on the investment this time around. Let people connect in a click to content, to their bank account, to mobile purchasing, coupons, loyalty, ticketing, networking its all doable. Make code scanning happen and it will show the returns you were hoping for. Here's a great article that speaks to the potential of mobile advertising and state of things.

Mobile Codes Blogsphere

In addition to the great market news and vendor list provided by the pondering primate, Jump! Mobile in his blog has a post with all the blogs that discuss mobile code scanning. there are vendors, marketers, mobile social networkers and much more. Excellent stuff from Jump! Mobile.

Let me quickly repeat the list of mobile code blogs for convenience (from Jump! Mobile):
Rex's blah blah blah (Chinese) - One of the most informative introductions to 2D barcodes and with great industry insight.

The Pondering Primate - Probably the blog that coined the term "physical world connection", always up to date on the latest developments on mobile barcodes.

QR Code Blog (Japanese) - Though discontinued, the blog's attempt at blogging with QR Codes is still quite interesting to see.

All About Mobile Life - Kaywa expert's blog always has something nice to share.

Bar code Insight (Chinese) - Observes the mobile barcode developments happening in Mainland China.

Tommi's S60 applications blog - Developer at Nokia shares views on mobile barcode applications.

GSMBLOG.net - Has an in depth review and comparison of various 2D barcode readers.

David Harper's Different Things - WinkSite founder introduces QR Codes.

BeeTagg Mobile Tagging Blog (Swiss) - BeeTagg's official blog.

streetstylz - NeoMedia's official blog, I think.

Make a Difference - Blog by NextCode's director of product management .

ShotCode Blog - ShotCode's official blog.

http://semacode.org/weblog/ - Semacode blog

http://www.semapedia.org/wordpress/ - Semapedia blog

http://barcode20.blogspot.com/ - Olivier Attia blog - Founder of Scanbuy

http://blog.announcemobile.com/ - Jeff Mould blog - Founder of Announce Mobile


Enjoy!

On Mobile Codes Standardization

I am being asked about how can vendors contribute to the standardization initiative, the new Mobile Code Consortium (MC2) .

For starters, I believe everyone identifies the threat, being that the market becomes fragmented by numerous code formats. Recognizing that brands and advertisers will drive this market, that fragmenting this market by code formats would prevent them from engaging this space is essential. Anything other than a ubiquitous user experience, regardless of codes and hardware will be unacceptable. I strongly recommend reading through Publicis presentation here.

Let me add a quick note here that I will avoid the discussion of whether MC2 is appropriate or not (as can be found in numerous places on the web).

In consensus that the MC2 initiative is essential and everyone in the space should support it,
the question becomes (IMHO): what are the issues that are realistic & appropriate for discussion and agreement in this context? Reading through the Mission Statement and the Standards Discussion here are the 3 issues MC2 is proposing to deal with:

• Visual and Encoding Aspects (essentially dealing with the code format)
• Data Aspects: Formatting the code content
• Behavioral Aspects (The code reader UI behavior)

I would suggest that at least for now, the symbology itself should not be on this list. The reason being is that there has not been enough evidence from the market place as to code-format related factors that drive adoption. The argument that standard codes have reach challenges because of optics issues on out-of-Japan phones is a temporary one. With that in mind, trying to define the new standard symbology will be based on vendors making the case for their proprietary code format based on their vision, experience and ego. That's not very effective. The market needs a prompt definition and there are two appropriate, well defined solutions out there, we should be using them (at least as V1.0).
In the same spirit, I think that the last issue on the MC2 initiative list, dealing with the code reader UI behavior, is to be left to the vendors to design and differentiate. MC2 should be able to define the functional behavior the reader once it scans a particular code but when it comes to UI, vendor should have the freedom to differentiate through a nicer screen and more flexible options menu.

Let me propose a few ideas that I think would be useful for MC2 members to make progress on:

• Ubiquitous standard symbologies support with optional proprietary codes: Agree that the industry needs a standard that every code reader will support. Those codes should be QR, DM or both. No point in arguing the code formats issue. All vendors that want to be considered need to support standard codes, and can add support for more codes, like their own proprietary format and maybe others. Operators and brands can then choose the solutions they prefer. Consumers will have the ability to decode the codes and use them regardless of the code reader they are using
  
• Define templates for the code content: This is, IMHO, the space at which MC2 can contribute the most. Assume a vendor supports QR, there is no definition today to what might be the code content, it could be anything. By defining the templates, MC2 would enable a structure that would provide acceptable, expected user experience, flexible use cases and the grounds for operators and brands to monetize on. MC2 can make this along term initiative such that defines the formatting for new use cases
  
• Data Aspects of more complex usage: This is an advanced discussion of the previous point but equally important: some use cases would require extra control and flexibility, that should be supported by the code content. For example, in the case of direct mobile payments, some fraud detection and prevention data might be embedded into the code and should stay hidden from the user. MC2 can make this happen by defining the structure of those codes generally, and then vendors or operators can go in and refine the details in their specific solution
• Introduce "licensed" codes schemes: one of the bigger issues of using standard codes for B2B, for example, is that anyone can read and reproduce their codes. In similar to IP address allocation, MC2 can take the initiative of allocation certain 'address space' for specific usage such as privately licensed prefixes
• Standard Symbology V2: by the time MC2 was able to facilitate all of the above, there will be as many members and activities in the marketplace to suggest what factors in the symbology drive adoption. At that time MC2 can begin defining future ("V2") symbologies and facilitate standardization process and encouraging vendors to adopt them

In viewing this list, I think that one of the strengths of it is that these all are achievable items in a measurable time frame. There is not much room for subjective arguments in any of them and so the process could be very effective.
By moderating an effective discussion MC2 could become the parallel to other centralized bodies like OMA (Open Mobile Alliance) and in that attract various players from the space to join.

I hope that was useful, thanks for reading.

Mobile: Getting an application on a phone, mobile code scanning implications

One of the biggest challenges that mobile application developers face is to get the application onto people's phones. There is a lot of value in doing that because (to mention some):

• In most cases, the user experience can be much more friendly, flexible and robust (you can take local actions on the phone), and can be tailored to the particular phone
• The applications doesn't necessarily depend on external resources (such as web access or SMS, which may or may not be available) for its core functionality
• The presence and availability of the application on the phone provides better chances of usage than if it would be remote on the web or available through SMS

However, getting an application onto subscribers phones is challenging:

• Reach: to become successful, the application needs to function and have an acceptable user interface on every phone you may want to launch on. Since in most cases applications are subscriber-facing, that means that you want it available on virtually any phone model available. This is particularly true if this is a social application. If all the phones in the world would have been the same, or at least conforming to the same API, that would have not have been an issue. But, just to give you an idea, every single J2ME phone is different. every single one. That means time, effort, cost to procure all the phones and test them (or get access through remote testing services like Mobile Complete and their service Device Anywhere) etc.
• Go off-deck: "Off deck" means that you do not have relationships with mobile operators to promote your application from their "deck" of services/applications/content (which they heavily promote to their subscribers through their channels). Off deck means you're on your own and you got to figure out the following:
  • Marketing and Subscriber Education: Making subscribers aware of the application/service and motivating them to try it, educating them about the value and how to use it
  • Distribution mechanisms: Enabling subscribers to easily obtain the application. That includes creating a WAP portal that will identify each different phone and provide the correct application for that phone. That also includes creating distribution channels like short codes (a bit of ahead ache if you're thinking globally...short codes are different in different geographies), near-range bluetooth is possible etc. you might also consider embedding into your application a "Tell-A-Friend" option so that users can virally spread the word
  • Download and Installation: As mentioned, you will need to build a WAP portal that will identify the particular phone model and provide the right application to download. That WAP site would typically also contain informational pages like extended help content beyond what's immediately available on the application on the phone, supported devices etc. The installation is a key part that needs to go 200% smoothly for subscribers. If you think people are paranoid about installing stuff on their PCs, triple that for phones
    
  One might think that going "off-deck" has the advantage of speeding programs into launch because you don't need to establish relationships with operators. That's not exactly true: you are making use of the operator's services, at least to distribute the application. In some geographies, you will find that operators charge a premium (beyond the standard data or messaging cost) for delivering content or applications, even if those are provided for free
• Go "On-Dec" means that you establish relationships with operator(s) in the targeted geographies. That will simplify your life in terms of marketing, distribution, subscriber education and other aspects of getting the application out there because the operator would typically already have the solutions to do that anyway. An operator would also have the power to pre-install the application on new phones, which removes the application distribution barrier completely. That said, getting an operator to be interested in your application to the point you have commercial relationship is not a trivial task

Once all of those systems are in place one would hope that subscribers would be motivated enough to obtain the application, install it and try it for the first time. The motivation should be very high for a subscriber to go through all these loops...If there was a way to get your application pre-installed on the phone or somehow avoid that step then your life might get simpler.
The bottom line here, I think, is that careful consideration is recommended when deciding whether your application strategy is to be installed on phones.

As an example, for LocaModa, a very interesting startup in the mobile space, some of these considerations guided their product strategy: getting an application on the phone is just too big of a barrier these days. They use the existing SMS channel, that everyone uses and is familiar with to deliver their cool service.

Let's take a look at the implications on mobile code scanning. A solution could be either a local application on the phone, with the capabilities of making use of local resources and applications on the phone to enhance the immediacy, flexibility and robustness of the application. Another way to provide code scanning solution is to have the code decoded remotely. There are several different mechanisms to do that:

• 3G video call: create a video call to a decoder server that will decode images sampled from the stream and will (in different ways) inform you of the result. One company that does that is DSPV
• MMS: take a picture of a code and send it over MMS, the server will reply with a response over SMS, for example, with a link. One company that does that is Mobot. When coming to MMS, one needs to keep in mind that the destination for the MMS requires, again, keying in. In some geographies, operators made MMS-to-shortcode available, however elsewhere the user experience would be to type in an email address when sending the code, and that in itself invalidates the whole usability issue that code scanning is trying to solve. So look for MMS-To-Shortcode functionality in those solutions

Interestingly enough, some companies can provide both services (local application or server based decoder).
There are several pros and cons for going the remote decoding route:

• No need for local application on the phone: removes all the hurdles mentioned earlier, but, also looses the advantages of having a local application (compelling use cases, flexibility, immediacy etc...)
• Campaigns aren't restricted to codes only: Since it is a remote powerful server that decodes data incoming, it could also correlate the incoming images with logos and other marketing material. therefore, you could send in a picture of a Nike shoe and the server may come back to you with a link to that shoe WAP site
• The technology to send an MMS is pretty much available on every phone, and people generally know how to send an SMS (not the same, but similar), hence easier learning curve
  

When considering code-scanning opportunities with brands and ad agencies in a very early market, where not all phones support access to the camera, there are reach and education issues, it may be viable to consider remote decoding options. Sure, this is not the optimal route, but it is an entry point for early adopter brands to get their feet wet and gain innovation recognition. It is an excellent way for players in the space to learn what works and what doesn't for consumers, and for the brands. When the technology will satisfy the reach challenge and other challenges mentioned, the on-phone application strategy would be widely accepted because people used codes and they are comfortable with the idea. Further, they would be happy with the better user experience and new features that will come with it.

Hope that was useful, thanks for reading!

Mobile Code Scanning: Business Models that work for Operators and Vendors

Allow me to open by thanking everyone for the positive response on the previous post that dealt with the technology selection criteria for mobile code scanning.

To recap, in the series of 'Mobile Code Scanning' posts I've looked at:

• What Code Scanning is all about
• Potential operator revenue streams (with an extra note on the B2B vertical)
  
• What might be subscribers expectations from this kind of service
• Technology selection

Figuring out the technology has significant implication on which are the vendors who should be considered. For example, if you decide to go for proprietary code format then those vendors who have the open standard codes on their flag might not be high on the list. Further, if you go for proprietary code format you may want to make sure that you have a fall back to open standard codes, so you may want to add another criteria that the vendor can provide that technology.

The discussion about business models and vendor selection should in no way suggest that this is the full list of vendor qualification, as we all know is a long list and every operator has it..

The starting point is identifying the sources for the potential revenue streams that an operator can enable, and these would be:

• 3rd party campaigns: Brands, ad agencies, advertisers etc.
• Operator offerings: Content (wallpapers, ringtones,...) and services (ex.: mobile payments)
• B2B applications: Couriers, Anti-Counterfeiting, Medical applications etc.
• Premium code scanning services for subscribers

You will note that I had not mentioned any sort of charging the subscriber for the standard code scanning service. To me, that is against the spirit of the service: you want to encourage adoption and remove any barriers in the way. charging the subscribers upfront is shortsighted and would cripple adoption and future revenues.

Given the maturity of this space, although very feasible by vendors, it is difficult for me to see in the near future operators leaning towards higher upfront non-recurring payment in a possible code scanning licensing deal with a vendor. I personally think that pushing for a higher setup fee is somewhat shortsighted by vendors.

Instead, I think that early adopter operators would like to see more of the upside that is associated with their win, and that can be attached to the following streams:

• 3rd party campaigns: Those campaigns would typically be associated with web access and/or SMS campaigns. the ideal business model there would be a mix of flat-fee rev share, a per click google-like click-thru model, or per SMS transaction. Keep in mind 3rd party campaigns would not launch on day one of the service launch. The first campaigns to be launched would be operator campaigns to test the water. The ideal scenario is that both the operator (who typically has geographical advantage and legacy deals with local brands) and the vendor would strive to bring in 3rd parties. The important lesson here, is even if the vendor or operator do not have a clear precise idea how to price 3rd party campaigns, they should put something on paper so that it doesn't break the deal. an imperfect deal is better than a no-deal.
  
• Operator campaigns: Operators would typically want to see an initial period where the service is launched. Call it a trial or initial launch, on that period it might be that only the operator would have running campaigns. That period might be an exception to the longer-term pricing model for the operator. Like the brands, operator campaigns would be typically web or SMS based, hence they can be charged per click, per campaign, per period (monthly?) or as flat fee (the latter unlikely).
• B2B: Those kind of deals would typically require intense customization that the vendor may want to pick up anyway. The reasonable model would be per license and period as it is very easy to measure and is attached to the success of the business, in most cases.
• Premium subscriber services: This is an interesting point. In my view, premium code scanning personal services would go into two categories: Personal productivity (adding a meeting to your calendar, adding a task to your to-do list, changing profile to 'meeting') and mobile social services (launch a PoC session, initiate a video call). In this particular case I think it would be difficult to track the transactions as they might take place locally on the phone, and also subscribers could create their own codes (meaning that it is not necessarily brands that would create the codes). hence a combination of charging per download and possibly per code creation seems to me the best way to go.

I think that the key to a healthy ecosystem is winning operator deals initially, and that requires identifying those operators who are early technology adopters and live of innovation. One might find those in geographies where the subscriber base is very receptive to new technologies (sometimes there's some correlation with pre-paid subscribers).

In the next post I'll try to look at preparing the initial launch. What features a product manager for an operator should consider to make this initial launch sizzly enough, but not overwhelming.

I hope this was useful, thanks for reading, and I would appreciate your comments!

Mobile Code Scanning: Selecting the Technology

Selecting the code scanning technology for your campaigns is a critical step. There are key factors in making that decision, and those, to mention two, are the code format and the features that the complete solution can offer.

To accompany the technology+vendor selection process, a good thing to do is to have the vendor list handy, and fortunately Scoot Shaffer in his Blog had composed a long list of code scanning vendors. Many vendors support standard code formats (QR+DM) while others have their own proprietary code format, plus optional support for the standard codes.

The code format has implications on the user experience, the value driven through simple or complex use cases, through to the control an operator has on their ecosystem and the ways in which revenue can be generated.
The following are the key factors when looking at code formats:

• Standard vs. Proprietary: That's probably the key decision to be made. Today there are two leading open-standard code formats: QR and DM. Both are old timers: QR has been largely successful in Japan and DM has had its own successes. What you want to keep in mind as you make this decision, is that in every emerging ecosystem, there would be two types of solutions: The first would be the existing solutions that were "loaned" from other industries, those would typically have significant traction by that time (otherwise nobody would "reuse" them) and in some cases they might be open standard. New solutions will have, by definition, less traction, they would typically be too new to be open standard. But, new solutions would almost always be optimized to the objective. So it's up to you whether you want to optimize the technology to what you're trying to achieve, risking it's immaturity, or you go down the safe route with open standard codes. If you chose the standard codes you can stop reading now, choose QR and/or DM and move to the next decision. If you want to learn the differences that new and innovative solutions create, keep reading.
  A note has to be said here about the 'Mobile Code Consortium', trying to make sense out of all of this. On one hand, recognizing that advertisers are the gold pot and they would not be in the game if the market were fragmented by different codes is a strategic required decision to be made. On the other hand, this is not the first time that a consortium is gathered in a very early market. For more reading on this, Scott Shaffer had made a good post on this and so had I, and the bottom line is, when you look into this consortium, make sure you are comfortable with the forum, timing, agenda (which is public) and their motivations.
  

• Scanning Performance: Once of the objectives you want to get from code scanning is how easy it is to scan codes. This should be an obvious operation for a non-trained subscriber. It should be immediate to an enterprise user. You want to find codes that were optimized for "real human hands" environment, where everything goes: blur, rotation, angles, slight motion or shiver, different lighting and shading conditions etc. You also want to find the decoding application that provides a timely response rather than choking the phone's CPU for several good seconds.
  
• Code size has reach implications: Certain codes compress information better than others, so that the resulting image (usually measured in modules) is smaller. typically, codes would grow in size in proportion to the amount of data you try to put into them. In code scanning, there's a couple of parameters that count: How many pixels can you get from the phone's camera API and how many modules does the code have. what the decoder needs to be able to do is to contain the complete code in the image, and be able to determine each module. For that, there is a sweet-spot of how many pixels-per-module would optimize the probability to successfully decode the code. If you have a code format that does not compress well, the code would be large, and low-resolution phones would just not be able to scan that code.
• Information Reliability: OK, so you've successfully scanned the code, hooray! But-are you sure you got the right data? Error detection and correction algorithms are a must-have in code scanning systems, make sure they're there.
• Better Data Compression drives Flexible Use Cases: The better compression the code uses, the more information it contains per given size, the more data the code reader application can have immediately after decoding the code. The result is comprehensive UI that is more user friendly, and more complex, valuable use cases: anything from launching a local file on the phone to triggering a mobile payment transaction, including the merchant, the user, the amount and security fraud-prevention data, all of which can finally be transmitted over SMS to the mobile payment backend system.
• Aesthetics: Finally, one of the key features of the codes being a visual entity, is how can they be visually pleasing to the subscriber. The typically scenario would be that these codes would be embedded into an ad, and it is expected that the subscriber would be triggered to scan the code by the context of the ad, not by the code itself. Advertisers would be highly aware of the space the code takes and how does it embed well in the graphics of the ad. They would be surprised to see how their logo embeds in an interesting way into the code, or the code into the logo. Therefore, aesthetic features like code shapes, code coloring, module shapes and coloring and others are likely to be of high value to advertisers.

There are probably more code format features, but let's turn the attention now to the solution features that are important to look at:

• Direct vs. Indirect resolution: The resolution point is where does the code content translate into an actual action, like launching the browser to a URL, adding a contact to the address book, sending an SMS etc. Some code formats only allow limited data to be carried in the code, such that essentially the code itself would typically only contain some index, the code reader application on the phone would connect to a web server ("Central Resolution Server") to say what action is associated with this index. This is called "Indirect Resolution". In contrast, code formats that allow more data to be carried in the code, in some cases allow the code reader to translate and take a local action, immediately on the phone without necessarily having to connect to that resolution server. I call that "Direct Resolution". For example, if we're looking at an SMS code, if the code can contain something that tells it's an SMS, and then the target phone number and the content of the message, then there's no need to connect to a remote server to send the SMS. There are a couple of differences in comparing direct and indirect resolution:
  • Direct resolution provides immediate value to the subscriber: when the subscriber scans the code and they immediately see what the code does (for example, see the SMS message composer screen pop up) that immediacy is very pleasing to the subscriber. using the indirect system, having to connect to a remote resolution server to resolve the index BEFORE the user even knows what the code does, is somewhat degraded user experience.
  • Reliability: The indirect resolution system relies on the user's patience while the phone attempts to connect to the remote resolution server, that the user indeed has data plan and is in data network coverage area and so forth. the direct resolution system is autonomous for those codes that contain the data.
  • Use cases include local actions: the ability of the code reader application on the phone to scan a code and have all the information it needs, means that the code reader, being an application running on the phone, can take any action using the phone's resources: launching a local multimedia file, adding a contact to the address book, adding a meeting to the calendar, sending an SMS and much more. More important, complex use cases can be thought of where the combination of the data in the code, samples of the user's context (location, time etc.) and collecting user input can be performed before taking the action. Typically, remote resolution systems launch the phone's web browser and from there the actions that can be taken are somewhat limited.
  • Monitoring: to the benefit of remote resolution systems is that they inherently provide monitoring and reporting mechanisms that, if installed on the code reader application, might be unpopular by users who would find out about them.
  • Registration and maintenance: Usually the location of the resolution server is a powerful negotiation point. Who controls that server, how is it being maintained, can users create codes or brands only. All these are valid questions to be asked and they have a lot of bearing on the business models that are created finally.
    

• Support for subscriber code creation as well as enterprises: the architecture of the solution is very important factor to look at. Whether initially subscriber code creation tools are important or not, for example, to encourage adoption you will want subscribers to get familiar with code solution and promote it to their friends.
• Reach: You will want to maximize the effect on your subscribers. You want to choose between support for all your new phones that are sold in stores, or support for a high chunk of your install base. there are different mobile operating systems and you want to think how to maximize the potential of this solution. Reach is very important to subscribers' friends...
• Control on your ecosystem: This is probably one of the most important issues you want to look at. Essentially, if you're working with open-standard codes, everyone can create those codes, everyone can scan those codes. Well, what if you need some control? For example, you have an SMS-based mobile payment system. the parameters of each transaction are made of the vendor, the price, the product and the user identity. You will not want someone to decipher your codes, change the price and attach it to products, would you? Some proprietary code-based solutions allow you to have better control on who creates codes, who can scan which codes and what happens when an authorized user scans that code, or an unauthorized user scan that code. with those systems you can fully customize the user experience so that it is predictable, user friendly, you can control the user input collection, you can add hidden security information for fraud prevention, for example, and you can control the resulting transaction.
• Support for open-standard codes: If you have gone down the road of choosing a proprietary code format-based solution, you may be anxious whether that code format will make it successfully. In that case, you may want to ask the vendor whether they support open-standard code formats "just in case". If they do, you can launch your solution with confidence that you have an optimized solution and a fall back if all hell breaks.

I hope that provides a pretty good coverage of the issues you want to put on your check list when selecting the technology. You want to keep in mind the business goals and the revenue streams I discussed in an earlier post so you don't get lost in the technology maze. A successful solution is not necessarily the technological robust one, its the one that makes sense to your audience and your organization.

In benchmarking different technologies you want to research the web, you will find that independent academic researches have been made on different codes, you will find that creating codes yourself and downloading the matching code reader to your phone will give you a lot of insight into how this thing really works and from there you can evangelize on innovative services in your ecosystem.

On the next quick post I will talk a briefly about vendor selection, and specifically discuss how sometimes technology "features/limitations" (you pick) mandate the vendor's business model with the operator.

I hope you found this useful, thanks for reading!

Mobile Code Scanning: The Enterprise Application Opportunity

Following my post that mentioned possible revenue stream for operators, that arise from code-based solutions, I have been asked about code-based enterprise applications. That's a great question, since many players in the space have to focus on the vertical they believe in. Code scanning is a technology enabler, that applies to many verticals, so it's a tough choice.


Let's take a closer look at enterprise vertical. Firstly, the mobile code scanning solution could prove highly feasible for them. What options do businesses with field force have (take for example a courier business):

• No Automation: Keep the current system, no upgrade costs. OK...let's look at how much revenue a typical independent courier looses: Let's take the case where that courier has 10-50 drivers (take 25), each doing 50 deliveries/day. Let's say a total 20k deliveries a month. Each package lost/delivery dispute/... cost is $5. Let's say the combination of human errors in tracking, delivery and invoicing is 5%. Not automating the system can cost a courier $5k/month. That's $60k/year under very modest numbers.
  
• Sophisticated off-the-shelve automation: buy a dedicated scanning hand held device. A typical price point for that kind of ruggadized- good-for-nothing-else device would be in the hundreds of $. Once you have that, can one do any customization to enable business logic on the reader? unlikely
  
• Code Scanning solution that would install virtually on any off-the-shelve handset and connect to an existing backend API to a database, invoicing system etc. It's possible to embed business logic and user interface customization. Drivers need phones anyway...that's an easier decision to make

Now that hopefully the case for mobile code scanning automation for enterprise users is established, here's a couple more advantages to focus on this vertical:

• No Reach issues: one very difficult challenge every application developer in the mobile space faces, is that every single phone is different. It's different because vendors, amongst other reasons, want to differentiate :-) That means, if your application targets subscribers, you have to make sure the application works on all those different phones. Not in the enterprise world. The IT manager would in fact mandate that only one phone would be used to reduce his maintenance cost. Big relief
• Building the complete solution: Usually enterprises know their context much better than the code scanning vendor does. They will be more inclined to get an SDK (hence the case for SDK for enterprises!) and build their own solution, which might be already built, but currently based on manual keystrokes. If they don't take ownership of building the solution, enterprises will pay handsomely for you to build it, as they can see the immediate upside
• It is possible to build a very simple, consistent business model that works for both sides. Almost no dependency on unknown factors. You can go per license, per usage, per month, doesn't matter. It's very cleans and concise.
• In most cases, the decision making process is not as long and complex as launching a consumer product. the requirements are usually clear, there aren't massive demo and trial requirements, and proceeding to the final solution is in both sides benefit.
• In some cases, enterprise users use very capable high-end phones and would be open to high-end numbers in your proposal :-)
  

I think it would be worthwhile contrasting 3 code-based enterprise solution requirements against the consumer solution:

• Rapid successful scans: Typically, the enterprise user (courier for example) doesn't have time for multiple scans. He has to be able to successfully scan rapidly and move on. Codes that were designed for the mobile context (deal with blur, slight motion, rotation, different lighting conditions) will do better at this
• Reliability: There's a lot at stake in taking in erroneous data. Algorithms that deal with error detection and correction are very applicable here
• Encryption: some businesses may want to contain sensitive information in the code. The implication here is that they would not want, for example, for just anyone to be able to read (and then possibly recreate) their codes, which can easily be done with open standard codes.

In contrast, typical businesses would not care as much about code size and other aesthetic features like consumer-facing brands would.

OK, I hope that gives some sense to the case for mobile code scanning for businesses. Like said, it's not an obvious decision to point your strategy there because code scanning can be applied in many, attractive fields, and you need to be wise when you go about it.

Hope that's useful, thanks for reading!

Mobile Code Scanning: Subscribers (1)

In the last post I've talked about understanding the two most critical factors at code scanning:

• What can Code Scanning do
• How can an operator monetize that

In this new post I want to talk about your subscribers. As a product manager, this is your audience, so know them well and make them happy. Specifically, these days it is common to look at the 'young and restless' 15-25 age group as technology-savvy, curious and receptive of innovative offerings. This will be the first of two posts I'll make on the subscriber aspect: on the first I'll try to share my thoughts on what is it that they are expecting a solution to be like. That will help shape the solution and the technology/vendor decision criteria. On the second post (after we've chosen a technology and vendor), I'll try to look at what key factors contribute to adoption when launching the first code scanning campaign.
Let me remind the two disclaimers I made in the first post on the subject.

So thinking of a 18-year old who had just experienced code scanning for the first time, the words I would love to hear them tell their friend is: "WOW. This is SO COOL. You GOT to try it!"
Take a closer look into it. To me, this sentence divides into two sections: "so cool" and "you got to try it". And this is how I translate those into subscriber expectations:
"So Cool" means "I am surprised because..."

• "...I got great value": Perhaps the most important key to this equation, is the value that you can deliver with code scanning. It could be the simplest thing like the latest ringtone of a favorite band, it could be as complex as paying for a purchase using the phone. It doesn't make a difference how complex is the technical use case and prompts, what matters is that the value delivered is not obvious.
• "...it was real easy": If the code scanning process is anything other than obvious, it will be as popular as typing a URL on a phone. nobody will do it. A- the operation needs to be obvious and B- the code scanning success rate has to be very high. Again, nobody will try scanning after they failed more than 3 times. they'll just give up.
• "...it worked": An obvious, but I had to mention it. Make sure sufficient QA is being done. Subscribers take it for granted and will not be very forgiving for bugs.

"You got to try it" means

• Reach: In high probability, it is available for your phone too (otherwise it will never take off)
• It's real easy to get: It is available through distribution mechanisms that make it available easily, like shortcodes etc.

Understanding the basic audience expectations will drive adoption and the resulting revenue. Make sure you relate to the key factors as you plan your campaign, especially the marketing side of it, so that users know what to expect.

I hope that was useful. In the next post I'll try to look closer at the process of selecting the technology and vendor. The way I see it, it is a process split between the code format, the derived advantages, and the business criteria that are related to the vendor selection. It is already sleeves-up step so I'm looking forward to discuss it.
Thanks for reading!

Mobile Code Scanning: the Starting Point

These days, if you're a mobile operator, MVNO, dealing with mobile content or services, then you probably are involved in some form in mobile Code scanning (Otherwise known as 'Physical World Connection') . Many players in the space are being pitched with the technology, or will be soon.
Having been in the space for a short while, I've decided to share some of my notes on mobile code scanning, where to start, what considerations should one make when selecting a technology and vendor, what are the key challenges that one might want to focus on when launching code-scanning campaign and more.
I should be making two quick notes:

1. In no way am I considering myself the know-all authority on this. This is an open discussion with whoever would care to comment, hopefully we'll get a useful discussion going.
2. The following are my independent, unbiased (I'll try!) thoughts on the subjects, and should not be affiliated with any one vendor. I will try my best to not recommend or favor one technology or vendor over the other, only present the decisions points, the rest is up to you!

So, the first and most important step, I think, is to deal with two things that one can take from this:

1. What can mobile code scanning do for you (, your subscribers, your audience, your shoppers,...)
2. How can one monetize that (AKA revenue streams)
   

So what does Mobile code scanning do for you? (Let's drop all the marketing spin:) Mobile code scanning connects (your) subscribers to the infinite sea of content and services you put in for them, and they never seem to use. Why? because nobody types a URL on their mobile phones (OK, nobody refers to 99% of users). Because nobody knows how to get to, operate and enjoy that great/useful/amazing/... game/application/community/... that you (Operator) just paid to make available. Because keystrokes are a usability barrier on phones.
There are many ways to think about "increasing usability": Voice recognition, text recognition etc., one of which is code scanning. Essentially use the on-board camera to collect and obtain information from the physical object they are looking (and interested) at: an ad, signage, interesting site, informational note (bus schedule) etc.
The advantages in code scanning, compared to other usability methods mentioned, is essentially once you've educated your subscriber, it is very easy, (with the right algorithms) it is error free, it is far less vulnerable to the context you're in (if you're in a noisy environment, for example) and, it can deliver significant value to the user, instantly. For an operator, this could be a differentiator.

That said, there's a lot of marketing hype spread around. Let's keep one thing in mind: a CEO in the space recently said: "They (Subscribers-AR) don’t just wake up and say, ‘Hey, let’s go scan some bar codes.’" Mobile code scanning is an enabler, if you will. Its about the value that it brings the subscribers closer to.

With that in mind, the next step, and probably the most important one in this journey to mobile code scanning, is understanding the potential revenue streams for an operator. And those divide into the following three:

• Increase operator content & services discovery & consumption: All operators in the last few years have heard the term 'bit pipe' all too frequently and had taken a move on it. A lot has been invested in content and services, licensing, distribution and marketing. An operator can increase their content revenues tremendously if they made finding and downloading it an immediate, obvious process. In reality, finding content that one wants and downloading it, is not easy at all. Same goes for services that would be very useful, but it's just too laborious to get to. Take mobile purchasing for example. Those sophisticated systems are usually SMS-based, and require the user to type in (correctly!) the merchant, how much they want to pay, possibly some identification etc... How many people would actually go about that? Imagine the alternative, where a simple code would contain most of the parameters required for the transaction, and all that is left to the user is to approve the transaction? consider the implied operator revenues in the messaging transactions and rev share opportunities.
• Incorporate 3rd party brand campaigns: When speaking of marketing budgets of ad agencies and brands, everyone start dreaming...sweet dreams. Operators have unique standing in the mobile code scanning space these days: it is early days for brands to go directly into code-based campaigns, essentially because "how many of my audience will have the code reader installed and will know what to do with this stuff?". However, if an operator is involved, well they can enable the code reader on phones, they will run a couple pilots to kick-start the buzz etc. That's where advertisers will be happy to see increased site visits, increased participation in SMS campaigns and contests through codes embedded into their ads. That's where an operator can reel 3rd parties in and sign them on click-through or rev share deals like hot buns, and they'll love it.
• B2B Mobile Code Scanning Services: There are many businesses that would benefit significantly from automation and communications at a much lower cost than commercial grade code scanning systems. They typically have little or no automation, their transactions would be managed manually and by the time the invoice goes out, resolving an exception would be almost impossible. The obvious use case would be the small couriers that lack automation and the existing solutions are just too complex and expensive. With mobile code scanning they get computing power and communications using far cheaper customized solutions than they would ever get otherwise. There's a lot to gain by offering code-based enterprise applications to this vertical.

Having looked at possible operator revenue streams that code scanning can enable or increase, there may be more, it is important to think what are the business models and the ways an operator can monetize on those streams, which is not a trivial task. Looking at that would also help in thinking of the acceptable business model with the technology vendor, such that the ecosystem is healthy and everyone's happy.

On the next posts I'll try to look at two issues: what do (I think) consumers care about and what should an operator be considering when choosing a technology (and) vendor.

Thanks for reading, looking forward to interact with your comments!

Guy Kawasaki must read: Ten Questions with Jeffrey Pfeffer

I've mentioned this before, Guy Kawasaki's blog "How to Change the World" is an enjoyable, educational must read for entrepreneurs and whoever is even remotely interested in the bigger picture of where is the organization he/she is with is headed.

This particular piece that Guy just posted is one of the best ones I've ever read, it gives a unique advice and analysis of organizational behavior and strategy lessons. And, perhaps it is very relevant to my thinking these days. Many of the Q&A are very relevant, "What is the proper role for a CEO?" ,
"What does it say about a company if it asks a candidate with twenty years of experience to submit school transcripts?",
"What role should budgets play in the management of an organization?" etc.


Here's the last question (just to show that you got to read till the end :-)):

Question: What role should strategic planning play in the management of an organization?

Answer: Doing the right thing is important, which is where strategy comes in. But doing that thing well—execution—is what sets companies apart. After all, every football play is designed to go for a huge gain. The reason it doesn’t is because of execution—people drop balls, miss blocks, go to the wrong place, and so forth. So, success depends on execution—on the ability to get things done.