Is Today's Email Infrastructure Fundamentally Flawed?

Sony, DNC, Celebgate, our daily headline is dominated by hackers exploiting yet another round of victims. The media never shy away from analyzing and publishing stolen information: some argue that hackers (both individuals and institutions) bring transparency to corrupt political organizations, greedy multi-national corporations and questionable celebrities. What they fail to admit is the fact that while leaked information destroys shareholder value and personal privacy, it satisfies people's "curiosity" and drives site traffic and media ratings up. Without getting into the debate of whether it does more good or bad to the society, I believe hacking is often ill-intentioned (KGB, WikiLeaks) and creates consequences that are too big and does collateral damage to too many innocent people, and I think today's email infrastructure is to blame.

Let's go back in history to the age of paper mail. When someone intercepts a package, they gain one piece of information. Today, a simple Gmail password reset phishing scheme easily exposes tens of thousands of emails in one account. It's almost laughable to compare the magnitude of damage/reward and the amount of effort required. We rely on the vigilance of every email user to distinguish phishing email and once one user fell for the trap, almost the entire domain is fallen. What if a new email infrastructure can fix this?

1. Gaining one password should not allow access to 10,000 emails. When someone logs into an email account, he/she should ONLY be able to see unread emails and today's emails.
2. To search or browse for older ones, two-factor login is required.
3. After every certain number of search queries (e.g. 10 scrolls), another two-factor login is required.
4. To download the entire email catalog, the strictest level of security is required. We can throw in fingerprint recognition, facial recognition, Iris recognition, password questions or all of the above.

This proposal is simple: we strike a balance between security and convenience. By separating client use cases with usage frequency (unread, search and download all), we can largely increase security without losing too much time. It's going to be a hard sell to individual users but I can see larger organizations adopting it.

Would you promote email infrastructure like this in your organization? If anyone wants to launch a startup with this idea, let me know!

• Originally published: https://www.linkedin.com/pulse/todays-email-infrastructure-fundamentally-flawed-maxwell-zhou

Is Software Engineering a Game of DotA?

I've recently learned from Chao Qin about an analogy that compares Software Engineering to DotA.  It sounded outlandish at first, but upon closer examination, these two activities shared striking similarities and I'll try jot them down. (For those of you who's never heard of DotA, this article is probably very hard to understand. In short, DotA is a Role-Playing Game (RPG) where players of two opposite teams farm gold and level up, eventually try and destroy the opponent's base. )

1. Farming (DotA) = Tasking (Software Engineering). DotA players will try compete for last hits on endless lane creeps in order to gain gold and experience. They occasionally take on jungle creeps to collect bigger rewards. Software engineers finish small tasks streaming in everyday to gain experience and earn salary, while occasionally take on side projects or participate in "Hackathons". 

2. Change lane (DotA) = Switch team (Software Engineering). DotA players might find it helpful to move to another lane in order to farm quicker and safer, while software engineers might have an urge for switching to another team. 

3. Level up (DotA) = Promotion (Software Engineering). DotA heroes level up by cumulating experience. Software engineers become more and more proficient until getting promoted to the next level. 

4. Pushing (DotA) = Big Rock Project (Software Engineering). In DotA, each team's main objective is to snipe enemy heroes, clear enemy creep waves and eventually take down enemy buildings. When an enemy tower goes down, every player on the team is rewarded with the one last-hitting getting the lion share. Similarly, finishing a Big Rock project in the software engineering world is what keeps the team moving forward. If the project is successful, the whole team will receive the credit while the engineer leading the project normally gets the most applause. 

5. Team Lead (Dota) = Engineering Manager (Software Engineering). Whether it's during pushing, ganking or team fights, a DotA team requires a lead player to actively provide guidance and issue orders while fighting within the team. In a tech company, engineering managers are responsible for supervising engineers, overseeing product development and "code 30% of the time" (Eliot Horowitz, founder of MongoDB).

Do you agree with my list? What analogy do you have for your line of work?

Originally published: https://www.linkedin.com/pulse/software-engineering-game-dota-maxwell-zhou

Customers Might Not Buy What They Want

I always assumed companies should focus on creating the most desirable product or service at the most competitive price point, and customers will buy what they want the most, but it's often not the case. 

Want ≠ Buy

Here are two main areas that are also critical apart from the traditional 4Ps (product, price, place, promotion).

1. How the customers want to buy.

Most entrepreneurs naturally start from how they want to sell. However, by doing that they often overlook their customer's search process in finding the product/service (PR, marketing, social media, referral etc.), and the most desired payment model, such as lease, purchase or subscription.

For example, I loved the Mercedes SLK but ended up leasing a BMW, because they provided a 2-year lease option and included a very comprehensive maintenance program for free. Payment model dominated this decision.

"Align your business model to how your customers want to buy; integrate the customer buying process into your support operation" (Martin Zwilling on Forbes)

2. What are the customers' concerns.

When I first saw Oculus Rift's video, I was amazed and totally wanted one regardless of the price. But I didn't end up pledge for their campaign because it just didn't "seem fit". I wasn't sure what games will be supported and which console is required. I didn't know about the company's reputation and their execution capability (even Google failed to build a Google Glass developer community). Customers want "end-to-end solutions", which may require product/services from more than one vendor. 

The other example is Alfa Romeo's 4C Coupe, which is an awesome car by many reviewers and sells on the same price range to Mercedes, BMW and Porsche's entry level sports coupe. However, being the new kid on the block, customers are naturally concerned about the reliability, maintenance cost and safety. Before getting these potential concerns out of the way, Alfa Romeo's sales number will remain at double digits per month in the U.S., even after sizable marketing spendings. 

In a startup's world, these two issues might drive the business from being product-centric to being more and more customer-centric. The good-o single tagline marketing approach (think "It's toasted" in Mad Men) might appear too naive and not efficient enough. Data-driven business models are sometimes required to make sure product/services are created the way customers want to buy and eliminate customers' concerns before hitting the "Pay" button. 

Originally published: https://www.linkedin.com/pulse/customers-might-buy-what-want-maxwell-zhou