Amazon Alexa is a “colossal failure,” on pace to lose $10 billion this year

Ron Amedeo for Ars Technician:

Amazon is going through the biggest layoffs in the company’s history right now, with a plan to eliminate some 10,000 jobs. One of the areas hit hardest is the Amazon Alexa voice assistant unit, which is apparently falling out of favor at the e-commerce giant. That’s according to a report from Business Insider, which details “the swift downfall of the voice assistant and Amazon’s larger hardware division.”

Alexa has been around for 10 years and has been a trailblazing voice assistant that was copied quite a bit by Google and Apple. Alexa never managed to create an ongoing revenue stream, though, so Alexa doesn’t really make any money. The Alexa division is part of the “Worldwide Digital” group along with Amazon Prime video, and Business Insider says that division lost $3 billion in just the first quarter of 2022, with “the vast majority” of the losses blamed on Alexa. That is apparently double the losses of any other division, and the report says the hardware team is on pace to lose $10 billion this year. It sounds like Amazon is tired of burning through all that cash.

The BI report spoke with “a dozen current and former employees on the company’s hardware team,” who described “a division in crisis.” Just about every plan to monetize Alexa has failed, with one former employee calling Alexa “a colossal failure of imagination,” and “a wasted opportunity.” This month’s layoffs are the end result of years of trying to turn things around. Alexa was given a huge runway at the company, back when it was reportedly the “pet project” of former CEO Jeff Bezos. An all-hands crisis meeting took place in 2019 to try to turn the monetization problem around, but that was fruitless. By late 2019, Alexa saw a hiring freeze, and Bezos started to lose interest in the project around 2020. Of course, Amazon now has an entirely new CEO, Andy Jassy, who apparently isn’t as interested in protecting Alexa.

Yes, Apple HomePods are expensive. Well, hardware is expensive and you can’t sell devices at a loss for a decade. Let that sink in.

If you look and compare at the two devices and their business models. Apple’s Siri is always at the heart of Apple devices and it makes all of their devices better and accessible. At the end Siri is part of Apples OS strategy.

Amazon echo on the other hand, I have no idea what is their business strategy. In the last 8 years of owning an echo dot, I have used it to set timers and occasionally my 9 year old has played jingles, songs and asked for help solving addition and subtraction problems.

Not once have we as a family ordered anything from Amazon using echo. And that was the big strategy behind Amazon Echo. I would love to see a product managers KPI dashboard for this product. Here is the thing, I use my iPhone 100% of the time to buy things on Amazon. If they could spend those billions of dollars to build a better iOS app, that would have paid better dividends.

Emotional Intelligence – An example

Justin Bariso writing for Inc. on explaining emotional intelligence when reporters asked Tom Brady if he was going to retire after the Bucs lost to Rams last weekend:

Never make a permanent decision based on a temporary emotion.

Nice, short and simple read, but does extremely well to explain how not to be emotional when making decisions.

As product managers we tend to get attached to the products we build and work on day in and day out but it is very important to keep our emotions aside while making decisions.

Scaling with Process vs. People

Marty Cagan writing for SVPG on scaling your product with people instead of processes:

I loved reading this article particularly because he simply uses quotes from former CEO’s who have focused on people rather than processes to scale new heights for their product.

My favorite quote here is from Reid Hastings talking about Netflix:

“[The reason Netflix has been so successful is because it has] a culture that values people over process, emphasizes innovation over efficiency, and has very few controls. Our culture, which focuses on achieving top performance with talent density and leading employees with context not control, has allowed us to continually grow and change as the world, and our members’ needs, have likewise morphed around us.”

You need people to continue scaling your product which simply means creation of new software, hardware, service, etc

Killing a feature is also important

When it comes to adding a feature to your product, there are countless ways of doing this – and we still mess it up. However, when it comes to killing a feature there isn’t much out there.

As product managers we get excited to take the product to the next level with new features. But deep inside we know there are some features in your product that simply don’t work anymore. You are tracking your product with countless KPIs and metrics to see the health of your product, and its right on the dashboard when a feature isn’t getting clicks or for that matter appreciation (feedback). We either ignore them or simply stop tracking them.

Features that don’t work cost money to support. Worst, just by being present in the product they complicate workflows and risk distracting your users from their core tasks.


You may have heard your customers complain at times: “Your product is to complicated or bulky”. There is a high likely hood that there are features sitting in your product that isn’t being used that’s adding to this bulk and complexity.


Removing a feature isn’t simple. You can’t simply release a new version without a feature. You have to treat removing a feature the same way as adding a new feature to the product:

  • does the existing feature align with your overall product vision & strategy.
  • deprecating a feature needs user search, interviews and analysis.
  • deprecating a feature needs planning, included in the roadmap, and communicate with your users.

To decide if a feature needs to be deprecated:

  • check with your users what are they using to solve their problems instead of your feature.
  • did the feature miss the market?
  • the feature may solve a user problem but its unsustainable for you.
  • the feature solves a problem for a very small set of users, but its not a problem worth solving for you.

When deprecating a feature, communication and transparency is key. Ensure you have two set paths, i.e. End of Life (EoL) and End of Support (EoS) and there is sufficient time for the users (if any) to move to other options if they are using this feature.

To ensure a successful EoL and EoS,

  • remove the feature so that new users do not have access to this
  • de-emphasize the feature in the UI – out of sight out of mind.
  • suggest alternatives and help your users migrate

Lastly, make sure this is part of your continuous onboarding strategy, where you are communicating this to your users and helping them migrate through the EoL and EoS timeframe.

Things to read for Week 44

Github gets a new CEO

GitHub CEO Nat Friedman is stepping down from his role on November 15 to become the Chairman Emeritus of the Microsoft-owned service. Thomas Dohmke, who only recently became GitHub’s chief product officer, will step into the CEO role.

Great to see a product person stepping into the shoes of a CEO.


Tesla is letting non-Tesla EVs use its Supercharger network for the first time

Tesla’s Supercharger network is often held up as the best possible example of an EV charging network: fast, reliable, and plentiful. But Tesla’s network is also exclusive to Tesla owners, meaning someone driving a Volkswagen or Ford EV wouldn’t be able to use it. But that’s now starting to change.

So how long until we start hearing about standardized car chargers?


How to design a good API and why it matters:

If you find yourself in charge of building an API for your application and need a good reference, this is a great start.


Toxiproxy

Toxiproxy is a framework for simulating network conditions. It’s made specifically to work in testing, CI and development environments, supporting deterministic tampering with connections, but with support for randomized chaos and customization.

This is a good library to have in your arsenal whether you are an Engineer, PM or QA. Testing on different network conditions is important.


Why you should develop a UX roadmap:

Thinking ahead to next quarter, consider collaborating with your fellow designers, researchers, and content strategists to develop a UX roadmap. This will prompt you to review potential work against user and business goals and prioritize the most important items. From there, you can share your draft with key stakeholders and see if they agree. Developing and refining this roadmap will help you become more strategic and focused, while helping you develop your collective perspective and voice.

Its not easy to change the culture of how things are built. It’s hard but its important to start doing this.


6 things a Product Manager is not:

4. A product manager isn’t an agile fascist

Agile and lean are all-the-rage and de rigueur in modern software development. The next statement will probably be an unfashionable one but agile isn’t the only way to build web products and waterfall isn’t evil. Product managers shouldn’t be wedded to cult agile.

This made me chuckle. Good read.


First companies and now cities battling for top talent. Good times.


Prioritize health over work. It’s important.

Product vs Feature teams

Marty Cagan writing about Product vs Feature teams:

In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.

When I talk and write about how tough it is to be a true product manager of an empowered product team, it’s precisely because it is so hard to ensure value and viability. If you think it’s easy to do this, please read this.

The lack of giving up control and delegating to your product team is probably the biggest reason I see very few product empowered teams.

Feature teams are set up similarly, but with a stark difference:

However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.

If they say they need you to build feature x, then they believe feature x will deliver some amount of value, and they believe that feature x is something that is viable for the business.

Whichever way you see it; they both are squads but the differences run deep, but I’ll leave you with that I think is the most important

Let’s start with the role of the product manager. In an empowered product team, where the product manager needs to ensure value and viability, deep knowledge of the customer, the data, the industry and especially your business (sales, marketing, finance, support, legal, etc.) is absolutely non-negotiable and essential.

Yet in a feature team, that knowledge is (at best) dispersed among the stakeholders.

Controversial topic but an essential read.

Applying a ‘Time-To-Market’ KPI in product

Gabriel Dan on Mind the Product:

It’s a KPI—used mostly by the business—to measure the time required to move a product or service from conception to market (until it is available to be purchased). The process is the combined efforts of all stakeholders, product management, marketing, and so on. It includes workflow steps and strategies involved throughout the process. It’s usually calculated in days/weeks/months/years but it can be met in other forms too depending on how the different organizations will want to implement this.

This is simply amazing and important especially when you are constantly trying to beat your competition to get out in the market to capture your audience.

The shorter the time to market is, the quicker the return on investment (ROI) can be realized, therefore you can imagine why it’s important for businesses.

The quicker the product gets on the market, the bigger market share the company will get especially in an unaddressed segment facing less competition and thus enjoys better profit margins. Getting fresh and relevant products to market quickly attracts customers.

Exactly. It is very common to get into the phase of doing more before releasing to the market. The TTM metric forces you to be frugal about your MVP.

Gabriel Dan does a great job setting the premise and goes on the explain how the TTM should be calculated. Highly recommended.

Avoid feature bloat and deliver your product strategy

Even the best products including your favorite product (can) suffer form feature bloat. In my last article Measuring Feature Adoption – I talked about measuring feature adoption. Tracking feature adoptions will help you avoid feature bloat.

A product filled with non-performing features causes

1. accumulation of technical debt,
2. increased maintenance costs,

leading to a lower customer satisfaction (NPS score) and a lack of market differentiation.

Features too have an iceberg problem. They may seem to be small features but turn out to have huge costs. This can happen when you decide to ship a feature for a specific customer or a use case instead of shipping new products.

Avoiding feature bloat

One way to avoid feature bloat is to have a strategic approach on the bigger picture. Focus on outcomes instead of output.

Avoid focusing on shipping features. Product teams should focus on the number of problems solved and the positive impact on their customers – this directly results in a better NPS score.

When you focus on the outcomes, it allows you to gather feedback from customers, talk to them more often to test your hypothesis for a new feature. Tracking your feature allows you to decide if you should either iterate or pull out this feature.

Finally, doing a feature audit will also help understand how features are being used. Looking at your feature adoption and usage metrics will allow you to decide to to kill an underperforming feature or work on increasing adoption.

Delivering a Product Strategy

As your product evolves and becomes mature, typically in the growth phase – you attempt to serve everyone. In this phase, products can be disrupted by the one big customer’s specific needs or by smaller niche markets.

Segmenting your product based on customer needs, jobs and personas will allow you to bundle your product to different tiers at different pricing options and avoid feature bloat.

Measuring Feature Adoption

When it comes to SaaS Products, product managers typically have product adoption as one of their top KPIs to track; especially when launching a new product. The logic is pretty simple, improving product adoption means higher retention, lower churn and move revenue.

However, once a product is launched we continue to release new features to keep that product adoption going, but we fail to realize that we also need to track feature adoption.

Both these key metrics indicate how well your product is received by your customers. The product adoption metric tells you the percentage of active users, while the feature adoption metric tells you the reason why people continue to engage with your product.

So when you launch a new feature, looking at this individual metric will tell you if the its driving your overall product adoption to go up or not.

Feature adoption is measured in percentage (%) as:
(# of users of a feature / total # of active users) x 100 = feature adoption %

Getting insight into what features users find the most valuable will also inform your team o how to position your product as well as help you with any product decisions you make.

New User Onboarding & Time to Value

Customers (or users) generally hire a software or a service to solve a problem. This results in immediate gratification (or value).

When customers first sign up for your product, they will either get what they are looking for; or they won’t…

In case of SaaS application, they are a bit like IKEA furniture. Unless you assemble the pieces together, you wont experience value. SaaS customers must wait to experience the value of the product. It’s this delay that makes churn a common theme among SaaS products.

This delay also referred as Time to Value (TtV) i.e. the amount of time it takes a NEW user to realize the products value.

User Onboarding is important as you want these users to realize that the product they hired is solving their problems. Product Managers should focus on reducing TtV and drive new users to being active users.

The longer your time to value, the higher customer churn. Users have very little patience. The key is to focus on optimizing your new user onboarding experience. Focus on the key actions that correlate to activation – typically an action that provides value.

It is important to have a continuous user onboarding for existing users as you introduce new features and products. TtV can also help move your already active users to engaged users where the cadence of a valuable task performed is higher. This will help drive adoption of your SaaS product.