Tuesday, July 31, 2007

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!

Sunday, July 29, 2007

Mobile Code Scanning: Selecting the Technology

Image Attribute: OrangeJack, FlickrSelecting 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!

Wednesday, July 25, 2007

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!

Tuesday, July 24, 2007

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!

Thursday, July 19, 2007

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!

Friday, July 13, 2007

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.