Google I/O 2019, Some Exciting Bits that Were not Obviously Exciting

Over the last couple of days I’ve been looking at the various product announcements that came out of Google I/O 2019 and there were a couple of themes that got me pretty excited about where Google can go and how that can make pretty a positive impact on millions of people.

Creating Opportunities for People… All People

I loved the Google Lens announcements from Aparna Chennapragada because the application of the technology can make such a huge difference in people’s lives, and not just the people I typically see in wearing fleece vests and sipping cold brew coffee Silicon Valley. What was most compelling to me was the transcribing / Google Translate integration that was demonstrated, especially when combined with the processing being done on device (not cloud), and being accessible to extremely low-end ($35) devices. Visual translation was always a very cool feature and, when I was trying to figure out menus in Paris, I was happy to have the privilege of a high-end phone and data plan. Making this technology widely accessible enables breaking down barriers created by illiteracy, assisting the visually impaired, and helping human interactions in regions with language borders.

Google also announced Live Caption, where pretty much every form of video (including third party apps and live chat) can have real-time subtitles. This is also done on-device, and works offline, so it can be applied to live events, like watching a speaker at a conference. A shoutout to my friend and former colleague KR Liu for her work with Google on this project, that makes the world far more accessible to people with hearing challenges.

Also notable, Google’s Project Euphonia is making speech recognition more accessible to people with impaired speech.

Movement Towards Device vs. Cloud

The “on device” and “offline” features I mentioned (and were part of other announcements like Google Assistant improvements) are important because of the implications they have in making the technology available to everyone, and also because of the personal privacy that capability will enable.

Of course, my data, Google’s access to it, and personal privacy is a much larger, complicated conversation… for now I am going to focus on possibilities, not challenges.

For years there has been a move for all aspects of people’s lives to be captured and collected in the cloud. There are many reasons this may have been necessary, from correlating data to make it useful, raw computer processing power requirements, over-reaching policies, and business models requiring all the things to win. Once in the cloud, personal information can be used for purposes never imagined by the consumer, including detailed profiling, sharing with third parties, accidentally leaking to malicious parties, revealing personal content, and various other exploitations that can negatively impact the consumer.

As the processing stays on your device and does not require transferring data off of your device, it enables products that can still provide incredible benefits while also being respectful of customer privacy. This is exciting as there are product opportunities in areas like personal health (physical and mental) that will likely require deep trust and protection of consumer information to gain wide acceptance and benefit the most people.

Personal Assistant of My Dreams

And something I am more selfishly excited about…

For several years I wished that all of the products in Google would integrate with each other and eliminate almost every manual step I have to organizing my day. I am going to side-step the discussion about how much data a company has about an individual and say that I intentionally choose to trust my information with two companies (Google being one), because of the value I get from them. I use Google to organize most aspects of my life, from email communication to coordinating my kid’s schedules, video conferencing, travel planning, finding my way around anywhere, and almost every form of document. As a result, all the parts of Google know a lot about me. But still, when I send an email to setup a meeting, I usually need to manually add that to my calendar and then I also need to add in the travel details (I frequently take trains instead of driving)… it’s a couple of extra minutes that I could be spending on better things, or just looking at pictures of cats on the Internet.

With the progress of Google Assistant and Google Duplex, I am seeing a path where administrivia is eliminated, where email, text messages, phone calls and video conferencing can also provide inputs that guide this assistant into organizing my life behind the scenes… Action items discussed in a Hangout can automatically result in a summary document, a coordinated follow-up lunch, optimal travel details, and a task list.

There is an obvious contradiction between my excitement for the announcements that emphasize better human outcomes and my “let Google know all the things” excitement over a personal assistant, but again, this is about my personal, intentional choice to share data vs. products that mandate supplying personal data, often far in excess of what is necessary to deliver the product or service.

There were some other “that’s cool” announcements, and I’ll probably be buying a Pixel 3a, which seems like a great deal for the feature set, but overall I’m more excited about the direction than the specific products showcased.

Empathy Driven Metrics

Social networks, online communities, and social media are services we use because of the promise they offer to strengthen relationships with other humans. However, these services frequently fall short of that promise, sometimes harming the relationships they were meant to support. In many companies, delivering a negative customer outcome results in business failure, but for many social companies, negative customer outcomes are producing positive business results for product teams because the business success metrics are not aligned with customer success.

Or, maybe the metrics are perfectly aligned with customer success, but unfortunately, end users are not the customer. The argument, “If you’re not paying for it, you’re not the customer; you’re the product being sold” explains the poor outcomes for end users resulting in positive business results from customers (typically advertisers). I believe a great number of employees in these companies do think of you, the end user, as their customer, but the systems in place to validate a successful outcome fail to reinforce the importance of the customer’s needs outside of the business objectives.

It is common to hear social companies talk about being “customer obsessed”, and I have met plenty of Product Managers that genuinely care about the end user as their customer. But how many companies translate this obsession into their performance metrics to deliver an outcome that is truly successful for the customer? How often do you see companies reporting objectively measured progress towards delivering customer well-being? Engagement metrics like daily active users, ads watched, shares, retention, number of posts, and time spent in app are all very common… but without consideration of customer well-being, what do engagement-driven metrics deliver in a social product that if fundamentally about human relationships?

Show me the incentive and I will show you the outcome.

Charlie Munger

Worse Human Interactions

Many of the negative customer outcomes so many people experience correlate with a positive result for the companies creating the product. Disagreement, anger, and outrage all drive activity and engagement… since last week your posts increased 23% and your time spent in app is up by 8%, but you’ve also unfriended uncle Ned because he keeps posting fake political stories about your favorite candidate, and you disinvited your extended family from Thanksgiving.

But even positive content combined with effectively scorekeeping popularity through shares and likes, can lead to worse outcomes and lower self esteem as people tend to post their best moments, creating the perception that everybody else’s life is amazing, while you do laundry, eat leftovers, and watch Netflix alone.

Worse Decisions

Humans have many cognitive biases, error patterns in the way we think, leading to irrational decisions. Online we are regularly influenced by an availability cascade, overwhelming our critical thinking by making obscure or even crazy ideas seem rational as they are repeated and seemingly reinforced as widely accepted when we witness more and more people supporting the idea.

You watch one video because you are amused that a guy thinks the Earth is flat, and then your recommended feed is showing more support for his argument. Based on what is being presented to you, there seems to be a lot of support for this flat Earth idea. What seems like an obscure initial video you watched thinking it’s ridiculous that this guy thinks the Earth is flat has led you down the rabbit-hole of conspiracy videos, and you’re starting to think there might really be two sides to consider in this whole chemtrail thing, but good news, you’re watching 13 more videos and 72 more minutes than you did last week!

The poor outcomes don’t stop with the individual, they are reflected in negative outcomes for society overall. Misinformation about vaccines continues leading to a reduction in vaccination rates and new outbreaks of mostly-eradicated diseases. Unfortunately, sensationalized false claims can go viral quickly, while corrections get a small percentage of the original article, so the fake information gains a substantially larger public mindshare.

Balancing Business Metrics with Customer Empathy

For many businesses, validating successful customer outcomes is relatively straightforward… reducing their cost per widget, increasing their leads, reducing time spent in a business process are all objective benefits. But for products that are fundamentally about human relationships, a successful customer outcome is more subjective, but by most definitions of healthy relationships, is not based on dependency, quantity of consumption, or other common assessments of engagement.

What metrics might a company consider if customer well-being were a consideration in the successful customer outcome? Factors like happiness, growth, confidence, personal enrichment, support, safety, and fulfillment seem like good candidates. In customer interviews, this would also mean understanding the real answer to the question, “How do you feel after using our product?

Customer Well-Being is Measurable

The subjective nature of metrics like “customer happiness” presents a challenge. However, technology is reaching a point where it is becoming possible, at scale, to more objectively answer the question, “how does my customer feel?”. Sentiment analysis of text has matured considerably, and can be used understand customer. Similarly, emotion recognition of voice and visuals can provide insights into the immediate reactions. Technologies like these are being applied to problems predicting depression from written text and speech. Wearables with biometrics are becoming increasingly common and also provide an opportunity to assess the physical impact from online interactions.

Further reinforcing that measuring customer well-being is possible, in 2018 the New York Times piloted ad placements based on the emotions certain articles evoke. However, like many current applications of sentiment analysis, this use case emphasized the value created for the advertiser, focusing on targeting the customer with premium-priced ads when the customer is in an emotional state that is optimal for the advertiser. The examples cited targeted upbeat, inspired customers, but it is easy to imagine the same technology could be used to target customers that are upset, reactionary, and likely more susceptible to radical suggestions. In other words, perfect for divisive political targeting.

An encouraging example of prioritizing customer well-being comes from Dan Seider at Stigma, using input from webcam images, regularly processed by artificial intelligence to understand online consumption impact on happiness. If this type of customer data can be secured (likely requiring it to never leave the customer’s device), this technology could lead to solutions that help people understand how their online habits are benefitting or harming their well-being. While empowering individuals with these sort of tools is great, it represents third-parties trying to provide protections from social products, rather than social companies considering customer well-being as part of their product success.

Codify Better Social Outcomes

From a business results perspective, there is little need for the current social giants to change. A couple of times a years we see news surface where customers are outraged by being exploited, manipulated, or endangered, a CEO repeats a statement about fixing things, and the market value of these companies generally continues to increase in spite of these problems.

I believe many CEOs are sincere in their desire to eliminate the social problems manifested in their products (I mean, who wouldn’t want that to go away), but I don’t see this desire supported with how the company objectively assesses success, and I am skeptical we will actually see improvements until customer well being metrics are considered alongside of engagement metrics. A commitment to results requires measurement, and cultural integration into what is considered success, from product performance to employee incentives. If you don’t track it, you probably don’t really care about it.

For earlier stage social products and companies with a commitment to better customer outcomes, it is easy to assume that strong product leadership holding this commitment is enough to stay on that path. Codifying what a better social outcome means will help make the path clear when there are inevitable product tradeoffs between short-term gains vs. long-term enduring value for customers. As new employees join the company they will see values like “we love our customers” not just as words painted on the wall, but as a requirement for success.

Does your product team include customer well-being as a desired outcome? I’d like to hear more, especially how success is measured – please leave a reply below!

Credits
Kids in Field on Laptops image by Unknown, via Pxhere
Blockhead Toy image by Unknown, via Pxhere
Girl on Playground image by Unknown, via Pxhere
Computer Draining Man image by Unknown, via Pxhere
Excited Kids on Laptop image by Unknown, via Pxhere

Make an Antique Garage Door Opener Internet Capable

I have an early 1990’s garage door opener that does all of the things you need a garage door opener to do (it… opens the garage door). However, the remotes are the size of cinder blocks and I never have one with me when I need it, so I decided to find a way to use my phone instead. This project is part of a long history of unnecessarily connecting items in my house to the Internet.

Requirements

  • A janky garage door opener, ideally the kind with wired switches attached to your garage wall
  • Some form of a server… nothing powerful. A $50 Raspberry Pi is about 50x more powerful than you need
  • A relay controller. For this project I happened to have a CanaKit UK1104 USB relay controller laying around
  • Some wire to connect from your server to the garage door opener, CAT5 is overkill and works great
  • A patient / forgiving significant other

Installation

  1. Wait for your significant other to leave the house for at least 90 minutes.
  2. Connect the relay controller to your server
  3. Grab my Garage-Door-Controller code from Github and copy it into the html directory of your server. In includes PHP and Perl scripts, the best programming languages 😜
  4. Install the Perl package Device::SerialPort. On Ubuntu / Debian: sudo apt-get install libdevice-serialport-perl
  5. Make sure the script can access the serial device… On Linux, you can add the web user www-data to the dialout group, or if you want a less secure option, use visudo and add this line: www-data ALL=(root) NOPASSWD: /var/www/html/garage/garageinterface (use the path for your server)
  6. Make sure the file garageinterface is executable, chmod a+x garageinterface
  7. Run a wire from the relay 1 on the controller to the same terminals on your garage door that the buttons on your wall are connected to (you can leave those wires in place, too… no need to make the buttons not work). On your relay, the wires should connect to “COM” and “NO” (common and normally open)
CanaKit UK1104 wired to an antique garage door opener

Opening Your Garage Door

When connected to the same network as your server, simply point your web browser to /garage and the magic begins. If you are using your phone browser, the “Add to Home Screen” option creates an icon on your phone and eliminates the menu bar, making a clean interface.

The garage door interface
It’s… pretty simple

The scripts provide a simple web interface that is responsive (it automatically adjusts to the screen where it is being rendered), so it works well on a phone web browser or whatever other web-capable device you want to use to open your garage..

There is a single “Garage Door Button” and pressing it… that’s right… it does the same thing as if you pressed the button connected to your garage door opener.

Of course you can connect the relay to whatever else you want to control… lights, refrigerators, bug zappers, sprinklers, your toaster.

Security Concerns

The HoT Garage “app” on my home screen.

If you are silly enough to follow in my path, I strongly suggest you only run this on a local home network (e.g. you must be connected to your home wifi) if you are using it on something like a garage door, partially because I didn’t consider security at all when writing the scripts, and more importantly, why in the hell would you want to open your garage door when you are not near your garage door? I know it sounds cool, but… no.

Happy Tinkering!

If you have a habit of wiring things up to teh Interwebs, I’d love to hear about your experiences… especially the ones that didn’t work out exactly as planned. Please leave a reply, below!

Hinder, Don’t Halt: Griefing Content Thieves for Fun and Profit

The art of deterring content theft is an ongoing game of cat and mouse – generally any barrier you create to prevent theft is temporary, as thieves continue to find new ways to steal the content, so long as the value of the content exceeds the effort necessary to steal it. For this reason, it can often be more effective to hinder thieves instead of trying to stop them.

I encounter this “hinder don’t halt” pattern with others that run large services, and you can see this reflected in solutions like shadow banning. One of the most common themes I hear is the satisfaction that comes from solutions that cause frustration for bad actors, so I’m sharing one from my personal experiences…

At IMVU, customers called Creators make content that they sell to other IMVU customers. The content they create is 3D items like avatar clothing, items to decorate an environment, and ways to customize an avatar. This content creates real value for other IMVU customers, who spend real money to purchase it from the catalog of over 10 million items. While many Creators create content just for the enjoyment of creating, some do it as a business, with a few making over $100K US annually. Whether creating for pleasure or business, all Creators hated having their work stolen. And, since there is real money from the sales of content, there is real incentive for thieves to try to steal it.

At one point we discovered a site that was selling a service that would allow people to steal Creator content without paying for it. It was pretty easy to detect the service and the initial response was blocking them, which immediately broke their service completely and, not surprisingly, made the thieves quickly respond by finding a new way around the block. The block lasted less than a day and the thieves were back in business.

The next response was more fun… rather than blocking the thieves, we made their service not work… sometimes… and inconsistently. Code was added to detect thieves accessing content and randomly some content being accessed would be mildly corrupted. The corruption could be configured to occur at certain rates, on certain items, at certain times of day, and be disabled based on what appeared to be testing for the corruption. As a result, customers of the thieves started getting inconsistent results, that would sometimes lead to content failing to load and even crashes. If you are an engineer reading this, you understand why this is a nightmare scenario to debug and fix… customers are reporting different failure cases with no consistent way of reproducing the problem to understand the cause. And, since your code is working fine, the bug isn’t going to be found… you eventually have to discover that you are being served different content than is being served to legitimate customers.

The result of hindering was much more effective than blocking… it took many weeks for the thieves to understand what was happening and, during this time, we could see them getting bashed by the people that paid them because the stolen content was ruining their experience. By the time the thieves had found another solution, they had such a bad reputation that people were less willing to give them money.

If you have dealt with content thieves I would be interested in hearing your stories, successful or not. Please leave a reply, below!

Credits
Cat and mouse chase image by Jeroen Moes
Dungeons & Dragons dice by Lydia

Rewards from Talking to Customers

Most people that build products or run companies have heard the mantra, “get out of the building – talk to customers.” It is easy to assume that talking to customers is only about building a better product. Talking to customers will help you build a better product, but more importantly, you may be rewarded by learning how your work changes people’s lives!

I recently had an experience that was so delightful I had to share it with my former employees, and they decided to share it with their millions of customers. Below is the excerpt from the IMVU blog:

You may remember a very familiar face in the photo featured in this story.  Brett Durrett is and always will be a friend of IMVU, even after his 11 years on staff and nearly 5 years as our CEO. Beyond his professional titles, or even his leadership as CEO, Brett was an active user that frequently went into chatrooms to join the conversation, answer questions, solve issues, or simply say hello. On Fridays at the HQ office, it was common to see Brett speaking from a microphone about the week’s accomplishments, and always finishing with words of inspiration, a story of encouragement, or a new product to be excited about.  Even if we didn’t hear your stories, Brett always told us your stories so that we could remember why we work at IMVU: we are here to spread the power of friendship, to help people find friends, to encourage them to express themselves, and to find an outlet for creative expression.Recently, our current Chief Operating Officer Kevin Henshaw, forwarded an email he received from Brett to the entire company about how IMVU continues to work its magic on and off our product. 

Brett’s email read like this:

On Monday I was wandering around New Orleans wearing my IMVU hoodie, as I am one to do. I went into a coffee shop and the woman at the counter asked me how I got my hoodie, to which I replied, “I used to work for IMVU”. Her eyes lit up as she proceeded to tell me how much IMVU meant to her as she was growing up.

Bea told me she used IMVU because it allowed her to connect with people without any stereotypes about who she was – she got to decide how she wanted to be seen. She also loved that it didn’t cost much to experience a fantasy lifestyle. She had a lot of friends on IMVU that felt the same. She really gushed about how important IMVU had been in her life. Her excitement went on for minutes. My traveling companion was taken aback, as I seemed to have rock star status. It was a chilly day in NOLA, but I gave Bea my IMVU hoodie (she had made me feel so warm inside that I really didn’t need it).

If you’ve talked to enough IMVU customers you know that Bea’s story isn’t unique… IMVU has helped people find their life partners, best friends, and caring families.

I thought I would use my chance encounter as an excuse to reach out to IMVU employees, say “hello”, and remind them that there are a lot of silly things than can happen on IMVU, but don’t lose sight of the really meaningful things as well! Bea’s story is a testament to what this is really about – helping people find new friends and creating something meaningful to benefit their lives. On behalf of Bea, myself, and millions of customers, keep up the great work!

Do you have a delightful customer story? I’d love to hear about it… please leave a reply!

Scaling Continuous Delivery: Happiness as a Metric

A few days ago Jeff Atwood (Coding Horror) suggested a good measure of a tech company’s health is the time it takes to have a simple change become available to customers:

And while there are numerous metrics that determine the health of a tech company (see Jez Humble’s book, Accelerate, for an amazingly comprehensive overview), Continuous Delivery strongly correlates to successful outcomes.

I support Jeff’s assertion – I witnessed the value created by Continuous Delivery at IMVU, where we pioneered some of the crazy processes that would be followed by more sane practitioners. From day one, IMVU placed value on the speed of product iteration and “designed” build systems accordingly. In 2006, development was done in Windows using Reactor Server to provide the LAMP-ish stack, and the deploy process looked something like this:

 svn-server$ rcp website/* production:/var/www/

If you’re wondering why I omitted the test framework, I didn’t. Code went from a local Windows sandbox environment, to source control, to live on a Linux environment running a version of PHP different than the local sandbox. Fun! While there were numerous problems with this system, iteration velocity was amazing (those 1 word copy changes could ship in less than 5 minutes, and so could full features). This development velocity was a key component enabling IMVU to build a large, successful business in a space where the failed companies outnumber survivors 50 to 1.

And to be clear, time to get a change live to customers doesn’t in itself indicate healthy tech, but a lot of tech health comes from the corresponding systems necessary to make rapid deployment work.

Fast forward a few years to 2008 and I transition from leading the operations team to leading the engineering organization, where the build and deploy systems had matured, with reasonable test coverage, and automated deployment, with automated rollbacks when something unfortunate made it into production. It was pretty cool, even though publicly the process was mostly received with the sentiment, “that will never work , and certainly won’t scale”.

Scaling Problems

One of my first challenges as the new engineering leader was a team unhappy about their ability to get work done because it was taking hours for a commit to become live to customers. It’s astonishing when you think about it – every engineer in the company had come from companies where the commit to live process was typically measured in months, but once they experienced the value of Continuous Delivery, anything more than minutes seemed unbearable.

Digging into the problem, I came to understand that the problem was not slow builds (although that was part of it), the most significant issues were caused from the shared responsibility for build systems, combined with the desire to deliver features to customers, created a tragedy of the commons. When an engineer had a failure in the build system, the optimal solution for that engineer was to fix the problem in place, blocking the build system for anybody else in the queue, which meant the number of commits in the next build increased, which meant the chance of a failure in the that build increased, ad infinitum. The result was pushing to production could be blocked for hours, sometimes most of the work day.

Solving for Happiness

I thought the best solution was to formalize a project, have a clear success outcome, and have a single person with the responsibility for (and therefore authority over) the build / deploy systems. The first problem was determining a clear success criteria… anything time metrics I chose would be somewhat arbitrary, so instead I chose engineering happiness as the success criteria, or more specifically, pushing to production was no longer causing unhappiness. While I generally hate subjective success criteria, there were ways to assess progress through 1:1 conversations and Likert scale surveys. We also had great (highly objective) data around commit to deploy times, so we could see the correlation to the more subjective happiness index.

There was some pretty straightforward work to improve the actual test and deploy speeds, including simple things like adding more hardware and the slightly less simple sorting tests to run by speed (a surprisingly large performance gain), and fixing the slowest of the tests. But some of the most important gains came from the human parts of the deployment system… engineers were required to immediately revert code and fix the issue in their sandbox rather than blocking the build system. This was not a popular policy change as immediately engineers experienced the direct impact from a failed commit, but didn’t immediately see any gains to the overall system.  But after a few weeks the improvements were clear in the average commit to deploy time. And giving credit where it is due, Eric Prestemon was the “Buildbot Sheriff” that identified so many of the opportunities for improvement and delivered the results… many people helped, but Eric had the burden of hearing a lot of critical feedback about unpopular policy changes (eventually outweighed by the praise for the results he produced).

Eventually the build system frustration ceased being a common topic in 1:1 meetings, and it faded away as a meaningful problem in engineering surveys. 12 minutes. When the commit to live time is 12 minutes, this system is operating well. That became the new value for alerting – under 12 minutes, all is good, after that we need to actively drive improvements. In practice, deploy time was usually around 11 minutes, 8 for parallel test builds/runs and 3 minutes for rollout checks (thanks for the reminder, @jwatte).

Diminishing Returns

I have been asked why we didn’t try to make the build and deploy systems as fast as possible… why not 2 minutes? We constantly worked on optimizing these systems, adding separate hypothesis builds, automatically isolating build servers to allow diagnosing and fixing without blocking, etc. And sometimes deployment would take less than 9 minutes.

However, much like the difference between 99.99% and 99.999% uptime for a service, the difference to the customer can be negligible while the resources necessary to deliver that improvement can be extraordinary. When business requirements are being met and engineering is happy with deploy times, the resources necessary to dramatically improve were better spent delivering value to customers.

Key Takeaways

  1. Working in a (well functioning) Continuous Delivery environment is empowering, naturally encourages other strong technical practices, and is hard to retreat from once experienced.
  2. Certain problems fall into what I call the “roommates and dishes” category, where “it’s everybody’s responsibility” sounds good, but in practice actually means “it’s nobody’s responsibility”. In these cases it is better to find a results-driven person and ensure they have responsibility and corresponding authority.
  3. Hire Eric Prestemon or somebody like him.

 

Have you worked in a Continuous Delivery environment and experienced non-obvious scaling challenges? I’d like to hear about your experience – please leave a comment!

Q&A on Digital Transformation

In August I presented The Challenges of Executing Lean Startup at Scale, generously hosted by Rangle.io in Toronto, Canada. Rangle is the premier digital transformation consultancy, founded on Lean Startup principles and achieving impressive growth – a really great success story. I spent some time with Nick Van Weerdenburg, Rangle’s CEO, discussing Digital Transformation.

Some of the topics covered in the conversation include:

  • Solving customer problems is more important than rigorously following a process
  • The challenges of being on an agile team while working with or being part of a non-agile organization
  • Successful agile transformation requiring a culture change before a toolset change… most organizations get this backwards
  • How to choose metrics that are meaningful to your business

I hope you enjoy the video:

If you watch the video I would love your feedback! Please leave a comment below telling me what you think I got it right and what you think sounds crazy. 

 

Exposing Your Private Data – It’s Not (Just) Them, It’s You

This week the Wall Street Journal published a story about third-party Google App Developers being able to read your Gmail, which was followed by many other outlets trying to sensationalize the news. However, a huge source of the exposing personal information problem isn’t big companies providing access to customer data, the problem is customers unwittingly (or uncaringly) granting permission for their data to be accessed. And while many people are skeptical about companies like Google and Facebook handling their data, the far bigger risk is users constantly exposing their private data to relatively unknown companies in exchange for low-value benefits.

Overreaching Account Access

Many sites and applications allow you to sign-on through an account on Facebook, Google and other services. This process is known as single sign-on (SSO), and is convenient and generally secure, especially if you utilize improved security measures like two-factor authentication. However, some applications ask for more access than is necessary, and the user willingly exposes a lot of private data to a third party that they don’t really know.

This Sample Application owns you and all of your data… forever

The list of permissions presented when you first grant access can enable a third party perpetual access to your information, usually long after you forgot you granted permission.

If you are simply trying to login to a new  application using SSO, there should be very little reason to grant any special permissions. Applications that request access to private data like email, contacts, messages, or calendars will have full access to your personal data. If an application doesn’t manage your private data, it should not need access. To protect your personal data, you should only provide the absolute minimum level of access necessary and avoid applications that request more that what they need.

Untrustworthy Third Parties

Some applications legitimately need elevated permissions to provide the service they offer, like inbox management, automatic scheduling, or even shopping deal comparisons. Many of these apps only access your data in the way necessary to provide the service, but there are many that take full advantage of access to your data and leverage your data for their benefit. According to articles on CNET and the Wall Street JournalReturnPath scanned the inboxes of 2 million people to collect marketing data after they’d signed up for one of the free apps produced by its partners, and the company’s employees read around 8,000 uncensored emails.

Even if you trust the intentions of the company producing the application, security is a really hard challenge and even the best companies fail at it… if you are providing access to an unknown startup, you are putting an exceptional amount of trust in believing they have the resources to ensure proper security measures. Of course, when a company is acquired (or its assets are sold), the access to your private data is passed along to the purchaser, whoever that might be.

When considering trading access to your private data in exchange for an application, ask what you are really getting for the risk. If somebody came up to you on the street and offered you some coupons in exchange for letting them read all of your email (forever), would you make that deal?

It’s Your Browser, Too

In addition to granting companies access directly, web browser extensions can expose data from every website you visit. These Extensions in Chrome, and Add-Ons, Extensions, and Plugins in Firefox, provide enhanced functionality from password management to page translation, ad blocking, and simple video downloads. To provide these services, many extensions get access to everything you do in the browser. For example, a news feed reader has permission to “Read and change all your data on the websites you visit” – this means every page visited and all content on that page is accessible by the news reader extension… your web mail, your Facebook messages, your dating sites, medical issues you research… all available to some company that organizes news headlines for you.

As browser extensions potentially grant access to every account, extra care should be taken to ensure trust for the company and permissions before installing.

Clean it Up and Lock it Down!

Until we make progress on time travel, there isn’t a way for an individual to guarantee deletion of data leaked from previously granted access. There are a few steps to greatly reduce your risk going forward…

Eliminate access to every app you don’t use

Most people simply stop using an app and forget about the access they granted, which usually continues in perpetuity. Regularly review the permissions you have granted – you will almost  certainly find some surprises. Facebook has settings for Apps and Websites, Google has a great Security Checkup, and other SSO services usually have a way of reviewing apps with access to your data. Only allow access to apps you are regularly use, disable those you don’t, and review the permissions to ensure they match the access needed.

And do the same for browser extensions! If there are extensions you use infrequently, most browsers have the option to enable / disable instead of having to delete the extension, so you can easily grant access only when necessary.

Trust Before You Install

Installing applications and linked account creation on websites is simpler than ever.  The downside to this ease of access is users typically spending little time scrutinizing the application. If you are giving access to your private data, spend the time to understand who is getting access, and how they will use your data. A simple web search for the application and “security” or “trust” can reveal what others experienced. If the company doesn’t have a website with the ability to contact them, and a published policy about handling your private data, there is a good chance securing your private data isn’t a real concern for them, and it should be for you!

 

Did you actually check to see who you are sharing your private data with? If so, what is the craziest thing you found? Please share by leaving a reply, below!

When Customers Benefit From Decisions They Hate

I’ve been looking at a lot of products recently, mostly for very early stage companies, where one typically builds a successful product by addressing a customer’s needs, and the customer is delighted. But some product decisions, while not well received by customers (or sometimes hated), end up being better for the customer in the long term.  As an example, with major version updates, customers can immediately hate re-learning a product they already knew how to use, even though the changes may result in a better experience and more customers.

A few years ago I was in the position where it was necessary to make such a product decision… I knew would be hated by my customers, it was unlikely the benefit could be communicated to them, and if the decision was wrong, it would be a disaster that could result in 100 people losing their jobs.

It was a change to the experience that powered 90% of IMVU’s revenue.

What is this IMVU Thing?

IMVU creates social products, connecting people using highly-expressive, animated avatars. A huge part of the value proposition is creativity and self expression, a lot of which comes from the customer’s choice of avatars and outfits. People are usually surprised to learn that the business generates well over $50 million annually. IMVU’s business model is based around monetizing that value proposition, as customers purchase avatar outfits and other customizations. However, IMVU doesn’t create this content, it is built by a subset of customers (“Creators”) for sale to other customers – IMVU provides the marketplace and facilitates the transactions. IMVU was the only entity that could create new tokens for the marketplace, so almost all of IMVU’s revenue was from customers purchasing tokens to buy virtual goods. This creates a true two-sided market, and one of the biggest challenges is balancing the needs of both sides of the market. Never was balancing these markets so risky as the decision to take control of the way Creators earned real-world currency through sales of their products.

But First, A Little History…

Today the idea of selling virtual goods for real money is common place, as is people getting paid for creating user generated content…. examples include YouTube, Roblox, and Twitch. When IMVU was pioneering this model, there were few examples, and a lot of uncertainty around the concept of virtual goods being converted to real currency, in particular if this process would classify the company as a bank, with all of the associated banking regulations. IMVU avoided this risk by not handling any conversion of tokens to real currency, and instead allowing third parties to engage in transactions independently.

Very quickly “Resellers” popped-up, offering customers tokens for prices below what IMVU charged, and frequently purchasing tokens, enabling successful Creators to obtain real currency (IMVU took a percentage of every transaction, so the overall supply of tokens always decreased and helped keep the economy strong). This structure created a robust marketplace, where customers loved a huge catalog of items, Creators benefitted from their success, and Resellers benefitted from arbitrage.

When there is a benefit to exploiting a system, people will try to exploit the system. Since the benefit in this system was real money, it didn’t take long for bad actors to surface. IMVU customers were being harmed by bad Resellers that would take their money and not provide tokens, or steal their accounts (and tokens). As a result, we locked-down the Reseller program to less than 20 trusted people and had requirements for them to maintain good practices to remain in the program. And things were good…

The World Changes

Fast forward to 2015 and the world has changed… selling virtual goods and making money from user-generated content are well established practices. And, perhaps related to these practices being more mainstream, financial institutions have established best practices and requirements for these types of businesses. Mobile apps were also well established, which included customer expectations for purchasing in-app content, and app store guidelines for selling virtual goods. These developments, along with recognizing opportunities to provide more purchasing reliability to customers, drove IMVU to restructure the fundamentals of the Reseller program.

The decision to go through this restructuring was highly disruptive to customers, generally unpleasant for all involved, and absolutely the right thing for both customers and the company.

The Heart Transplant

The fundamental change was eliminating Resellers altogether, with IMVU providing royalty payments directly to Creators for the sale of their virtual goods. The process of paying content creators directly is pretty straightforward if it is your starting point, but transitioning to it is painful.

The immediate pain comes from managing communication with a large, passionate community that benefits from the established system, doesn’t necessarily see the need for change, and doesn’t (and can’t) have the breadth of information necessary to understand why changes are necessary (and ultimately, beneficial). IMVU’s Community Manager made heroic efforts and did a great job with communication, but there were still massive forum threads, petitions, and doomsayers.

The next challenge is trying to do the best thing possible for the Resellers, knowing that ultimately the result is going to be eliminating their business, so all you can hope for is making the best of a crappy situation. At this point Resellers were a small oligopoly with strongly protected positions, giving them a huge advantage in both purchasing tokens from Creators and selling to customers, and many had many months of token supply in inventory. Making things even more complicated, many Creators were also uncertain about their future ability to sell tokens, and wanted a way to cash out.

The solution was to announce to the IMVU community a timeframe for the wind-down of the Reseller program, allowing Resellers a small window to purchase tokens from Creators, and a larger window to deplete their inventories. A few Resellers dumped their tokens immediately at fire sale prices, but the more savvy Resellers paced their sales, recognizing that prices would increase as supplies dwindled. A few Resellers maximized the opportunity to buy tokens from Creators at next-to-nothing prices and benefit by selling them an close-to-peak prices a few weeks later. Ultimately Resellers were able to deplete their inventories before the program end. During the two month transition, IMVU resisted discounting its own token sales as to not compete with Resellers – this choice, combined with the tokens flooding the market, had a very real impact on revenue, both in the immediate loss of token sales and in the months following, while many customers had stockpiled a large supply of discounted tokens and didn’t need to purchase from the company.

The remaining transitional work was relatively straightforward (I’d write, “simple”, but I saw several teams of people work their butts off to get everything in place and working in time). Creators needed to provide necessary documentation so they could receive payment, and IMVU needed the accounting systems and people to facilitate payments.

But it wasn’t smooth sailing yet… While IMVU was very good about tracking Reseller token supply as part of monitoring the economy, unknown was the fact that Creators had a pent-up demand to sell their tokens, and much of this demand was completely unmet by the oligopoly of Resellers. As a result, request for royalty payments were much higher than initially expected. The new process would lead to a better result for a larger number of customers, as Creators would reliably be able to receive royalties. However, this immediately meant substantially higher expenses for the company, which was already feeling the impact of lower revenue from the Reseller cash-out. No amount of spreadsheet magic could make the business results look good.

A Quick Note on Leading Through Uncertainty

I was CEO of IMVU during this transition, and I distinctly remember this period as one where I felt I may have made a catastrophic decision. Most bad decisions can be corrected if you’re responsive, and it is usually better to take action and correct if necessary vs. stagnate from analysis paralysis. However, given that the token economy was the business, getting this transition wrong was an existential problem for the company. Over a hundred employees could lose their jobs, and millions of customers could lose a product where they connect with friends.

I knew the potential impact before making the decision, and exercised a lot of diligence researching the economy and token ecosystem (to be more accurate, I had an amazing COO that did the heavy lifting and we were aligned on our understanding). There were few decisions I made where I felt as confident in the ultimate result it would produce, but the timing, and seeing the painful business results each week certainly tested my confidence internally and I would review my assumptions to see where I could have gotten it wrong. Externally I remained more confident, reassuring employees and board we would see an inflection point… soon… it’s coming… hang in there.

I’ve heard other CEOs share stories with a similar pattern… the role requires a balance of internal self-questioning while portraying confidence externally, and the CEO rarely has the ability to share that internal conflict with others.

Results!

In the third month following the changes, IMVU hit the inflection point – the transitional business pain stabilized and started producing positive results. Taking full control of the Creator and Reseller aspects of the economy meant customers could have a reliable experience, from purchasing tokens to receiving royalties for their content. As part of the better-regulated process, there were other bad actors, scams, and negative customer experiences that were eliminated. And since there were less variables in token supply and pricing, it was much easier to maintain stability in the value of the token, a huge win for Creators, the business, and customers that ultimately benefit from a vibrant Creator marketplace.

The change to a more tightly-controlled token economy, combined with other big initiatives that were engaging new customers, resulted in a significant wave of growth and record results for IMVU’s business.

Key Takeaways

  • Talking to customers is critically important! Deeply understand the core of their objectives and pain points, and make sure product changes solve for the customer’s needs.
  • Be mindful that customers won’t have the breadth or depth of information necessary to recognize the real benefit of some product decisions. Sometimes what seems to be an immediately unpopular product decision is necessary to deliver a better customer experience over the long-term.
  • Spend the time to get information necessary for confidence in decisions that can have significant impact, but also be humble, open to recognizing a mistake, and ready to adjust if the results aren’t there.
  • With a large enough customer base it becomes impossible to solve for everybody, as occasionally their needs will conflict. Be intentional in product decisions that make these tradeoffs, solving for the best long-term customer experience for the customers your business needs.
  • Unsupportive customers should be an exception… most of the time your decisions should delight your customers.

 

Do you have examples of product changes customers hated but ultimately produced a better experience for them? If so, I want to hear about them! Please leave a reply, below.

Know Thyself – Startup or Small Business?

There are plenty of good businesses that fail because they are convinced they must be great businesses.

When an entrepreneur asks me for advice for their company, the two most common questions I end up asking are, “what do you want to get out of this?”, and some variation of “do you really want to run a Startup, or would you be happier running a Small Business?” It’s not uncommon for people to make the mistake of thinking these types of companies are basically the same.

What’s the Difference and Why Does it Matter?

When you look at all of the new companies being created, the majority of these are Small Businesses. There are a few reasons for starting these, from following your passion, to having a reliable income, to perhaps creating a family business that will provide work for future generations. These companies are generally funded with family savings, small business loans, or personal loans. In almost all cases, the goal of these businesses is to be cash-flow positive and, if there is company growth, it is usually constrained by actual cash coming into the company, not spending ahead of revenue. As such, a Small Business will have revenue very early after starting, quickly as months or weeks. Owners are typically rewarded by the longevity of the company, a share of the profits, and sometimes a sale of the company.

While you couldn’t tell from a survey of Silicon Valley, but only a very small percentage of new companies are Startups. These are companies that have a vision to discover some radical innovation, in a product, a process, or a service, that has the ability to win a huge market. Since this is an exercise in discovery, the path of a Startup is one of uncertainty and high risk, with 9 out of 10 of these companies failing. The uncertainly means Startups need risk capital (usually multiple infusions) and can take years before they have any revenue. The most common source of funding for these companies is Venture Capital. Proving a repeatable business model and massively scaling business is the goal of Startups. Owners (shareholders) are rewarded by a liquidity event where stock in the company is converted to cash, typically through an acquisition or by having an IPO, and trading stock on the public markets.

The differing goals, and the financing dynamics mean that Startups and Small Businesses operate almost opposite of each other. With cash being a critical resource in a Small Business, business decisions are typically risk adverse. In most cases the better decision will be one that keeps the business at break even rather than risk negative cash flow, even if that decision has a small chance of a huge positive change.

In contrast, since 9 out of 10 Startups fail, that last 1 has to not only deliver economic wins for itself, it has to carry the weight of the 9 others that didn’t (since investors actually want better than market returns over the several-year life of the fund, the real increase in value for a win needs to be closer to 30x). What kind of decisions lead to a 30x return on investment? Not the conservative, sane ones you want protecting the existing value of a Small Business. Investors need big returns and that means they need the company to take big risks.

Crossovers are Rare

Occasionally you will hear about company being run as a Small Business that is super successful has the outsized success of a Startup. More common is the Startup that has crossed-over to being a Small Business… in almost every case the crossover to Small Business represents a failure for investors, where the company established a sustainable business but not one that could generate liquidity. These companies are sometimes referred to as “zombies” by investors… won’t die, but the stock will never turn into cash. For Startups it is way more likely that they fail completely, burning through all cash in high-risk attempts before discovering an actual business. The lucky ones can become acquihires (where a company “acquires” the team as employees, but no real cash is spent). Acquires can be a decent outcome for some of the team, but it a failure for investors.

Know Thyself

And this gets back to my question to many entrepreneurs, “what do you want to get out of this?”

Too often an entrepreneur has shared his company with me and I’ve seen a good business – one that can pretty reliably grow at 10-15% per year, provide jobs for many grateful employees, have lots of happy customers, enable taking decent amounts of cash off the table as it grows, not require 60+ hour weeks to manage. That’s a pretty good outcome, but it is a Small Business, not a Startup.

A lot of entrepreneurs (especially in Silicon Valley), see Startup as the only option.

And, Startups are great, too! They change the world (usually with the intention of making it better), they risk death doing the crazy things that occasionally produce amazing results. And for those very few entrepreneurs that make it through the gauntlet, successfully deliver a revolutionary business, they are rewarded with substantial financial rewards and, occasionally, hero-like status. They’ve created a great business.

My advice to any entrepreneur starting the journey of building a company is understand what you want to get out of the company, from quality of life to financial reward, and understand if you want to build a Startup or a Small Business.

 

I would really like to have more great Small Business stories! If you are part of a Small Business or you know of a great Small Business, please leave a comment!