It was Monday, April 9, 2012 and we were at a team dinner. We were launching Everyme the next day at 10:00am. Launch was a Tuesday, of course. Consumers use their phones and the web more on Tuesdays than any other day. We had everything set: the TechCrunch article, the AllThingsD piece, and a handful of interviews with top tech blogs. We had 25,000+ people that had signed up to be notified about our launch. We designed and shipped a special page with a countdown three weeks earlier on our homepage. It seemed like the perfect time for our iPhone-only social network for groups: Instagram had been purchased the same day as our team dinner for a billion dollars and Everyme was, in our minds, the Next Big Thing™.
Our plan was simple. Launch the app and generate enough buzz for 25-50,000 downloads, or what we guessed was enough to propel us into the top apps in the Social Networking category in the App Store. Once we got there, we would start generating “organic” downloads from people checking out the top free social apps. A month later we’d roll out an Android app and web and we would be proclaimed king of the messaging space. Mark Zuckerberg would invite us to Fuki Sushi for vegetable tempura rolls, and we would laugh about how we crushed all of our competitors as he handed us a billion-dollar check addressed to Everyme, Inc.
So that Monday night, we were on top of the world and there was no way we could lose. We were probably in the top percentile of all startups already, having checked everything off of our startup bucket list: Y Combinator. CHECK. Raise a big seed round. CHECK. TechCrunch. CHECK. When I went to sleep that night, my body buzzed with excitement.
Tuesday morning rolled around, and everything went live. Mandatory tweets and Facebook posts went out, congratulatory emails from investors filled our inboxes, and my second monitor looked like NASA mission control, full of custom stats dashboards and Twitter searches.
Just hours later, by Tuesday afternoon, we already knew that our plans and the reality were far apart. Signups were coming in, but at a pace that would never reach 25,000 the first day. TechCrunch was sending hundreds of visitors and not thousands. Our Twitter searches were full of users that didn't get it. And there was no Zuckerberg dinner invitation in our inbox. We peaked at rank 35 in the Social Networking category and ended up with 11,000 downloads and 6000 sign-ups for our first day. Not exactly the day we expected.
It didn’t get better the rest of the week either. We had fewer sign-ups on Wednesday than on Tuesday: 2000. And fewer sign-ups on Thursday than on Wednesday. And so on. To top it off, all of our team members had access to the stats dashboards. You could see the psychological effects of dropping numbers impacting productivity and morale significantly. It felt like we had bet it all on red and the ball stopped on black.
The fact is that when you create the big launch event, you will always see the subsequent big drop-off. Your market is not TechCrunch readers and Mark Zuckerberg does not want to eat vegetable tempura rolls with you. If you plan for massive scale out of the gate, you will face disappointment and a morale drain that can kill your company. And unlike a lot of other problems that you face in the startup world, learning this lesson the hard way can cost you your startup right at the outset. Here are a couple reasons why focusing on a big launch is the wrong strategy:
“Launching” screws with your metrics – and you need clean metrics to evaluate and iterate on your business. If you see 6000 signups on day one and 2000 on day two, you can be mislead about the strength of your vision. It clouds your ability to single out the passionate users and understand their usage patterns.
You’re probably not going to find product/market fit right out of the gate. So whatever press or marketing you have planned will fall on uninterested eyes. Again, this will mislead you. You’ll spend less money and waste less time by locating your interested market first and then pursuing marketing channels to reach them when ready. It sounds obvious, but it isn’t. When you have a consumer app, at first, everyone seems like part of your target audience even though they aren’t. Likewise with enterprise, not all businesses are candidates for your software.
As mentioned earlier, the bigger your launch, the quicker you will enter the famous “trough of sorrow.” No human can easily withstand the emotional rollercoaster of startup metrics. Such baggage can lose you co-founders, employees, and your capital. And you will lose faith in yourself in the process.
You’ll be penalized when raising your next round. Neither the bell-curve nor the downward slope is an attractive graph to show investors. You can demonstrate growth by finding one passionate user, and then ten, and then 100 instead of taking in 6000 sign-ups to find 111 passionate ones. Some savvy investors will ignore your charts and focus on you – fine – but you have to be a champion. You can’t afford to think negative thoughts about your business when talking to an investor.
Having been through multiple launches, seen companies launch at big conferences, and talked with many startups that have experienced the same effect, what I recommend – and what we’re doing at Origami - is not launching at all. Take the word launch out of your vocabulary – it’s a sign that you are gambling on your app and not building a long-term, sustainable company. Instead, put your sign-up page up or your app out because you need more feedback on your idea. Find an audience of passionate users, even if small, and reach out to their community through appropriate means. Try SEM and Facebook ads to find a target market. Experiment with business models and onboarding flows. Let the press come to you because they love what you’ve made.
You wouldn’t know it by its plain homepage, but our new product has a thriving community of families in the hundreds already. We’ve been “testing it” for months. One of these days we might put out a homepage where families can sign-up – but you won’t hear about it from the press. You’ll hear about it from a passionate fan.
The story about Summly's 17-year old founder cashing out his company for $30,000,000 is fascinating because it makes no sense. I hate to be a curmudgeon, but I think Yahoo shareholders deserve an explanation. It's not clear at all to me that they are getting their money's worth. Let's walk through the story together (Disclaimer: I have no idea if it actually happened like this. Just an educated guess.):
Yahoo says great, we are looking to beef up our mobile team here. We are also interested in the future of news. You have 5 employees. But you don't have enough downloads, technology, or revenue for this to be an attractive deal to us on the real M&A front. Tell you what, you guys have raised $1.5m. It won't take a huge sum for us to pick you up. I think if all of your engineers pass the rigorous technical/CS interviews that Marissa has mandated, or at least a majority, we'll hire your team and we'll pay your investors back.
Summly says OK, let's pursue that option. I think my team can pass your interviews.
Yahoo screens the employees, and tells the founder that 2 of them passed. And we'll let the the founder skip the interview because he's 17 and won't pass it - but he probably understands mobile better than half the people at Yahoo.
Summly says dang, only 2 out of 5 passed? Umm…alright, well will you still buy us? What's the number?
Yahoo takes the information back to PR and corp dev's numbers people. PR calculates that they'll get major press for the acquisition of a teenager's company, values that press at $1m. Corp dev says they'll pay $1m per engineer as is typical. And we'll throw in $5m for the founder. That brings the total to $8m.
Summly says no, $50m is our minimum. We need to pay back our generous investors.
Yahoo says $15m is fair. After all, we're getting 3 employees, shutting down the app, and will have to rewrite the technology on our stack with a team of senior engineers.
Summly says $30m.
Yahoo says yes.
What?????? The craziest thing is that there are a lot of really qualified, CS-beefy teams doing really amazing things in the mobile news/discovery space these days - and that would definitely take a $30m acquisition offer or less. I don't really understand why they picked this one.
Update on March 27: I just want to clarify some things, since this article really took off and the story is pretty much out of my hands now. First, I mean no disrespect to Nick or anybody else at Summly. They obviously made something people want, and Yahoo wanted. The app was beautifully created, wonderfully marketed, and cool. It just seemed to me that this was not a typical acquisition, and therefore Yahoo needed to explain it better. I also want to say that in my last paragraph, I mention that there are othergreatteamsinthemobilenews/discoveryspace that Yahoo could have bought. I was not referring even a little bit to my own company that makes Everyme.com and Origami.com. Neither of those properties have anything to do with news or content discovery. They are private social networks. I don't expect any redactions from any news publications, I just wish they would ask me for clarifications or do maybe 3 minutes of research on my company and me before calling me a “jelly belly” or declaring my post as “adolescent-style envy” or surmising that I wonder “why him and not me?”. I'm neither envious, jealous, nor do I wonder why it wasn't me. I am just curious like a lot of other people are, as is evidenced by how popular this post became.
I was getting a haircut recently, and the owner happened to be present. I asked the owner how the salon got its first customers, because the business is booming and the owner now has multiple salons.
“I used to go hang out in the mall where women from the town would be. I’d offer pretty girls a free haircut or other free hair services, as long as they came to my salon with my business card. The women didn’t always show up, but when they did, we’d give them a haircut or coloring or whatever it is they wanted free of charge, as I promised.
I knew I wasn’t that good at cutting hair at the time; I had just started. So I wasn’t going to be able to sell clients on my talent alone.
What I knew to be true was that if you were a pretty girl, the haircut didn’t matter that much – you'd get compliments on your hair all the time whether it looked good or not. And "your hair looks great” is always followed by “who did it for you?” I was able to make a lot of mistakes early on with new customers, and they’d still be a great source of referrals for me.
It still works today. When new employees ask me how to build a clientele like mine, I simply tell them: ‘Cut the hair of all the pretty girls for free.’"
I wrote an article recently on why mobile app-first companies are doomed to fail due to their inability to close viral loops and retain users effectively. I pivoted my own company’s new product Origami to focus on the web and build mobile as a companion. The article centers on data regarding onboarding and our inability to optimize onboarding in a timely manner. I’d like to propose a couple changes for Apple and Google to consider that I believe would make mobile a viable platform for startups going forward. I’ve ordered these from most plausible to least plausible.
1. Ability to pass parameters from a download URL to an app
“I have no idea why people are downloading my app, or how they found out about it” is the response given by most app developers when asked where their mobile downloads are coming from. This is a huge problem and there is an easy and powerful fix.
On the web, there are a number of ways to track a user from page to page:
Referrer header that tells you what page someone clicked to get to the current page.
Cookies so that a website can, for example, store a bit of information about a user to keep them logged in even if they close their browser.
URI parameters that trigger predictable actions on a page (i.e. google.com/?query=soup will always show you a search for soup).
All of these methods let the developer maintain state for the user, as well as potentially actionable insights on where your users come from and what they are doing.
If a user transitions from the mobile web to the App Store, the chain is broken and we’ve lost all information about the user. We can’t maintain state and we no longer reliably understand where the download came from.
The solution is simple: let developers pass arbitrary parameters from the web through to a download.
Currently, the download link to our app is a static URL:
Apple or Google would then make these parameters available to the developer from the native app. The link above would allow us to keep the user logged in from web to download, as well as know where our new user came from.
I believe this single feature alone would spawn an ecosystem of startups. Developers could instantly personalize app downloads and ad companies could sell real performance-based install campaigns. And we’d finally be able to answer the question of where downloads came from.
2. Show search terms from App Store/Google Play in developer portals
Related to the ability to pass parameters is a simple dashboard that the developer portals should include, with a Google Analytics-like view of how users discovered their app organically in the App Store or Google Play. It would show a list of keywords used to get to your app and their frequency. This doesn’t seem that hard to do, and it would provide an enormous increase in visibility into where users are coming from.
In addition, if the user came from a featuring or from a particular category or Top X chart, that information would also be valuable to share with the developer, either afterwards in a dashboard or even better, on the user’s first app open.
If we had this information available to us, it would help us optimize our app descriptions as well as give us insights into what users are looking for. We’d save a lot of development time if we knew people came to Everyme primarily because they typed in “Group Messaging” or “Private Social Network" in terms of prioritizing features and marketing campaigns.
3. Removing the app price floor, allowing paid upgrades, and adding the ability to generate coupons
I believe that the $0.99 floor on app pricing and the inability to charge for an upgrade degrades the quality of apps and has had a negative economic effect on developers as well.
App developers who shouldn’t be making $0.99 off of terrible apps make a profit on every random person that downloads one, and thus they have an incentive to flood the store with low-quality apps at a guaranteed profit margin. App discovery is very difficult on mobile so quality apps get buried under the load.
App developers who should be making a lot more than $0.99 per app end up pricing their apps at $0.99. Mobile consumers seem to be extremely price sensitive - probably from the pricing floor. Great app developers end up making less money than they should. In addition, since developers can’t charge for app upgrades, they have little incentive to continually improve their product. This is passed on to the consumer in the form of higher expectations for 1.0 apps.
Startups that know that they can’t make a long term, sustainable business selling apps at $0.99 give away their apps for free instead. Eventually they will turn to advertising or virtual goods. But users of a free product are not very sticky, and why should they be – they haven’t invested anything and don’t expect a return.
The solution to me is simple: Remove pricing constraints. No minimum pricing, ability to shift pricing in real-time, paid upgrades, and also couponing. Coupons are a great way to incentivize people to download your app. They let you test price sensitivity of your target market as well as create artificial demand. I’m sure there will be a flood of $0.01 apps, but that’s great because all of the bad apps will trend towards free and the good apps will have the opportunity to find their equilibrium price.
4. Programmatic app submission and developer APIs
As has been pointed out many times before, the ability to deploy fixes and new features on the fly has been a huge boon to the web and we need a similar system for mobile. It doesn’t need to be complicated – just a REST endpoint to upload a new Android APK or iOS binary along with metadata – version number, changelog, etc. will do. Coupled with automated build systems like Jenkins, developers will be able to fix bugs faster and test features in real-time with something as simple as a Git commit.
I think a corollary feature to programmatic app submission is more APIs for developers surrounding the app details. Adjusting the icon, screenshots, pricing, search tags, and your app description via APIs would save developers time, money, and would give us more success factors that we can algorithmically control.
5. Load a native app immediately by hitting a website/URL
Allowing developers to load a native app via the mobile web would solve 95% of the problems with mobile. Here is what I mean by this:
User reads about Everyme in their mobile Twitter client or sees an ad.
User visits Everyme.com.
Mobile web browser encounters a new HTML header tag:
If the user wants to go back or reveal the address bar, he or she swipes down from the top (currently loads notifications) and the address bar shows everyme.com as being loaded, along with standard browser navigation controls.
The main complaint I’ve heard with this is that mobile apps are huge downloads. That’s true – but the average size of a website has increased greatly over time, in addition to our network bandwidth. I suspect that app developers would also adjust their code to load less heavy resources synchronously. We would figure it out as a community.
6. Allow an app to set itself as the default handler for files, calls, texts, etc.
What I really mean by this is that we need more power over the core functionality of the phone. Android has embraced this but iOS hasn’t, and we need buy-in from both systems, especially for apps that have a social component. We need the ability to ask the user if it’s ok for our app to handle certain phone events and files by default.
This hurt our company a lot when we realized we could never create an address book app better than Apple’s because we weren’t able to capture phone calls, texts, or the recent calls log. We ended up creating our own call log internally, but it was a significantly degraded experience from the default address book.
I am hopeful that in the next couple years, at least some of these changes will be implemented. At that time, I think it will make a lot of sense to reconsider a mobile app-first strategy. For now, I still recommend that you build mobile apps to engage and retain users alongside the web, but not necessarily to acquire new ones.
There has been discussion from the venture capitalist angle on the failings of mobile consumer companies, including posts by Fred Wilson and Om Malik. I wanted to share my perspective, having been the co-founder of a mobile-first startup . We’ve raised $3.65m to date, and have tried two mobile-first free social products. However, for our next product, we are going web-first and charging out of the gate.
Ads are the Internet’s tax on users who want free apps and websites. Allmost all free apps and services have ads. Ad-supported companies are akin to the government in the sense that they are both really good at finding ways to charge you without it seemingly coming out of your pocket. Many people’s taxes are taken automatically out of their payroll, so they don’t think of that money as being theirs to begin with. Similarly, we feel like everything that we don’t directly pay money for on the Internet is free, but that is simply not true.
Unlike taxes, however, ad-based services target lower-income and lower-education audiences because that’s where they make all of their money. To take the largest example, Google makes $30.00 ARPU (Average Revenue Per User) per year and charges about $1/click on average to advertisers. That’s 30 ads clicked per user per year. I’m certainly not clicking that many Google ads per year and I don't know if most technically-inclined users do. We know where content stops and ads begin.
What’s the cost to the user? The cost is the loss of privacy, and future opportunities for the user that they’ve lost as a result. Those opportunities can cost tens or hundreds of thousands of dollars as well as future happiness. Advertising-based companies need lots of data to win advertiser dollars away from television and newspapers. That being said, your data is given mostly in aggregate, so none of your personal information is revealed or sold directly to advertisers (in most cases). Usually the argument goes that your data is being sold, but that’s not mine (unless I'm trying to sell privacy to a lay person). If that were true, consumers would revolt the same way they would if they had to go into their bank account once a year and hand 20-50% of it to the government to spend on programs like the TSA. My argument is different; that because of the way ad-supported companies must operate and grow, your data is compromised.
To gather enough data to be statistically significant to advertisers, as well as to achieve the scale necessary to have a large enough lower-income and lower-education audience to click on ads, all ad-based companies must grow very large user bases. They also have to grow their user base fast in the early days of the company, because nobody will suck up the cost of running a slow-growing and high-cost tech company for a long-enough period. To raise venture capital post-seed round, you need fast growth. You will not find many or any large advertising-based tech companies that have not raised money from VCs.
So advertising-based companies have to grow very large, very fast in order to support their free product. Let’s talk some numbers on user acquisition. If you work at a startup and have access to your funnel data, you can confirm that what I am saying is true. User acquisition is ultimately about retaining the user through all stages of the user lifecycle. If you don’t focus on that, at each step of your website or app’s onboarding and main user activity flows, you will lose a percentage of users. I believe this is the primary reason that mobile is failing.
Let me share with you some rough numbers from our mobile-first startup. Out of 300,000+ downloads and 250,000 unique website visitors, 200,000 people have signed up. So right away, chop off 60% of your audience whom are just window-shopping. As an aside, I have heard privately from an app maker with a 100m+ downloads that 50% of people don’t even open their app after downloading. And that's not counting people who can't find your app in the store or decide not to download it after seeing your app rating (4.5 stars, in our case).
We used to have a screen where users could input their phone numbers and emails to help other users find them better. Out of 200,000, chop off 25% who don’t have the patience for that or are scared that we will sell their phone number. We also used to have a social network sign-in screen to automatically create groups for our users. Another 25% don’t want to sign-in to a social network, don’t see the skip button, or get bored by this time. We have since removed those two steps, but it took us a while to get there because we had to re-engineer how onboarding worked.
So that takes our original 550,000 eyeballs + people to 100,000 users. Now that the user is in our app and has an account, we want them to create a group and add their friends or family to the group. 25% of users won’t create a group and another 25% won’t add anybody to the group they created. Now we need them to share something to those people. Then the people they share with need to see the value, understand what is going on, and go through most of the steps above.
At best, we retain 5% of users through the entire onboarding process. Attempts to fix it have raised it only nominally. We are not alone on that count even amongst apps with much better onboarding and many more app versions than our own.
The most natural way to combat this is to try and ratchet up the total number of downloads and that costs money. If you paid Google’s $1 CPC for people to enter your funnel, you’re really paying $20 per user and you will never recoup that cost. Simply redesigning or reengineering mobile signup/onboarding is not enough because on mobile, you can’t deploy or react to user behavior fast enough to test a lot of things. Non-active users tend to only download big updates and those updates take a ton of development time. You can't ship bugs because your rating will hurt. You also have already lost a potential user because there is no great way to tell a user that got lost in your funnel to come back and try your new funnel. The press is not going to write another article championing your new funnel. Company emails have tiny conversion rates to mobile no matter how sophisticated your emailing marketing tricks are. The user has already calculated in their mind how long it takes to go to the app store, find your app, download it, enter their password, open the app, and go through onboarding, and because it will take so long they simply won't do it.
All in all, mobile service apps turn out to be a horrible place to close viral loops and win at the retention game. Only a handful of apps have succeeded mobile-first: Instagram, Tango, Shazam, maybe 2 or 3 others (Games drive short-term revenue but don’t get me started on that topic – sell a billion $0.99 games with 30% taken off the top by Apple/Google and you now have the equivalent revenue of a Call Of Duty opening weekend).
You have an entirely different onboarding story on the web. You can test easily, cheaply, and fast enough to make a difference on the web. You can fix a critical bug that crashes your app on load 15 minutes after discovery (See Circa). You can show 10 different landing pages and decide in real-time which one is working the best for a particular user. You can also close a viral loop: A user can click an email and immediately be using your app with you. You can’t put parameters on a download link and people don’t download apps from their computer to their phone. Without the barrier of a download + opening the app to try your product, you can prove value to the user immediately upon their first impression, as is with Google. In addition, the experience of signing up for a service is superior in every way. Typing is easier. Sign-up with OAuth is faster. Tab to the next field. Provide marketing alongside sign-up as encouragement. Auto-fill information is a feature in every browser. The open eco-system of the web and 20 years of innovation has solved many of the most difficult parts of onboarding. With mobile, that kind of innovation is lagging significantly behind because we create apps at the leisure of two companies, neither of which have a great incentive to help free app makers succeed.
As I said before, ad-supported companies need to grow very large, very fast, and I said that that is at the cost of your privacy. I made my case for why web companies can retain and acquire users easier, and the way to do that is through testing and the web’s ability to provide quick and perceivable value to a user. What follows is my theory: All advertising-based companies will innovate and iterate to approach zero set-up time, zero friction user actions, and a maximum viral factor, because that increases their growth and revenue.
In order to get to zero set-up time, in the best-case scenario a user will be shown a highly targeted list of suggested friends, auto-follow people, or not have to sign-up at all. In any case, they will not be provided customization options. Also, the user will be shown interesting and relevant content immediately, which requires a vast amount of viewable and public content. In order to achieve zero-friction user action flows, like searching or sharing, it will provide few or zero advanced sharing options and in some cases even share automatically on your behalf. Lastly, to increase the viral factor of the app, invitations will be sent seamlessly or automatically and results and content will be available for any user preference or search.
Unfortunately, your privacy is an advanced option and would in most cases damage one or all of those company goals. Nobody wants to share without an audience, consume a news feed without any content, or search and receive no results. So I make the obvious point: Google and Facebook need your data, information, and content to be public so that they have something to show other people.
The cost to the user is monumental. Unfortunately, you don’t experience that cost until it’s much too late to do anything about it. A blog post could cost you your job, a cached tweet could cost you a relationship, and an inerasable search result can cost you the opportunity for both.
So what can you do if you’re an entrepreneur or have a mobile-first startup not getting the traction you deserve? I’m not really sure yet, we are still figuring that out at our company. I don’t want to peddle our wares, but I’ll tell you what we are thinking and working on at Origami Labs and it’s just something for you to consider for your own business.
We want to place our chips where we believe we have the best chance of succeeding based on our theories and data. For us, mobile is not that place, which is why our new product is going to be launching web-first in the next couple months, with mobile as a companion app. We are taking a big bet on the web and the Internet in general, as you’ll see by how it functions. We are also going revenue-first because we believe in privacy and we’re willing to trade a smaller, slower-growing audience for it. Our new product will cost you money, so you can be assured that it doesn’t cost you something else.
In conclusion, I want to say that I don’t think mobile is going to stop growing. We are not going web-first because people use the web more than mobile. I use my phone more than anything else. I just don’t think that an entrepreneur who wants a real shot at success should start their business there. The Android and iOS platform set us up to fail by attracting us with the veneer of users, but in reality you are going to fight harder for them than is worthwhile to your business. You certainly need a mobile app to serve your customers and compete, but it should only be part of your strategy and not the whole thing.
I don't think there is enough data yet to answer that, and what's out in public is mostly anecdotal. I wanted to come up with something that is a fair representation of successful tech companies and how many founders they each have.
Deloitte publishes an annual list of the top 500 fastest growing technology companies, sorted by their growth rate. Tesla tops that list this year. While the list is made up of clean tech, bio tech, and software, it's reasonable to assume that it's a list of high-achieving, growth companies. Not all of them are startups, but they all most certainly can be characterized as successful. It certainly would not be biased towards any particular founder count.
I went through the list, parsed out the top 100 companies from the list in the areas of Software/Internet/Communications/Networking by Deloitte's labeling conventions, and then scoured the internet for hours looking for accurate data about how many founders each one had (not as easy as you would think).
The next thing to know to be able to make any reasonable hypothesis is to find out how many tech companies are started by each cohort. Any ideas on how to get this data?
One lead I have is that 72% of all businesses are sole proprietorships, e.g. they have a single founder/employee. That does not take into account how many were founded by one person and grew. If it is true that greater than 70% of all companies are started or owned by one person, you would be able to make the conclusion that more single founders fail than should on average.
Every four years when the presidential elections come around in the US, I become both curious and critical of the government, as does everyone around me. What I'm about to spout is entirely idealistic, unrealistic, and most definitely oversimplifies everything. That being said, many people I talk to about government and politics that work in technology think the same way I do. Minor differences aside, I believe there is an early adopter faction growing that I'm tentatively calling “The Technology Party.” Members of this fictional party share the views I outline below. I had at first thought to call it “The Internet Party” but I feel that can be misconstrued as extremist. One who believes in the power of technology and the network does not necessarily think that everything should be open and free, although they may.
Everyone agrees that our government and elected officials are unwilling to embrace technology fast enough. Many of them don't understand technology, don't know how to use basic tools like email, and really have no interest in the internet other than as a way to help them win political campaigns on Twitter. The extent of internet technology in the government is ASP.NET websites that can charge your credit card for parking tickets. It astonishes me that the average citizen spends 10 minutes every 4 years, or 3.5 hours in the total of their life, voting for measures that impact billions of people. The internet and mobile phones should enable us to not only make more critical decisions in realtime, but make those decisions better-informed and with a larger participating electorate. There are more cellphones in the US than people but only 63% of people vote.
This problem of making tons of decisions all at once is systemic. Politicians generally employ a waterfall development methodology to enacting change instead of an agile one. This methodology produces two thousand-page long documents that a single person is incapable of understanding or processing, and that must be voted for in an all-or-nothing fashion. The government could learn heavily from lean and agile software engineering ideas.
In addition, the current way things are done makes testing new ideas in the government very difficult, if not impossible. On the web, we test things cheaply and efficiently. A company like Google can test thousands of variations of things automatically and come to the best solution for a given problem within days. I suspect that we could use our local governments as testing buckets in a similar way to how we do multivariate testing on the web. And indeed there is no need to apply uniform policy across all cohorts, or towns, in this metaphor. Perhaps one underperforming town can learn and apply policy adapted from better towns with similar demographics and conditions. That's what we do on the internet.
In order to fix any of these problems, our senators and representatives need to be more productive. I would be fired if I tried to work 3 days a week. I don't think it's too much to ask for our officials to take a little less time off. I also find it strange that we expect our president to, in effect, work only three years on our behalf when we paid for four. We should not expect a lengthy campaign from the incumbent when there is so much to do for our country. If you did good work, it should be more or less self-evident the same way you'll probably know how good your startup idea is after 3 years.
I strongly believe an internet party candidate does not subscribe to a binary slate of views assigned to them by their political party. Many of us believe neither candidate is very different from the other; if not that, than we certainly believe that neither candidate would have a vastly different total effect on the country. That's primarily because of how ineffectual government is. I think all of us believe that everyone should be treated equally and be given equal civil rights. That is, for some reason, a recently liberal viewpoint. On the other hand, I think many of us also desire our president to be a strong business leader with an intricate understanding of economics, finance, and accounting. That is for some reason a conservative view.
I don't think it's too much to ask for one out of 300 million people to be someone that loves all people, can create a strong and healthy economy with a balanced budget, and is a good enough public speaker and intellectual to fulfill the duties of the president here and abroad. This person also needs to be willing to change their views with the onset of new data, as any good leader does. I am tired of political ads from both sides about flip-flopping views; if you're not changing and adapting all the time, you are probably making stuff up.
This touches the surface but the general idea of The Technology Party is a society led by technology, not a laggard to it. One where politicians use data and testing to make decisions instead of political contributions. One where all politicians work as hard as we do.
We made a small change yesterday on Everyme that had a huge impact on our conversion rate.
When a user invites a friend or family member by email to an Everyme Circle (basically, a group),we send an email to the invitee:
Each of the links in the email body, when clicked, bring you to our signup flow with your information pre-filled:
All the user has to do is fill in their password and they're now part of the Circle. Very simple.
However, if the user is already logged-in to an account on their browser when they click the invite link, we assume they have been invited to a new Circle and want to join it, so we automatically associate their existing account with the new Circle. Now the user is part of multiple Circles, which is good.
Over the past couple months, we've had a couple reports here and there that people were having trouble joining a Circle via our invite emails. Basically, we have a guard in place so that people don't join a Circle twice. If you try to join a Circle via an email invite and you are already part of that Circle, we cancel the invite.
Yesterday, we decided to make a small change to see what happens. Now, we no longer automatically associate their account with the new Circle if a user is already logged-in. Instead, we log them out and force them to make a choice on whether to sign-up fresh or login again, just in case it's a different person using the same browser. The results are huge. Today is by far our biggest day ever in terms of email and SMS signup conversion and we're only halfway through the day.
So what does this mean? It means a couple things that you might want to think about when designing a system:
Lots of people share the same computer with other people - so don't hook up your email buttons to automatically do things on your site without double checking the user's identity.
People do not always have multiple email addresses so assume different emails are different people.
People do things together, including signing up for new services. It's very clear from our data here that one person signs up and invites somebody else nearby to them, in the same place and possibly in the same room. Use this info wisely.
I am constantly trying to be a better programmer because I want to be able to make better things for people than what they already have. I think most programmers, as compared an average profession, have a strong desire to improve and “invest in their knowledge portfolio” because learning has an easy-to-see impact on what opportunities are available. It occurred to me that the way I do this for myself is very structured and thus can probably be systematized and possibly benefit others. Here are three questions I always ask myself when approaching a problem or a new project in order to become a better programmer:
1.) What were the bottlenecks, annoyances, or performance issues of the last code that I wrote that can be improved? It does not matter what problem I am solving, there are certain things that I do no matter what type of code I am writing, from formatting, style, and documentation, to deeper things like how I cache fetched objects. If I strive to even make just one thing better, or faster, or prettier than last time, I become a better programmer.
2.) Is there anything I take for granted about what I am about to code, and if so, is there something better? Curiosity about what I take for granted is the best way I've found to improve my skill set. For example, most people (myself included) use their favorite language with their favorite server (NGINX + unicorn) whenever they are starting on a new web project or need to build a new feature, whether or not it's really the best option for the job at hand. I question this every time I start on something new. And I don't just mean looking at new languages and new types of server - I mean sometimes the best option is writing my own server in my own language. In order to come to that decision, I need to question all of my assumptions. It's not easy to do, but just by questioning and investigating things I take for granted, l become a better programmer.
3.) Has anyone else solved this problem or done this type of thing before that I can learn from? Googling effectively is part of my skill repertoire and since I don't know what I don't know, I need to try and look at as many different sources and hope I stumble across new leads, terms, languages, libraries, or anything that I couldn't have thought of myself. And a lot of the time, such research leads to things outside of what you were originally looking for in the first place. For example, I recently wanted to speed up JSON parsing on our servers so I looked to see if there were good alternatives to the Rails default. It turns out there are but at the same time I stumbled across Jbuilder (it now ships with Rails by default, I believe) and I was inspired by its approach to building JSON objects, from the usage to the implementation. I ended up creating a module based on Jbuilder that has similar usage but an implementation that takes into account some of my unique needs. Googling makes me become a better programmer.
Lastly, I think it's obvious but if you're a programmer and not reading Hacker News, I guarantee you will miss out on things every day that will make you a better programmer.
I’ve mentioned the idea of unethical defaults before, but I want to formally introduce and define the concept because I think it’s a growing problem in our industry. Ivan Kirigin wrote a great blog post about Quora’s new “Views” feature that has struck a chord with the tech community. The reason his post is great is because he pointed out specific examples of how a feature turned on by default can be dangerous to the uninformed user. Unfortunately, Quora's wrong decision is just one in a long line of unethical defaults.
Here is my definition of an unethical default:
An unethical default is a software setting that is turned on automatically or absent a choice by a user to their detriment.
To be fair, there is a lot of precedent for talking about ethics and software development. ACM has maintained a Code of Ethics for software engineers for twenty years.
But unlike some other professions like law and medicine, neither software developers nor their product managers are subjected to any code of ethics. Software developers are not forced to join an association to practice their trade, even though software can be just as deadly as any other profession. You can find many examples of software mistakes taking down manned helicopters and space shuttles, and costing companies and countries billions of dollars. In fact, software can probably do more harm than anything else. I think that’s just the natural flip-side of something that can also do so much good.
Though there is precedent for talking about ethics and software, it is not discussed enough nor is it taken seriously enough in our modern age of high-level languages and massive distribution. I wrote recently that I think sharing in public on the Internet is actually an unethical default. Lesser-informed people will not understand the impact that exposing their lives and opinions will have on their future. I recognize that view is an extreme one. However, any product manager or data scientist worth their salt can tell you that an overwhelming majority of users do not change defaults or deep settings.
For that reason, it’s incredibly important for software engineers and their managers to think about defaults as part of their design process. If a feature is to be turned on by default that impacts the end user significantly, like the Views feature on Quora, or the “Public” sharing option for new accounts on Facebook, then appropriate time should be spent informing the user of the choice that the developer made for them.
In Quora’s case, they should have provided a full-screen pop-up on the user’s first visit asking whether they wanted the feature on or off, without an option to skip. No doubt, some percentage of users would like that feature on, but at least they would have made a choice of their own free will.
Ethics aside, there is a very practical reason to think about defaults and settings as part of your design process. I would actually argue that if you ship a feature that through your judgment should be off by default, it’s probably a feature that doesn’t need to be shipped at all.
