Category Archives: Technology

The Next Big Thingd?

Thingd (Thing Daemon) is building a structured database of every object in the world and then mapping those objects (and associated metadata) to people and to other objects.  The concept is still in its early stages of being realized, but it is a big ambitious idea and one worth thinking more about.

The easy (and slightly inaccurate) way to put Thingd in context is: Facebook organizes people, Google organizes information, and Thingd organizes things.  The lines get blurry though and I’ve written before about how Facebook and Hunch are creating massive collaborative filters that can improve recommendations for ecommerce and deliver more targeted content and ads across the web.

Thingd approaches the problem differently by focusing on the database itself.  It’s basically a utility in the way that twitter has been described as a utility.  It is a product whose core function is so basic that it can power a multitude of applications.  That is the promise and the reason for the excitement.

For example, Plastastic is a game for toy collectors that is built on the Thingd database (by Thingd).  Because it pulls structured data from Thingd, the site enables extremely granular browsing.  For example, you can browse for toys that are only 5.5″ tall.  More importantly, you signal your purchase interest by clicking “Have it” or “Want it” (similar to Like).  By “Wanting” lots of Handpainted Resin toys, Plastastic could show you other toys that people with similar tastes Like.  So, what’s exciting is not necessarily the collaborative filtering, but Thingd’s structured data (as long as it is of high quality).  Assuming an API is released, anyone could leverage Thingd’s structured data to build completely new kinds of web services.

Since Thingd’s database will theoretically include every object, it could empower anyone to very easily become a buyer and (passive) seller via its marketplace.  One could also imagine extending Thingd to other services: consider how Thingd could be integrated with Facebook profiles.  It would be far more useful than Facebook Marketplace.  Using image recognition, the database could also be used to power affiliate services on sites like Pinterest and Aprizi (similar to how Pixazza works).  While an affiliate business model is a first thought, other more interesting models could emerge.

Thingd also launched a platform for mobile developers called productids.org which provides access to >100 million UPC barcodes tied to Thingd’s database.  So, if you’re shopping for a bike at a store, imagine an app that could scan a bike’s barcode with your smartphone and then browse for similar bikes based on the specific attributes you care about (style, number of speeds, material, color, etc.).  You could check prices and availability online and at physical stores (via Milo).  An integration with Google Goggles would be even cooler: take a picture instead of scanning the barcode.

In addition to ecommerce business models, advertisers and publishers might also be interested in connecting to people based on users’ prospective (Want It) and historical (Have It) purchase habits.  As long as the structured data is consistent and clean (very difficult to achieve if attributes are crowdsourced), there is a lot a developer could do with a Thingd API.

The immediate challenge for Thingd is to continue improving the user experience while building and refining its database.  While the experience on Thingd.com isn’t seamless yet, the company recently launched Fancy, which is a lot more user-friendly than Thingd.com in allowing you to tag images and discover new stuff.  Fancy will make it easier for Thingd to collect data on more objects and there’s no doubt the company will be adding features as it rolls out (would be nice to have a bookmarklet for easier off-site tagging; small design tweaks like tiled images and infinite scrolling).

It’s clear that there is no shortage of options for Thingd, so the question will be product focus and execution.  I’m really excited to see how Thingd develops.  It’s working on a truly massive idea.

Coke’s API and the Outsourcing of Innovation

While he may not have realized it at the time, Asa Griggs Candler helped pioneer the “platform” business model used by thousands of web companies today.  But Chandler wasn’t a tech startup guy, he was the founder of The Coca-Cola Company.

Coke became a platform company almost by accident.  Beginning in 1886, Coke was principally sold to soda fountains and Candler saw little demand for bottled Coke.  Couldn’t you just get a Coke at your local drugstore?  Besides, creating a bottling and distribution operation was expensive, and lower-margin.  The Coca-Cola Company had great margins.  They didn’t even make the Coke that people drank.  They manufactured concentrated Coke syrup and marketed the final product.  It was the pharmacy soda fountains that added carbonated water to Coke’s concentrate to make the drink.

In the late 1890’s, Candler was approached by two Chattanooga businessmen who proposed creating a Coke bottling operation.  Candler signed a contract with the two men, giving them control of Coke bottling for one dollar (Candler never actually collected the dollar).  Whether Candler didn’t see the potential for bottled Coke or was nervous about the risks and costs associated with building a bottling operation in-house, the decision was incredibly beneficial to Coke over the long-term.  Coke was able to focus on its two core competencies while the technology and manufacturing processes required to bottle mass quantities of soda developed in parallel.  Coke benefited massively from the greater volume and distribution that bottlers enabled.

APIs provide a similar function in the programming world.  Platform companies such as Twitter have stuck to developing their core capabilities (their syrup and marketing) while enabling others to innovate around the Twitter APIs.  Basically, it’s a licensing strategy.  As of the Spring, Twitter was generating about 75% of its traffic through third-party clients (its bottlers) utilizing the Twitter APIs.

Apple’s app strategy for iOS is another example.  Apple developed a few core applications (iCal, Safari, Mail, etc.) for the iPhone platform and then enabled the creation of hundreds of thousands of applications via the iOS SDK.  This has enabled Apple to create enormous value for its platform without shouldering the costs of building thousands of applications in-house (which it couldn’t do with the same efficiency and creativity of its developer community anyway).

There are of course benefits and dangers to innovating on top of another company’s platform.  Primarily, there is a hold-up problem with this type of innovation.  For example, Coke could hold its bottlers hostage and force the bottlers to pay higher fees for concentrate.  On the other hand, bottlers could threaten to choke off Coke’s distribution.  The way to solve these hold-up problems and to improve manufacturer-supplier coordination is through vertical integration, and that’s exactly what we have seen from both Coke and Twitter.

Vertical integration allows a company to remove coordination problems and reduce costs by bringing the relevant supplier(s) or partner(s) in-house.  Coke did this by acquiring its North American bottling partner in February 2010.  Twitter did this by acquiring complementary functions such as search (Summize) and mobile (Tweetie).  These acquisitions reduced coordination problems for Twitter, enabling them to accelerate development of their roadmap.   Most importantly, both companies were able to maintain focus while enabling the ancillary innovation that would become critical to their long-term growth.

On a much broader level, the trend of outsourcing corporate R&D to venture-funded companies seems to be accelerating.  Steven Kaplan and Josh Lerner wrote a great paper explaining this trend, noting that venture-backed firms are three times as efficient in generating innovations as corporate research.  Incumbent (and upstart) technology companies can take advantage of this trend by providing entrepreneurs with the tools that accelerate innovation: API’s, open source software, and greater access to data/information.

The Data Storage Conundrum & Oscar Wilde

The Economist is a great “newspaper”, my favorite.  A couple weeks ago they did a special report on “The Data Deluge” which explored the recent and rapid expansion of data, and how to handle it.  There were two parts of the report that caught my eye because they seemed contradictory.  The first was an 1894 quote from Oscar Wilde:

It is a very sad thing that nowadays there is so little useless information.

To which The Economist added, “He did not know the half of it”.

The other part was this chart:

The question I have is, if there’s “so little useless information”, why doesn’t data storage more closely track data creation?  Wouldn’t one want to store and analyze all of this data if it were truly useful? It’s a pretty obvious but important question because the answers could tell us a lot about what we as a society think is valuable.  So what are some potential answers?

We Don’t Value the Data We Create Enough, So We Don’t Store It
Maybe we already store all the data we deem important enough to save.   Everything else is expendable. It’s not free to store data, so one has to weigh costs and benefits about what is kept and what is not.   It’s possible that this excess data doesn’t have any value, but I doubt it.

We Know the Data We Create is Somehow Valuable, But We Don’t Know How to Make it Valuable
This scenario argues for more statisticians or better tools to extract insights from large data sets.   Most data is unstructured and it takes specific expertise to organize and analyze it.  Generally speaking, it’s big companies that have the in-house skills needed to glean real value from these data.  Smaller- and medium-sized businesses generate plenty of data, too, but they may lack the resources and personnel required to make their data useful and actionable.  When a business decides what data gets stored and what sublimates, it will only spend money storing what is required to run the business and nothing more.

We Throw Out Old Data, So Available Storage Capacity Lags New Data Creation
Perhaps older data is perceived as less valuable (rightly or wrongly) and is discarded as it expires.  This “hole” in the bottom of the proverbial cup would account for the flatter growth in available storage vs. information created.

We Can’t Make Data Storage Capabilities Fast Enough to Store the Data
This would be a great problem for companies such as EMC to have, but it’s just not the case.  It’s becoming less expensive to store more data. Kenneth Cukier points out that companies such as Wal-Mart store more than 2.5 petabytes (the equivalent of 167 times the books in the Library of Congress) of data, fed by more than 1 million customer transactions per hour.  Facebook stores over 40 billion photos.  Guaranteed that Facebook’s “available storage” curve closely hugs its “information created” curve because obviously Facebook sees economic value in storing its users’ data.  It’s a safe bet that Facebook’s “available storage” curve is actually above its “information created” curve since FB probably has at least two mirrors for each piece of data.

There’s no doubt that data is becoming a more valuable commodity, even to businesses that have traditionally been less data-intensive than the Facebooks of the world.   The bottom line is that it’s relatively expensive to store data (vs. discard it), so we need to have a good reason to store it.  Perhaps the solution is to create better tools that can make data more useful for people who lack interest or training in statistics and data mining.  This may be another aspect of The Facebook Imperative that Marc Benioff recently wrote about.  Companies such as Oracle, SAS, SAP, Salesforce, and Tibco already offer software tools to help make data more useful, so there’s got to be something else pulling down the growth in data storage.  Maybe there’s just a lack of will to implement and use these tools?  What do you think?

Reblog this post [with Zemanta]

Will Apple Bet the Farm on Quattro Wireless?

Apple‘s recent purchase of mobile ad network Quattro Wireless may signify a much more significant shift in Apple’s business model than it would otherwise seem.

So, why did Apple buy Quattro (Apple earlier sought to buy market-leader AdMob, but ceded the purchase to Google once the price became too rich)?  Apple has always focused on providing well-designed, tightly-integrated software and hardware to customers willing to pay a premium for these qualities.  The focus has always been profits over an indeterminate quest for market share and that strategy has proved very durable.  With that in mind, my guess is that Apple will initially use Quattro to better monetize the large number of free apps (perhaps 9:1, free:paid) in the App Store.   While free apps help iPhone/iPodTouch sales by making the devices more useful, Apple’s 30% take on free app sales is still $0.  Beyond iPhone/Touch, being able to monetize content via an ad-supported model will become more important as publishers begin to distribute content on the iPad.  While the iPhone/Touch/Pad SDK enables app developers to charge for incremental purchases within apps, Apple will need an ad platform to satisfy the needs of various publishers, particularly on the iPad.   These are all practical tactics that make a lot of sense in the context of Apple’s strategy to monetize “closed” platforms that benefit from tightly integrated software and hardware.

Apple’s critics have faulted the company for not being more “open” with the iPhone/Touch/iPad OS (“open”, meaning device agnostic, with no app approval process).  Critics say Apple is making the same mistakes today as it did during the OS wars.  The battle then was Apple’s “closed” model that exclusively paired Apple software to Apple hardware, versus Microsoft’s decision to allow its software to run on any hardware device (with certain controls).  We all know the result: Microsoft has something like >85% of the OS market vs. ~10% for Apple.   The argument is that Google’s “open” Android platform will eat Apple’s lunch just as Microsoft did, and Apple will be relegated to distant second place in mobile.

Others argue (using Clayton Christensen’s theory) that Apple does not need to open up since customers will continue to value higher-performance mobile devices over lower-priced commodity ones for the next decade or so. It’s hard to argue against this, but it is difficult to time innovation to anticipate customers’ needs, especially when you’re targeting global markets each with unique demand.  More importantly, the competitive attribute may not be device performance, but app costs (i.e. look at the substitutes: free turn-by-turn GPS on Android vs. $59.99 for TomTom‘s US GPS app on iPhone).  Couple this with the fact that the iPhone’s gross margins are decreasing and that iPhones account for more than 30% (!) of Apple’s ’09 Net Sales, Apple may be in a tighter spot sooner rather than later.

Before Quattro, Apple’s mobile business model could not compete with Google’s ad-based model because Apple’s incentives to sell more iPhones and paid apps simply did not enable it to do so.  Google benefits from an open platform because it gives Google broader reach to sell more ads.  More importantly, as Bill Gurley points out, Android offers a “less than free” business model to carriers that want to license Android.  Carriers that license Android split ad revenues with Google, so instead of carriers paying to license an OS, carriers are getting paid to use Android.  And with traditionally expensive apps such as turn-by-turn navigation becoming free on Android (ad supported), it will be difficult for Apple to continue making money off of app sales commissions.

While Apple has remained “closed”, the Quattro purchase will enable the company to pursue a more open strategy that would enable Apple to benefit financially (ad-supported) from ubiquity.  A more “open” system would allow the iPhone/Touch/Pad OS to run on non-Apple hardware (managing this ecosystem would be more complex) and enable developers to launch apps more easily. Of course, this would go entirely against Apple’s long history of tightly integrating its hardware to its software, but Apple has done 180’s before (Perhaps in a calculated way.  Jobs once said something like, “nobody will ever want to watch video on a small screen” before they launched the iPod with video).  The decision to open up would look highly unlikely in the context of Apple’s recent decision to remove certain adult-themed applications from the App Store.  Nonetheless, while Apple is rightfully focusing on getting its phones on more carriers worldwide, Quattro Wireless could be the genesis of a more “open” (but bet-the-farm) strategy at Apple.

Reblog this post [with Zemanta]

How Square is Building a Two-Market Platform One Market at a Time

The innovation in mobile is really getting exciting, especially as it relates to advertising and payments.  My last post touched on this but I wanted to dig a little deeper.  The experience of paying for things now, particularly face-to-face transactions, leaves a lot to be desired.  When I frequent a local business, I’d like them to know that I’m a repeat customer and to know what I’ve bought in the past.  Local businesses would love to know this stuff, too, so that they could reward loyal customers with targeted offers and provide more personalized service (“How’d you like Factotum?  You might also want to check out Oracle Night if you haven’t read it.”).  There are social opportunities for local businesses as well.  For example, I might want to recommend purchases I’ve made to friends and family members a la Blippy (but perhaps in a more private way).  There is a lot that can be done to make payments more accessible, useful, and rewarding, and I think we’re going to see a lot of innovation targeting these features.

The incumbents in the payment market have historically focused on the transactions themselves: how to process them faster, make them more secure, and convenient.  The incumbents include the card issuers, acquirers, credit card associations (Visa, MasterCard, etc.), POS manufacturers, companies such as PayPal, and related service providers.  Beyond the services offered by companies such as Catalina Marketing, there hasn’t been a lot of innovation around the purchase experience or the data that is generated during the transaction (location, item-level purchase data, an individual’s purchase history, etc.).  And while there has been progress in improving card issuers’ “online billing” sites, those sites are still terrible at presenting information and making that information useful.

It’s conventional wisdom that PayPal is best positioned to lead the next cycle of innovation in payments but I’m skeptical of this.  Following its acquisition by eBay, PayPal’s culture of innovation was subsumed by the far more measured innovation ethic at eBay.  At PlaceVine we are users of PayPal’s APIs – including the recurring billing features – and the experience has been exasperating at best.  Other developers I have spoken with have found the APIs similarly frustrating.  While PayPal has the huge benefit of a large installed base of customers and recently announced its new global payments platform, PayPal X (“X” was also the name of Elon Musk’s payments company which merged with Peter Thiel’s Confinity (PayPal was its flagship brand) to become PayPal), there is opportunity for upstarts with fresh approaches unburdened by legacy platforms and business models.

It is notoriously difficult for payment platforms to achieve ubiquity (how many other PayPal’s do you know of?) but one company is taking an interesting approach to payments: Square.  While Square – the payments company launched by twitter-creator Jack Dorsey – has received a lot of recent buzz, it’s not all hype.  Square enables anyone with an iPhone, iPod Touch, or Blackberry to accept credit card payments via a dongle that plugs into the device’s headphone jack.  The service also bundles in a merchant account that doesn’t require monthly fees (Square’s initial plan will be to make money on transaction fees).

I imagine the dongle will only be one of many ways Square will accept payments (here is a demo of Square running on Apple’s new Linea Pro iPod Touch POS from Infinite Peripherals), but the strategy to focus first on accepting credit cards is a smart one.  The company is making a number of solid strategic moves.

How Square is Building a Two-Market Platform, One Market at a Time
Leveraging the Installed Base of Cardholders
The credit card business is a two-market platform (aka two-sided market) as it requires cardholders (to buy things) and merchants (to accept holders’ payments).  PlaceVine is another example of a two-market platform as it requires both content producers and marketers in order for the platform to create value.  Diners Club was the first charge card company and they started off by mailing a thousand or so cards to affluent New Yorkers while convincing a group of restaurants to accept them.  Simultaneously building a two-market platform is a classic chicken-and-egg problem and it takes brute force and (usually) a lot of capital to get both markets onto the platform.

Square wants to “design” the purchase process and we can assume they would like for people to eventually pay with Square (instead of paying with Amex, MC, etc.).  But it’s too expensive (and slow) for them to try and acquire  payers directly (as Diner’s Club did with cardholders).  So, instead they are focusing on under-served merchants (which will also be expensive to acquire, but less so) and leveraging the enormous installed base of credit cards in the hands of payers.  In other words, Square doesn’t need to build the payer side of the platform in order for Square to be useful.  Payers can buy from Square merchants using credit cards at first and Square can roll out a service for payers later on.  Assuming that Square can gain traction among merchants, Square can begin to short-circuit the major costs and challenges of simultaneously building a two-market platform.  How will they do this?  Receipts!

Receipts Will Help Drive Square Adoption Among Payers
As Dorsey mentioned, receipts offer a huge opportunity for innovation.  Currently, receipts are just little pieces of paper without a whole lot of use.  However, when a payer buys something from a Square merchant, the payer can have the receipt emailed to her.  This feedback loop is critical because the receipt is a perfect touch point to expose the customer to what can be done with this data via Square.  The greater the number of Square merchants, the more receipts, the more services that will be built on top of this data, and thus the more frequently customers will be exposed to Square (this process will take years to gain critical mass, but it’s important).  If customers come to value the payment process provided by Square merchants, payer demand could be a positive factor in helping accelerate adoption among merchants.  The next step will then be to design payment capabilities for the payers (the other “market” in the two-market platform) so that they can ditch their credit cards and begin using Square to buy things.

Removing Friction Points to Gain Merchant Acceptance
So, Square is removing as many friction points as possible in order to build this two-market payment platform.  Leveraging the installed base of credit cards is one move.  The other is providing “free” merchant accounts and dongles to a category of merchants that have been under-served by incumbent technology and service providers.  By making it inexpensive (assuming the transaction-based fee structure is competitive) and easy for merchants to use Square, the company can focus on gaining traction from traditionally under-served merchants without rocking the boats of competitors focused on high-end POS deployments.

Focusing on Design, Social, and Open Systems
Creating a robust and ubiquitous payment utility is an enormous challenge, but Square is being built by a team that understands the benefits of simplicity, the social graph, and open systems.  The incumbents do not have this in their DNA.  Square is a classic disruptive technology but is unique in that it: 1) satisfies a need in the market that older POS technology could not fulfill (at least at Square’s launch; now there are competitors); and 2) as a software utility with (future) open APIs, it has the potential to move upmarket and take share from incumbent POS providers (ie those focused on major retailers) that may have initially discounted Square for its downmarket focus (again, the Apple Linea Pro/Square demo is a good example of where this could go).  #2 is especially powerful because developers will be looking to build on the most flexible and open platform.  When Foursquare begins building payments functionality in so that it can tie FS ads/check-ins to actual purchases (*the* local ad category killer IMO), what API will it implement?  It won’t be PayPal’s (and it’s not just because Crowley and Dorsey have invested in each others’ startups).
To the three people who have read this far, I can only apologize – this was too long!  More to come on this topic, but that’s all for now.

How Blippy Can Help Foursquare Monetize Check-Ins

Foursquare‘s great for a number of reasons.  Like a lot of people, I use it to keep track of my friends when I’m going out, but it’s also a fun way to discover new restaurants and other spots based on friends’ check-ins.  Since I go to great lengths to find awesome Chinese, Indian, Thai, Vietnamese, Korean, etc. food, Foursquare makes it easy for me to share these gems with my close friends.  It’s also a good way to keep a running log of where I’ve been.

While the “check-in” is already becoming a commodity (Yelp recently released check-in functionality and Facebook will, too), Foursquare has focus and timing on its side.  Back in 2006 I might have friended someone on Yelp because I liked a bunch of their reviews, but since I don’t know these people beyond their food rants I don’t want to share my real-time location with them.  FB will have a similar problem since a lot of people have hundreds of “friends”.  Unless FB can make it easy to select what friends you want to share location information with, it’s going to be such a noisy mess that it won’t have any value (let’s all hope FB check-ins will be opt-in).  The point is that people are figuring out the best way to use social networks and Foursquare’s launch happened to coincide with the steeper end of this learning curve.  Most Foursquare users I know are far more selective about who they accept as friends (typically one’s “real” friends) vs. who they friend on “older”, non-native-mobile social networks.

Whether it be mayorships, scavenger hunts, coupons, or other marketing or promotional offers, there seem to be a number of ways that Foursquare can begin to experiment with monetization.  The problem with most of these monetization schemes is that they’re a little klugey and require too much work for either the user and/or the business.  Coupons would be a challenge for Foursquare, because traditionally coupons are distributed by the manufacturer to the consumer and then redeemed at the point of sale with the help of the merchant.  There are three entities in this transaction, all of whom benefit at specific parts of the coupon value chain.  The merchant honors the coupon and gives the customer the discount but then the merchant has to submit the redeemed coupon in order to get repaid.  This works because the consumer has an incentive to use the coupon (to get the discount), and once it’s used, the merchant has an incentive to get repaid.  The manufacturer is happy because it got a sale it might otherwise not have received.

Now, consider what happens when a hypothetical FS coupon is redeemed at a small business (not a Best Buy which has sophisticated POS systems).  You’re at a packed bar and you show the bartender your coupon for a free beer.  The bartender (who is usually not the owner and has less incentive to keep track of these things) will need to somehow process the coupon so that you can’t reuse it.  Let’s say there’s a simple code he types into your phone (that’s awkward and slow) or maybe he just swipes a finger across the screen to process it.  The problem actually isn’t the processing, it’s that unlike in the supermarket example, there is no third party that will repay the business owner for the coupon.  If the bar pays FS directly for each coupon redeemed, the bartender has little incentive to process the coupon.  If the bar is paying for each coupon that gets redeemed, a less-than-honest business is not going to process (and pay for) the coupon once it’s already acquired the customer.  A CPM-based coupon system isn’t a great alternative either since it’s difficult to tie the ad to a specific action and thus to charge much for the coupon.

The point is that check ins don’t necessarily translate into dollars, but sales obviously do.  The real value for businesses (and for FS) is to harness the social and loyalty aspects of Foursquare and tie them to sales.  One way that Foursquare might do this is by partnering with a company such as Blippy that publicly tracks users’ purchases.  Blippy is still early in its development (launched about a month ago) and doesn’t have an API yet, but consider how a Foursquare check-in could be tied to the bar bill you forgot you racked up at Clandestino?  Businesses could begin to tie their mobile advertising spend to specific customer check-ins and related purchases.  You could then begin looking at people’s networks to better understand who the influencers are – the people who by virtue of their check-ins attract high-spending, loyal friends to the business.  If you’re interested in digging deeper into network science, you may want to check out Professor Michael Kearns‘ posts about his incredible class, Networked Life (if you happen to be a student at Penn, I highly recommend it).

The other way to do this would be to integrate a mobile payment API into Foursquare.  A service such as Venmo or Square could be a neat addition and it would solve the problem of tying the check-in and social features to the customer’s purchase.

Reblog this post [with Zemanta]