Competing with AWS

Fools rush in where angels fear to tread

Competing against AWS and having a fighting chance is hard but not impossible

Table Stakes

Amazon is an exceptional company of our generation. They have good products, they also run a smart business. For a company to compete against them, it has to be better than AWS. AWS currently has superb momentum, traction, reputation and following. Below are what I consider table stakes.

• Customer Focus

Listen to customers. Get their feedback early and often on your ideas, features, products, economics, total offering. Talk to more than one group of customers. Talk to your least happy customers. Follow your critics, listen to them. Visit your customers. Send your staff to meetups to listen to the conversations. Do not do things on just gut feel. Validate, validate, validate.

• Discipline

Your company has to be disciplined. This means no rush projects to meet a trade show deadline or a board meeting or a competitive response. Do not do things to fill gaps in a competitive checklist. If something does not help customers, do not do it. This is hard to achieve for some of us with decades of experience with fire drills, competitive war rooms, tradeshow driven developments and “what cool shit can we do” dev cycles.

• Stay small, stay hungry

Size of your team should be smaller than what you would like to have. slight scarcity of resources should be a norm. Do not spend money because you have it. Team sizes are important. If you have a large team because you wanted to build an empire, get out of that habit or move into a different role. Smaller teams build better products. A team of 25 people has never produced anything compelling. A team of 8 or 12 have.

• Take a long view

Have a plan. Think long term about how customer requirements evolve. Think beyond 12 months. Invest in features, products that may have small pay off now, but its clear that customers will need them. This is not guessing, instead should be based on your customer conversations. In general, if a customer use case was valid 6 months ago, its likely still valid today. when people say technology is changing too fast and we can’t take a long term view, they are framing the requirements wrong. Think about customer Job to be done, that doesn’t change as frequently.

Exploiting AWS Characteristics

• User Experience

UX has not been a strong suite of AWS. For ex: Lightsail is a sorry excuse for the complexity of their EC2 offering. Similar complexity exists in other areas of their offering, including Lambda. If you can figure out the optimal user experience, by taking advantage of how people are using products now vs. when AWS made original design decisions in 2006, your company can gain an edge. For ex: Digital Ocean was able to do Lightsail like offering years ago because they did not have the baggage that AWS had.

• Complexity

Somewhat related to #1. AWS has become complex. It is still time consuming to do basic things in AWS. Automation helps, but automation needs investment and not all customers (wrongly?) willing to invest in it. You can target the customers who dont like this complexity as initial adopters of your product. If you say AWS is complex, customers for most part will agree. If you come to the table with an offering that reduces this complexity, they will atleast take a look at your offer once.

• Platform Dependency

The whisper among some of the Cloud whisperers has been that AWS developers have internal issues holding them back. One of them is platform tax. Every new feature has to be well integrated with all the primitives of AWS. This is beneficial to AWS customers, since they can expect a consistent platform. But, this means, their ability to innovate will be slower than your team’s ability to innovate. You may not have the same baggage an AWS team has. The key here is to identify a customer gap and develop it and get it sticky. AWS may try to enter this space in couple of years but you can pull away from them. For ex: see Twilio. AWS would likely want some of the Twilio revenue for themselves. AWS probably knows that its a much bigger wall to climb to get to same level of simple UX and loved solution. Do not be fooled by 1000 features in 2016 alone. In specific areas, their ability to innovate is likely slower than your team’s ability.

• Pricing Model

Majority of AWS pricing model is now outdated. Their Reserved Instances, Convertible Reserved Instances and Scheduled Reserved Instances are band aids on a decade old unit rental pricing model. This pricing model is neither elastic nor customer friendly. AWS will get the pricing model right with Lambda and newer services, but its full adoption is still few years away. Companies have an opening here to attack AWS on their pricing model. Cloud business is not Rent-A-Center business model longer term. It has to be elastic with usage. Customers will expect to pay what they use and not pay for instances sitting on the shelf. AWS on-demand pricing is super expensive and not competitive, so they push people towards RIs. You can deliver a pricing model that’s more inline with requirements of current customers. You will still do enterprise pricing etc, but to get initial adoption, you can deliver a true elastic pricing model and attack AWS on this.

In the next follow up post, I will share some thoughts on what startups can do and what larger companies can do to compete with AWS.

Thoughts?