Interview with Crypto Gurus

Interview discussing the future of digitized securities and what it means for investors.

Last  week I had the chance to have an in depth discussion with the folks at Crypto Gurus about Fetch, Security Tokens and Open Finance. We delve deep into the thesis that Security Tokens and Open Finance need each  other to grow and prosper.

You can view the view embedded below or directly on YouTube. Enjoy!

AWS for Finance

Ethereum is poised to become the enabler of a new way of fully digital finance. Just like AWS did for software backends.

Today,  financial innovation is slow, costly and reserved for the few. Often it  happens manually in spreadsheets and is available only for the largest  of investors. Open source blockchains and digital native assets are  changing this, just like AWS and open source did for software  development.

Ethereum is the AWS of finance, radically transforming the cost to build and release financial products.

It  used to be expensive to buy the servers and software licenses required  to release software. Companies raised millions and spent much of it on  Oracle licenses and server racks. Two things happened. Open source  systems (bye-bye Oracle database) replaced many expensive software  licenses, and AWS offered a pay-as-you-go system  to replace high upfront costs. As a result, the cost to build and  release a software product dropped 10x and massive experimentation blossomed.

Everybody benefits from the great software created as a result. Want an app to help meditate? Maybe find the cheapest gas station? No problem, software has you covered.

This same thing is happening in finance today. Open  source systems on Ethereum are replacing the expensive and manual  systems (DTCC, clearing, trustee) reducing the cost and time to bring  financial products to market. We’re on the cusp of an explosion of more efficient and open financial products.

The Layers of Finance

While  investors usually only pay attention to the top of the stack, what  products they can access, much of the important work happens under the  surface. To appreciate why we’re on the cusp of change, it’s important  to understand what’s going on under the covers.

In traditional finance, layer  upon layer of administrative (and very often manual) work falls to  interlocking players who have not modernized significantly in decades. This creates a baseline of inefficiency and cost that restricts innovation.

Ever  wonder why the minimum or cost for a financial product is so high? The reason usually lies in fixed costs or restrictions that come from an  intermediary lower in the stack. Tokenized  Finance upends this by replacing much of those intermediaries and fees  with trustless code, it’s digital at the core. That’s critical because  it’s the first step into turning finance into an API, making  programmable money a possibility.

A Simple Example

Let’s  take securities-based lending as an example. It’s a simple financial  product, cash loans using securities as collateral, and growing quickly.

In traditional finance, brokerages and banks offer customers competitive rates with minimums ranging from $50,000 to  $250,000 to access a cash loan. That’s not bad and gives investors an  opportunity to take a non-purpose loan while still retaining their  investment positions.

In Tokenized Finance, the financial product itself is code, protocols built on Ethereum A great example is MakerDao’s CDP which allows investors to deposit their collateral and take a cash-like  (DAI) loan. It’s simple and the rates are not too different than what  is available in traditional finance.

The  big difference is the lack of a minimum. Code just works. It works  exactly the same if the amount being deposited is worth $1 or $1M. And  because there are no fixed marginal costs from intermediaries, the  financial product as code can deliver the same value to the smallest and  largest of investors.

Now,  this may not seem like a big deal right now. Do you really want to take  a $1 loan? Probably not. It does however provide a glimpse into what a  future of code-driven financial products can offer.

What’s the Future?

Let’s add up what we know about Tokenized Finance.

  1. Transforms the core of finance into API, similar to how AWS turned software infrastructure into an API.
  2. Removes  the fixed costs and antiquated rules of the financial intermediaries,  removing barriers to bringing financial products to market and the costs inherent to them.

This  means that software teams can now build and release financial products  quickly. In addition, without fixed costs to every transaction, they can  experiment with business models not before possible.

Today, that’s resulted in Tokenized Finance products that mimic traditional products with lower minimums and costs. MakerDAO for securities-based loans, Compound for money market just to name a few.

What’s more interesting is what will happen as the ecosystem grows.

Permissionless  innovation with a reduced cost to bring products to market means rapid  experimentation is now possible. This will create financial products not possible or conceived of in traditional finance.

The future is bright.

Wyre Podcast

Chat with team at Wyre about what a brokerage will look like in the future.

Thanks to the team at Wyre for having our me on their podcast last week. We had a great time covering a range of  topics from the state of wallet software, regulation to the future of Fetch and financial services.

You can listen to the podcast  and there is also a transcript of the conversation on the Wyre Blog.

Software is even eating the hardware…

Software is not just eating the world, it will also eat the hardware margins of the leading mobile vendors and level the distribution of mobile industry profits.

Today’s mobile market has clear winners. Samsung makes more profit from Android phones than Google does from all of their operations [Asymco], while Apple earned 57% of global smartphone industry profits in Q1 [Link]. The integrated players, Apple and Samsung, are drowning in the profits from integrated production, efficient supply chains and differentiated, well marketed products.

The software and service players are not monetizing mobile in any comparable way….yet. Google, Amazon (and to a small degree Microsoft) – are playing the role of disruptor. Their strategy resides in subsidizing hardware with services (ads) and content, which will eventually reshape the distribution of wealth in the mobile industry. Two reasons this is working:

  1. Hardware innovation has slowed – The spec war is over. Capacitive touch screens and cheap sensors were the last major improvements. Some are on the horizon (flexible screens), but in general even the less expensive smartphones are capable for most users. Does anybody really know or care how many computing cores their phone has?
  2. Whole product matters – Consumers view the device as a mobile extension of their digital life. So seamless access to the services that support their life (email, maps, search, apps, etc…) are as, if not more, important as any hardware spec.

What’s a mobile goliath like Apple or Samsung to do to keep their monopoly sized profit machine running? For one, continue to invest in R&D to stay in front of the hardware innovation curve and find the next breakthrough. Second, they need to rapidly round out their digital life offerings, getting more users onto their service and content platforms.

They will do everything they can to fill their software, service and content deficiencies to ensure that as hardware margins decrease, they can make it up in service and content margin. Otherwise they will see their products become less attractive and less profitable. How well they do this over the next few years will dictate how much of the industry’s profits they retain from the attack of the disruptors.

[This post also appears as a guest post on the Telefonica blog]

Why do so many mobile apps suck?

If you work at a mid size enterprise and are in charge of rolling out your company’s new mobile app offering, unfortunately your options suck. Your boss or their boss probably just used a beautifully designed consumer app, and they had a vision for something your company could do on these incredible phones to make your customers happier. Now it is your job to make it happen.

This app will be harder for you to build than that whiz bang camera app of the week. You will have to figure out how to:

  • Not only support the devices out there, but budget to support all the new ones coming (new OS versions, as well as new platforms and form factors)
  • Integrate with whatever backend systems hold the data that your app will need
    Make sure the app is secure enough so your IT group doesn’t shoot you

If you don’t happen to work out at one of the few companies that has assembled a strong mobile development team, then these are your options:
Use a Mobile App “Platform”

Whenever there is enterprise grade complexity, there are never a lack of platforms to choose from. I’ve been looking closely at these the last couple of months, and can put most of them into one of two buckets:

  1. MEAPs – Mobile Enterprise App Platforms

What they do -A combination of tools and services a company can use to build an app. They generally offer some guarantee of future proofing the app, promising support for new devices and OS updates. If this seems like a vague description, it is because the products are just that, vague.

How they came to be –  Many of these usually come from companies that have been engaged with companies as professional services vendors, and saw the general trends that I listed above. They also realized that they were building some basic components across all their customers, so the obvious next move is to bring these components under one umbrella, market it as a platform and shift their revenue from hard to scale, chunky, unpredictable services revenue into predictable, scalable licensing revenue.

Why they suck  – While there may actually be some productized code in these platforms, they generally are customized per deployment. To take advantage of the productized parts, the customer can either assemble pre-built components into a mediocre app of some sort, or live through a costly, maybe lengthy customization phase – which they were trying to avoid in the first place by selecting a platform to build their apps.

  1. Visual App Designers

What they do – Enable non-developers to build an app using some set of WYSIWYG tools

How they came to be – If scarcity of app developers is a problem, than let’s make it possible to build apps without them.

Why they suck – These generally involve translating some visual design language to native for all the major mobile platforms at some lowest common denominator. This results in a poorly optimized user experience on every platform. Steve Jobs says it better than I ever could:

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

–Steve Jobs

Build a Team

Good luck here. The scarcity of mobile app devs is well documented (read more here). If you are a qualified mobile app developer right now, your options are endless. You can opt for the cool small company/startup of the day, or any high-profile, brand name company you want – they all need you. Recruiting and retaining a team at a mid size company is going to be painful.
Hire a Vendor

There are any number of companies out there that will build an app for you. From large service providers to 3 man outfits based in a far flung locale. I won’t dig into the pros/cons of this since this option has and will always exist in roughly the same form, everybody differentiating in whatever way they can to maintain some margin in what always becomes a race down to zero margin.

None of these are great options, and it feels very much like companies building web sites in the late 90s. The options aren’t that great, and the results don’t ever wow you, they just kind of work. Just like building for the web did, this will evolve. Talent will become more available, the tools will mature and the platforms will settle down. Along they way though, there is going to be a ton of opportunity for products that can make this process less painful.

How Cornerstone put Android in a tractor

When Onskreen open sourced Cornerstone early in 2012, we had no idea what was going to happen. At the time, Google was using their powerful stick to beat away customers who wanted to include Cornerstone on their devices (read more about this here); and open sourcing the product was the best way of getting the product out to users.

After being open sourced, the first thing we expected to happen, did happen. That is, the mod community took to it and started to make Cornerstone ROMs for some of the most popular devices out on the market.  In fact, when CyanogenMod (the most popular Android ROM) wanted to include Cornerstone in their releases, Google had to publicly declare they would restrict CyanogenMod from including the Play Store if they did this. You can read the thread here. This was exactly what Google was doing to OEMs behind closed doors already, and was the first time I know of that they had to declare it publicly.

But then a funny thing happened. Other companies, releasing Android based non-tablet/phone devices started to adopt Cornerstone also. We saw a few use cases that were really interesting:

  • Qualcomm/Smart TV and St Microelectronics/Set Top Box – Qualcomm with their Android based smart TV platform built to run on their new SnapDragon chip (read more here) and Orly, ST Micro’s Android based set top box both use Cornerstone to provide a richer experience on large TV displays. Integrating video and Android apps to make use of a > 40″ display and lean back living room experience.
  • All-In-One Computer – A can’t-be-named-yet OEM used Cornerstone as the basis for an upcoming AIO computer. The 27″ device would be ridiculous without multi-tasking so users can engage with and monitor various apps at the same time on the huge screen.
  • Tractors – Yep, tractors. They used Cornerstone to upgrade their in machine control system. The built in display is being upgraded from a relic OS to Android so the company can take advantage of modern s/w development practices. However, federal law requires certain information to be displayed at all times. So they are using Cornerstone to enable a mutli-tasked display and split their app development into smaller, functional units rather a monolithic app that was hard to maintain and upgrade.

There were a few larger trends driving adoption:

  • Android as a technology and not ecosystem -Similar to Amazon with the Kindle Fire, these companies are using Android as a basis for technology, and not looking to it as an ecosystem blessed by Google. For them, Android serves as a modern OS with a supported developer environment. Not being concerned with the Google ecosystem, these companies can adopt and modify the OS without concern of the politics around certification.
  • Google TV’s failure – I’m not sure any real consumer has actually ever bought one before. So for the TV products using Android as the OS, they are very much using the OS purely as a technology platform. Once they do that and see the one app at a time UX on a 50″ TV, it begins to look ridiculous and the need for multi-tasking becomes obvious.

It is great to see the product used in ways we never imagined when we built it, and I’m looking forward to seeing these products get to market as well as see how others use Cornerstone in the future.

When open means closed, it gets confusing

Google owns Android, and everybody else is a second class citizen.

This should be obvious, but Google was able to confuse everyone for a number of years by releasing the source code. This offered the veneer of openness while remaining actually closed. At Onskreen, we saw the implications of this the last couple of years and it all played out behind closed doors. However, recently, Google made a very public move by shutting down Acer’s plan to launch a device based on a modified Android stack (read more here.

Certification has some technical requirements, none of which Cornerstone was in violation of. The real problem was that using Cornerstone gave the device manufacturers a differentiated UI. The goal of that was to offer a superior user experience to users, and thus engender loyalty directly to the device manufacturer as opposed to the brand of mobile OS. This may have not been in violation of Google’s technical requirements, however, it did violate Google’s goals. So they essentially banned it.

The act of coercing our common customers (device manufacturers), I don’t actually have an issue with. The problem is the false veneer of opening the code and then basically ensuring that nobody does anything with it that Google does not approve of. It was a great initial marketing tactic by Google that is now running into its limitations and beginning to cause more problems than helping Android.

I should be clear, I think Android is great. I use an Android device and Onskreen does a ton of business around it. It would just be better served with a transparent governance model from Google. The open, but closed approach does nothing but confuse the ecosystem and reinforce that Google’s ‘Don’t be evil’ mantra is outdated in their fight to the death to own mobile.

[Update 1.18.2013] – Samsung has released a version of multi-tasking on their Galaxy devices, and been certified by Google for those devices. Samsung is the major Android distributor (as of mid last year, they sold almost 50% of all Android devices worldwide with no other manufacturer above 10%), so clearly they had the clout to force Google to certify their multi-tasking implementation. It’s unfortunate that the only way that this could happen was with Samsung’s clout, as opposed to being enabled via the Android certification process that is supposed to level the playing field for Android. The implications for this are severe if you are not Samsung:

  • Me-too devices are a guarantee – Differentiating Android in any meaningful way is just not going to happen unless you are Samsung. Some others (LG) have come out with a version of multi-tasking after Samsung, but it is clear that Google had to certify those devices after certifying Samsung’s devices. The problem is that LG and the others are now followers as far as the market is concerned, and have no real means of leading.
  • Stephen Elop looks like a genius – With Nokia surging (at least in stock value), the decision to go with WP and not become another Android clone looks like the right one.

Mobile software is dead…long live mobile software

OK, it isn’t really dead, actually it has never been more alive. The distinction that I am making is regarding software for mobile phones (exploding) and software that runs as a good citizen on those phones (declining).

I’ve been involved in one way or another with software on mobile phones for almost 10 years, and the shift has been incredible. The explosion of the quality and breadth of things I can do  (and actually enjoy doing) from my phone has exploded in the last 4 years. Unfortunately, this has coincided with a decline in the quality of how these apps behave when considering the constraints of the mobile environment they are running within. Sometimes basic good citizen rules are ignored by many apps:

  • Data Compression – the easiest of easy, compress the data you send over the air. It’s amazing how many apps don’t do this.
  • Logical Polling – if you are going to poll for changes and there is nothing new for a long period, back off the polling interval. Rocket science this is not.
  • Battery – I won’t go into detail here but there are a number of things we have done @ Onskreen over the years when writing mobile client software to ensure the battery wasn’t unnecessarily drained.

So, if you want to see the future of what people will be doing on their mobile phones – skip the retreads at Mobile World Congress, and head to sxsw to see what the cool kids are building. Just be sure to get a bigger data plan and bring an extra battery….you’ll need it.

Resist the Urge Facebook

The rumor mill has churned out the possibility of Facebook building their own phone again. I have no idea if this has any truth behind it, but having seen stories like this in the past and having previously watched similar companies fail at this, it seemed useful to go through a few of the reasons why it should be avoided.

DNA

Facebook’s DNA is to solve problems with software and rapid iterations. There is a huge difference between this and distributing hardware. You can argue that corporate DNA evolves, particularly in response to an acute threat. However, to see how difficult this is, let’s look at the experience of some comparable companies:

  • Microsoft has spent roughly the last 10 years and untold amounts of money to get the integrated hardware/software experience and retailing of the Xbox just right. That took incredible commitment, patience and deep pockets from a software company.
  • Google, no doubt driven by some of the same fears Facebook has now,  has rocket ship growth of Android in smartphones. Yet, their attempts to directly retail Nexus devices was a flop. They have revived the program now, but there is no evidence to show it has been a success.
  • Nokia illustrates the reverse DNA mutation is also difficult. Their attempts to create a viable software OS and combine it with their superior hardware failed miserably. Their failure to accept that this was not in their DNA has destroyed a brand that was at one time synonymous with mobile phone excellence.

Distribution

Almost 1 Billion users is incredible, but it doesn’t guarantee successful distribution of a Facebook phone. Where is the Apple-like retail presence? Are Carriers really going to be excited to subsidize a Facebook phone that uses Facebook messaging to further erode their one-time SMS cash cow?

Brand

Facebook brand = Social connectivity. Facebook users are the product and they are conditioned to expect all of Facebook’s magic social goodness for free. This isn’t about whether users will pay $100 vs $300 for a Facebook phone, it is about whether that brand association will mean they want to pay anything at all. Need proof? Just go the Facebook login page to see it in their words – “It’s free and always will be.”

Role of Utilities

Facebook describes itself as a “Social Utility…”, and it is exactly that. While there are no doubt Facebook zealots who will use anything Facebook offers, these are the people who will be using Facebook from whatever phone they already have regardless. The more important segment is those between zealots and non-users who may be swayed to use Facebook rivals. Are there other ways to further engage this segment with Facebook mobile services and still hold true to their strengths as a company?

(There are a host of other issues – thin hardware margins, the importance of App Ecosystems, mobile patent wars, etc…but I’ve gone on too long already.)

If not a phone then what?

The presumed driver of this strategy and fear Facebook has is a valid one. The quote that best sums it up is:

“Mark is worried that if he doesn’t create a mobile phone in the near future that Facebook will simply become an app on other mobile platforms”

While a successful Facebook phone would alleviate this problem, there seem to be alternate strategies which better leverage Facebook’s strengths as a company.

Optimize and create Facebook products for mobile specifically. Their social product innovation is what got them their current dominant position on the web in the first place. Easier said than done of course, but software and product innovation is more up Facebook’s alley than building a phone is.
Other than Samsung and Apple, other OEMs have failed to differentiate their products and are languishing with a bunch of me-too products. If there is a unique need Facebook feels it needs from the hardware, these OEMs would happily provide it.

Onskreen Story

There haven’t been any good write ups of the story behind Onskreen – how and why we started it and the twists and turns along the way – so, it seemed like a fitting topic for the start of this blog.

Warning – this is going to be long. So if you can’t stand to be away from your inbox for the time it will take to read the entire post, here is the take-home message -> User Experience matters.

Pre-Onskreen – State of Things
It is hard to believe in today’s world of billions of app downloads, but in 2003, the problem of the day was how to get people to use their phones for more than just phone calls and sms. The magic elixir was supposed to be a killer application for mobile that everybody would have to use so badly they would ignore the small screen, lack of keyboard, etc…The only problem was nobody knew exactly what this app was supposed to be. So, much to the chagrin of the mobile pundits,  people continued buying phones based on how skinny they were (remember the Motorola RAZR?) or the camera. At the time, trying to accomplish any of the following with your super slim, shiny phone would cause you to either pull your hair out, or throw it against a wall:

  • Open the Browser – Yes, even figuring out how to open the browser on some popular models was a miracle
  • Download an app – Navigating the WAP deck was a nightmare (BTW – if you know what a WAP deck is you have been in the mobile industry too long!)
  • Change the Ringtone – I wish that I was exaggerating, but some phones had menus so long and convoluted on some phones this could be a serious challenge

At the same time, I was coming out of a one year stint working at Motorola after they had purchased 4thpass. At 4thpass, we became successful creating the concept of the Mobile App Store and deploying it with Telecom Operators around the world. We provided the back end infrastructure, wired it up to the network and the Operator had an app store for their users.
So, the industry plodded along making great advances in some areas (awesome camera phones, speedier networks, etc…) and failing miserably at crucial issues (UX specifically).

Launching Onskreen – UX is King
The killer app for mobile is not an app at all – it is an incredible User Experience. This was the key premise for starting Onskreen in 2005, which was a time where that idea was not a very well received world view. Today, it’s obvious of course, just look at Apple’s market cap. Seven years ago it took some convincing that what people wanted to do with their phones was everything, if they could only figure out how to use the damn thing.

The truth was that the Motorola’s and Nokia’s of the world in 2005 were never going to solve the problem of how people interacted with their phones. In addition to being relatively unchallenged to innovate, they were fundamentally not software companies. Their attempts at creating new mobile OS’s or improving their current ones were borderline comical. Their DNA was centered around optimizing radio and hardware and being efficient at global distribution of their products, not making great software.

So, I started Onskreen with the ambition of fixing the mobile UX problem and helping transform mobile phones into the incredibly useful little computers that they are today.

The Journey
Our first product, Fusion, attempted to solve UX problems that would improve user’s experience with their phones while solving business problems for Operators (at that time they were the only real source of distribution so we needed them on board). For users we wanted to help improve:

  • Discovery – No more searching around, information had to be obvious and consistently available.
  • Latency – Info had to be updated in a way that users felt like it was always fresh. No frustrating experience of click and wait.
  • Relevance – Put the power in the hands of the users so that the info they were getting was valuable to them.

Fusion transformed the front screen of the phone from the generic, static wallpaper into a richer experience capable of supporting widgets with info, news…anything the user wanted. I won’t go into detail here, but by doing this we also solved a slew of marketing and service problems for Operators. It was a win for everybody and it worked. We built the product and licensed it to Operators and Device Manufacturers. Things were going well and we were working towards a huge deal with Telefónica. Like much in startups, it was all good, until it wasn’t.

In parallel to Telefónica grinding their enormous gears to make the deployment happen, Nokia was leading the mobile industry with no real competitors. Motorola had faltered and Silicon Valley had not yet risen up to take over the mobile OS to displace them. When the time came for Nokia to include our software on the phones Telefónica purchased from them, they not so politely refused Telefónica’s request, although it was as simple as including an app on the phones. Nokia knew, as we did, that whoever owned the user experience owned the user. They understood that the loyalty of the user would become intertwined with that experience, and they were not about to let Telefónica own a piece of that. The industry as a whole wasn’t challenging Nokia to innovate at any pace but their own, so they felt no pressure to play nicely. [Note: The story of Nokia’s strategy and software failures in the last decade have been written about here and elsewhere. They are a great cautionary tale.]

It was late 2006 and Onskreen was at a crossroads. We had invested a lot to get a product through all the hoops so that a giant customer could deploy it and we could really scale, only to have another industry titan crush it. There was no point investing further on the path we were on. It was time to either cut and run or figure out another approach. Luckily for us and everybody else, Apple was on the verge of announcing the first iPhone. By solving the UX problem from outside the cozy and glacially slow pace of the mobile industry, they forced everybody in the industry to figure out how to improve immediately. What customers currently had to choose from paled in comparison to what Apple was tantalizingly promising. Our current customers and those that were interested but had not yet pulled the trigger started scrambling to figure out how they were going to respond to this threat and who could help them. We had been waving the mobile UX flag for the last 2 years, so our phones started ringing again.

Onskreen was reborn as a professional services organization helping Operators, OEMs and Silicon Vendors to improve the user experience of their products. We were fortunate to be involved with some of the first Android device releases and built a successful portion of our business on the explosion of Android phones and then tablets and TVs. Most recently, our work on transforming Android into a true multi-tasking platform, Cornerstone, was open sourced and is the basis of a number of upcoming Tablet and smart TV implementations.

Current State
Onskreen is a rarity among companies selling to the mobile customers as large as ours. We were bootstrapped and have been profitable for a number of years. It continues as a strong business, profitable and engaged with a number of the interesting shifts in strategy the mobile incumbents make to compete with their new competitors.

This doesn’t mean that all is rosy in the mobile world. There are a number of complex issues that we have had the chance witness first-hand, and that I hope to write more about as this blog goes on.