Fundamental problems with software user analytics

July 31, 2017 by Jeff Martens in business

My entire career has been centered on using data to make decisions. From sales, inventory, product, financial, customer, and user data. Not only have I been a consumer of data and user of analytics products, I've built, purchased an implemented analytics products as well. So while I may not be the world's expert on analytics, I have a set of experiences that has led me to some strongly held beliefs, particularly in the area of software user analytics.

So, what is software user analytics? In short, I'm talking about data collected from web applications that tells exactly who, does exactly what in the product, and what the outcome was. This space has evolved a ton since the advent of the web. First we had simple web Analytics, which told us what content on our sites was popular and a bit about the visitors to our site (country, operating system, etc). Then, as web sites morphed into web applications, a new breed of analytics told us about usage, rather than just page loads. I call this User Analytics. Which users clicked which buttons, and what the result were.

While the differences between web analytics and user analytics may seem subtle, user analytics provide us 100x more value, in my estimation, than web analytics. That's because user analytics helps us understand user intent, and the value derived. If content is your product, such as a blog, then web analytics is probably fine for you. However, if software is your product, like social media, gaming, or banking, then you need user analytics. It can tell us where to put a button, which features to build/enhance/deprecate, what type of user gains the most value from the product, what data they desire, and so much more.

So, what's my beef with user analytics products? Honestly, I love them! Companies like Mixpanel, Google, Heap, and Segment make amazing products that I rely on. I've been successful in my career because of what they've allowed me to do as a user, and I've had my most fun at work when building analytics tools. They just aren't perfect, they leave a lot to be desired, and I believe there is an opportunity to deliver more to users today, while building for the next shift in software tomorrow.

I see 3 fundamental problems with User Analytics...

1. Most analytics providers want to own the entire solution stack

Most user analytics products do three things: they help collect data from an application, they store the data, and they offer visualization capabilities on that data. Naturally, they price for these benefits. When you buy a user analytics solution, like Heap or Mixpanel, you pay for all 3 things, whether you need all three or not. However, most businesses don't need all three for user analytics.

Any enterprise worth their salt has data as a central piece of their operations, and no piece of data they collect lives in a silo. These organizations are running a data warehouse, a collection of all the data used to run their business, including user analytics, sales data, financial, marketing, customer success and more.

While companies like Mixpanel and Heap offer best in class data capture for user analytics, they aren't a data warehouse and they don't offer best in class data visualization. In fact, its nearly impossible today to buy best in class user analytics data capture and pair it with your own data warehouse for visualization alongside your other data. Take my recent experience as an example. I recently led the selection and implementation of a software user analytics solution where I work. One of our many requirements was to reduce the effort necessary to collect usage data by at least 80%. Another of the requirements was that we could store the data in our own Redshift instance, and query it with our visualization tool of choice (Looker). So I needed to buy data capture, but not data storage or querying. We got what we needed, but we had no choice but to pay for more than we are using.

Best in class data capture for user analytics comes from Heap and Mixpanel, with their auto-track capabilities. However, Mixpanel won't let you use that data outside of their product, and Heap charges a premium for that capability. To get best in class data capture, you have to pay for data storage and data visualization, whether you want it or not. Sure, Segment makes it easy to put my user analytics data anywhere I need it, but without auto tracking, they fall short of the best in class label. My options were limited, to a single provider, and today we pay for more product than we need.

As we collect more data from more places, its not acceptable for data to live in walled gardens. We need to marry our marketing data with our sales data with our usage data. At the same time, enterprises expect control and ownership of their data. They are building Business Intelligence teams that require sophisticated data warehouses that offer flexibility in how the data can be used.

Unfortunately, buyers have to choose between enterprise grade business intelligence (Segment to Redshift, in my opinion), or effortless usage data from our web apps (Heap or Mixpanel for their auto track features). Why can't we have both, without pay for things we don't need?

2. Little value comes out of the box

In the early days of the internet, web analytics solutions offered out of the box value. Once the tracking code was dropped onto a site, web analytics tools like Google Analytics and Webtrends would tell you a whole lot about your users...no other effort required. No writing queries, no building reports, no curation of dashboards. Just login and immediately view how many visitors you had last week, which pages were popular, where your users came from and what type of device they were using.

Unfortunately, that level of data isn't good enough anymore. I need to know which form was filled out the most, what selection from my dropdown menus resulted in the most exports images, which sequence of steps result in the most purchases, and which of my sales reps have the most customers interacting with the new feature we launched in beta.

To get any of that, most user analytics solutions require the user has to put in significant effort. Start from scratch...literally a blank page. Learn a data structure and definitions. Learn a query language/system, then start creating charts, graphs, tables, and dashboards. This may sound easy, but you are looking at many, many hours of effort, only to get data you may not fully understand and may not even be correct.

The other day, I had to contact the customer support team of an analytics product I use, to get help on how to count the number of unique users my app had. With all my experience using, buying, implementing, and building analytics products...I had to contact support to get help with the most simple, fundamental of queries.

It doesn't have to be this way. It wasn't this way with early web analytics, and its not this way with software performance analytics. When I log into New Relic, I am immediately presented with data that provides value, answers questions, and leads me down a rabbit hole. Yet, when I engage with user analytics tools....I'm starting from nothing. This pain isn't isolated to getting started. Even once I've spent hours.....days setting up dashboards, reports, graphs, and charts, I'll still have to start from scratch at other times. Build a new feature? Start writing more quires to know how that feature is used! Want to know something different about your app? Get working on a new dashboard!

Nothing comes for free with user analytics. We have powerful access to data, but the data is meaningless without a significant investment to use that data. Why can't user analytics be more like New Relic software performance monitoring?

3. Users must know what they need to know

I find most user analytics tools to be incredibly limiting in the value they provide. The benefits are in theory unlimited, yet to reach much of that value, the user has to know what they need or want to know. With the amount of data we collect these days, and the rate at which our data collection grows, I believe there is significantly more value hidden in the data, and we don't even know how to extract it.

As discussed earlier, most use analytics tools require the user to write queries, create charts and graphs, and build dashboards. We do this with what we know. We know we want to see a count of user. I know I want to see what percentage of my total user base was active in the last month, I want to see which pages are the most popular, which option from the drop down menu was the most popular, and what percentage of people drop off at each of step of my ideal user flow through the product.

What if users forged their own path through my product, defying the path I thought they would take, and the path I created my reporting around? How would I know? How would I measure and see the impact? I likely wouldn't know. Something in the data would have to peek my interest and drive me to discover this funnel of user behavior, before updating my dashboard to capture my new learning.

How many more insights like this might be hidden in my user analytics data? I'm guessing there is a virtually unlimited number of observations that can be made on user analytics data, and through the noise is likely signal that we are missing, because we didn't know to look for it. I want the user analytics solution of tomorrow to tell me what I should know, instead of waiting on me to ask the question.

User analytics products aren't perfect, but they aren't all bad either. I'm a new user of Heap Analytics, and I'm really enjoying the product they have built...their auto track + retroactive data capture saved by butt the other day! Mixpanel offers a fantastic product, and is the best solution for funnel and cohort analysis on web or mobile apps. Google Analytics was a game changer and one of the best things that has happened to content producers.

What do you think, how do web and user analytics tools need to evolve in order to provide value tomorrow? Let me know on Twitter or comment where you were linked to this post.

More on Product Management (Part 2)

July 03, 2017 by Jeff Martens in business

Recently, I published a post that outlined 9 principles that make for great product management (On Product Management; May 23rd, 2017). I enjoyed writing the post as it was helpful for me to get my beliefs in a single place, and I was lucky to attract a great audience. My readers had some valuable thoughts, insightful questions, and astute clarifications via LinkedIn comments, Slack discussion, and direct emails.

In this post, I want to address some of those points of discussion, clarify a few things from my original post, and explore a few more principles that make for great Product Managers.

If you haven't read my original post, take a moment to read it and come back to this one. Finally, thank you to everyone that contributed thoughts, counterpoints, questions, and praise...you've helped me become a better writer, and a better Product Manager!

More on the Product Manager's role with vision & strategy

I started my last post out by saying that the role of a Product Manager is to shepherd through a vision...the vision of a Founder, a CEO, or a Chief Product Officer. I went on to talk about the PM's role as a leader, rallying the team around a vision and strategy, and developing products that serve multiple stakeholders. A couple of my readers pointed out that my message might have contradicted itself, and could be taken as a statement that vision and strategy aren't the role of the Product Manager.

This topic gets at a phrase that is commonly thrown around around Product Management, that being a PM is like being the CEO of a Product. I like this statement because it alludes to the type of work that a PM does, and the level of leadership they must demonstrate. I dislike this statement because it implies that the PM is ultimately in charge, that they can do what they want and have no equal in the organization.

While I absolutely believe that Product Managers should influence and contribute to company vision and strategy, and they should set a vision and strategy for their area of responsibility, the truth is that most of us work as part of a larger organization. Most of us have a boss, have a leader we work with. Many of us work at the companies we do because we were attracted to the mission and vision that their leadership put in place. If the Product Manager is setting company vision and strategy, rather than the C-suite, there's a problem. Similarly, if a Product Manager isn't helping the C-suite refine, build on, and advance the vision, there's also a problem.

Effective Product Management orgs report through the CEO

Something I didn't touch on in my earlier post was the placement of Product Management in the org chart. There are a two common reporting structures for Product Management: Through the CEO or through the CTO. While both can work, I believe the best results come from Product Management organizations that report through the CEO.

This preference of mine stems from the idea that Product Management is about more than engineering. Engineering groups are singularly focused on technology, whether its the technology that customers interact with directly, or the backend and foundations that the product is built on. Conversely, Product Management is cross-functional by nature, working across pricing, customer support, sales, marketing, and more.

While the Office of the CTO can effectively lead Product Management, reporting through the CEO is a better fit. Like Product Management, a CEO's role spans the entire organization, influencing all aspects of delivering a product. Reporting through the CEO avoids potential conflicts of interest, where tough decisions must be made and priorities identified, and more easily allowing for a solution that might not be an engineering one.

Product Management is about more than code

In my last post, I may have ignored a principle which I feel is so important. The product is more than your software. The product is the entire experience that a customer or user has with your company. From how they first learn about your product, to how they are sold to, how they are on-boarded, how they use the product, how they are supported, and even how they are 'off-boarded", so to speak. Its all your product to the customer, they don't put walls between your marketing and your code, or between sales and support.

Effective product managers influence and lead all aspects of the product. They think of things like user documentation as part of the product. They know that interacting with customer support is part of the value being delivered. Sometimes the best way to move a product forward, to move the needle on sales or net promoter score, is to fine tune the non-software aspects of your product. If a Product Manager doesn't take responsibility for a cohesive product experience, its likely no one will and each customer touchpoint will remain silo'd.

Nike doesn't just sell shoes, they sell an identity. Blue Apron doesn't just sell meal kits, they sell time-savings and the joy of cooking. Software companies don't just sell access to code, they sell solutions to problems.

Am I living in a Product Management dreamland?

So am I crazy, or is my view on effective Product Management realistic? Truth is, its both. I have outlined a bit of a dreamland, a perfect world, but not a world that I've experienced at any single company or role I've held. That said, every philosophy that I've outlined is one that I've experienced personally or seen at other organizations. All of these philosophies are reasonable individually, and together they are a rare but special reality.

Some of these principles are ones that we can do on our own, as individuals seeking to be better at our jobs. Some of these principles require the mandate and support of our organizations and our bosses. If you desire more of a strategic and leadership role in your work as a PM, ask yourself two things. First ask if you are doing the things you can do with autonomy to be a more effective and efficient PM. Then, ask yourself if you are working for a company that wants and values leadership in a Product Manager.

This is part 2 of a 2 part series on effective Product Management. If you haven't read part 1, head on over to On Product Management for principles exhibited by great Product Managers.

On Product Management (Part 1)

May 23, 2017 by Jeff Martens in business

Update: Thanks to the huge response from readers, across LinkedIn, Twitter, Slack, and Email, I've written a follow up post to expand on the below thoughts and address reader feedback. You'll find a link to that post at the end of this one.

Recently, I've been asked a few times what my philosophy is on Product Management. I have to say, I've never thought about my philosophy on Product Management before being asked this question. Sure, I have thought about various issues and ideas related to Product Management, but I've never developed a holistic philosophy. As I thought about the question, I started to realize that I do have some solid beliefs, strong feelings, and best practices on this topic.

This blog post represents my personal philosophy on Product Management. It isn't perfect, it may change over time, and it isn't an exhaustive list. What you will get is a look into what I feel strongly about, how I work as a Product Manager, and what I believe leads to great products and thus, great businesses.

Product Managers are the shepherds of a vision

I believe that the fundamental job of a Product Manager is to turn a leader's vision into action. At a certain point, a Founder/CEO is no longer able to be day-to-day with product development. Product Managers exist to ensure that a Founder, a CEO, or a Chief Product Officer's vision is carried out. This is especially important as companies launch additional products or serve multiple use-cases.

Some may say that being a Product Manager is a "mini-CEO" or the "CEO of your product." I get the meaning of that statement, but it goes farther than I'm willing to go with a comparison. Instead, I like to think of myself as a shepherd. I'm overseeing an asset. Leading it to green pasture. Protecting it. Turning it into something more. Delivering.

When I worked at New Relic, the vision was that every Knowledge Worker would one day log into our products on a regular basis to inform their work. Our mission was to be the first, best place for companies to go to when seeking to understand their digital business.

We believed in that mission and worked towards that vision, but it wasn't exactly a roadmap to get there. Thats where Product Managers come in. They chart the course to that end goal, showing a team what they need to do in the short, medium, and long term in order to get to the destination.

Easier said than done, of course. Read on for more.

Product Managers work across a continuum

One thing I love about Product Management is the opportunity it gives me to work on so many different things. One day I am focused on Marketing, another day I am engaging with Customer Support, and most days I'm working directly with engineering. Similarly, Product Management offers the ability to be both strategic and tactical. One minute I'm setting a product vision for three years in the future, the next I'm working with a UX Designer to determine how to reduce friction for users of a single functionality in the product.

I've also found that some Product Managers gravitate towards certain areas of responsibility, while minimizing their efforts in others. This approach in itself isn't bad, but a good Product Manager understands where their time is best spent. I believe a good Product Manager knows when to let other's do what they do best. When to let Designers and Engineers work with freedom, and when to listen to company leadership for strategic direction. I stay out of the weeds and focus my efforts to the right of center on the continuum of tactical and strategic activities.

Product Managers are the voice of the customer

When most people think about Product Management, they probably think about serving customers. When I think about customers as they relate to Product Management, I like to to go a step further. I look at it as my job to represent the customer at every table I'm invited to. It doesn't stop with product features, its my job to ensure that Marketing delivers what the customer needs, that the support infrastructure offers the customer what the require, that the sales process meets customer expectations, and that pricing aligns with the value delivered.

Your product is more than just software. It's the entire experience a customer has with your organization. Don't just represent that customer with your roadmap, it's a Product Manager's job to represent them in every discussion that happens.

Product Management is a partner to Sales

Before I became a Product Manager for the first time, a friend asked me a trick question. He said "As a Product Manager, who do you think your customer is?" Easy question, I thought! The obvious answer is the end user.

My friend suggested I was wrong. He went on to make the case that Salespeople are the customer we serve as Product Managers. While I don't fully adopt this line of thinking (I struggle to think that anyone is more important than the end user), I have carried the spirit of this idea with me in my work.

The argument goes like this: If a Salesperson is excited about my product, educated on its benefits, equipped to sell it, and confident in what it will do for the customer, the Product will succeed. Ultimately, Product Managers are measured on their success of the Product. So, unless you work in an industry with self-serve products, you better have good relationship with the Sales organization.

Personally, I love working with the Sales. I find it to be a great way to get in front of customers, and an efficient way to collect feedback. I'm also a Salesperson at heart, and I love the feeling of winning someone's business!

Product Managers balance stakeholder needs

When I make product decisions, there are three key stakeholders I am thinking about. I'm constantly asking myself: what does my current customer base need from me, what does the industry/market of the future need from me, and what does my company/employer need from me? Rarely will I make a decision where one of these stakeholders is ignored, and never will I make a decision without considering all three of them.

Its obvious to say that the customer's needs are important, and its true. That said, be careful not to ignore customers you don't have yet, the customer of the future. When I meet an existing customer's needs, or the needs of a persona/market that I already serve, I'm likely optimizing for retention and incremental sales. When I think about the industry/market at large, I'm allowing myself to deliver what my existing users would never tell me they need. I'm opening up exponential opportunities, positioning my product to be an industry leader in the future. Finally, looking to my employer as a stakeholder isn't about ensuring I continue to get a paycheck. Rather, I'm looking at company strategy and ensuring that the decisions I make for my product, my user, my future market.

The best decision I can make is the one that serves my existing customer, positions my product to be a market leader in the future, and delivers towards the company strategy.

Product Managers are industry experts

As a Product Manager, I don't know everything and frequently my team is better than me at most things. The one thing I know I can do better than anyone is to be an expert in the industry my product serves. In fact, its my job to be an expert. No one within my organization should know more than me about the market I serve, the users I have, and the problems we solve. The beauty of this is that just about anyone can become an expert, with effort and time. The downside is that it will take time. No one becomes an expert overnight. We either bring it into the job from past experience, or we learn it on the job. Either way, a successful Product Manager is a respected authority on the industry.

Product Managers serve as Leaders & Coaches

Despite the title, often times Product Managers are not managers of people, they aren't the boss. Engineering doesn't report to them, nor does Marketing, Sales, or any other team involved in taking a product to market. Instead, Product Managers are leaders. They use influence to get things done. Effective Product Managers convince people to come along on a journey, working together to ensure success.

Additionally, my job as a Product Manager is also to be a coach. I'm sharing my industry expertise with others, removing obstacles so others can do their best work, and loudly praising the team's success.

Product Managers belong outside the office

There is a program called Pragmatic Marketing and its essentially Product Management school. If you take one of their courses, specifically the Foundations course, you'll likely hear the instructor make a lame but memorable joke. They'll tell you about something called NIHITO ("neh-he-toe"). Its an acronym that stands for Nothing Interesting Happens in the Office. As lame as the instructor will sound when they make that joke, the sentiment couldn't be more true.

Product Managers should spend a majority of their of time out of the building, or at least away from their desks. The more I am sitting at my desk, the less effective I am at my job. Rather, much of my time should be spent talking with customers and engaging with other teams within my organization. This is not to say that 100% of time spent away from your office is equal to 100% effectiveness, but how you split your time is an indicator of effectiveness. You also don't have to literally leave the building to achieve the figurative example...talking with customers in any way, even a simple phone call or studying user metrics qualifies.

If I had to boil it down, my perfect time-split would be this: 1/3 of my time talking with customers, 1/3 of my time working with other teams, and 1/3 of my time synthesizing what I've learned into a strategy, roadmap, and product requirements.

Product Managers are not JIRA Jockeys

You'll notice that in this entire blog post on Product Management, I haven't once mentioned JIRA Tickets or User Stories. There is no question that User Stories are an effective way to communicate product requirements and JIRA is a great tool for organizing and planning product development efforts, However, writing and moving around JIRA tickets is not the best use of a Product Managers time and expertise.

I believe a Product Manager's time is best spent being an industry expert, turning company vision into product strategy, developing a roadmap, making the user persona's and problems clear, removing obstacles so my teammates can do their best, work, and supporting them however else I can. Moving one JIRA ticket above another doesn't equal effectiveness. Ensuring others have everything they need to do great and the right work, that does result in being effective.

I've said a lot about Product Management, but in a way I feel like I've barely scratched the surface. This line of work is one of the most fun, rewarding, yet complicated and ambiguous around.

I'd love to hear your take. Did I get it right? Do you disagree with anything? Did I miss something? Join the conversation with me on Twitter, Facebook, LinkedIn, or wherever you found the link to this post.

For a follow up on this post and my response to comments and feedback, check out part 2: More on product management

Bad product design is everywhere

April 13, 2017 by Jeff Martens in business

I used to not think much about product design. Sure, I thought about the design of shoes, which I love, and even more so when I worked at Nike. I didn't pay much attention to the design of the every day things interact with. That's until I started building software in 2010. The software industry is, rightfully, obsessed with good user experience. They design for it. They do so because technology products are used by so many, especially software. Build once, get used by billions. What a departure from the days of physical products that differed in each region, where users had little visibility into how good things could be.

With technology making so many more products available to us, and with smart companies showing us what good user experiences can look like, its easier to notice when bad product design happens. Turns out, poorly designed products are everywhere! These days, I quickly notice when products put a button in an inconvenient place, when the visual they want me to see is covered up, or when there is an unnecessary step or barrier that prevents me from completing the task I want to complete, in a timely fashion.

My favorite example of this is when users are asked to select what type of credit card they are using, followed by the credit card number. You may not know this, but there is absolutely no reason to ask software users to tell the web site what credit card you want to use. Credit cards have standards. Visa cards always start with a 4. American Express will start with a 34 or 37. Mastercard with 51 through 55 or 2221 through 2720. Go ahead, check our cards, I'll wait.

See, its a totally unnecessary step, yet just about every web site you purchase from will require you to do it (there are some good ones that don't, thank you). Why don't we make products easier to use?

Recently, I found another example of poor product design, this time with a physical product. My office has a few coffee makers, just like every other American office. One of them is a fancy coffee + espresso drinks machine. The user experience design on this thing is absolutely terrible!

Coffee machine with a terrible user experience, and my favorite coffee mug

I am guessing you are looking at the above picture, wondering what could possibly be wrong with it. Allow me to explain. There are 3 examples of terrible user experience design in this one product.

First, notice the coffee bean hoppers at the top of the machine. They hold 2 different types of beans, labeled #1 and #2. As most English speakers would expect, #1 is on the left, #2 is on the right. However, there is a 3rd hopper for beans, which my company uses for decaf. Its inside the machine, with no easy external access like #1 and #2. As such, we had to place a label on the front of the machine to let users and servicers know that there is in fact a 3rd option. The lack of uniformity and the hidden option are both failures in product design and user experience.

The second problem comes when its time to brew a cup (lets be honest, thats the worst time for a caffeine junky). Remember, the coffee beans are labeled left to right, one, two, and three. So what happens when you are presented with a menu to selection your option? Have a look for yourself.

Coffee #2 is on the far left, followed by coffee #1 and coffee #3. They couldn't even stay consistent with their inconsistency. The following three options are extra strength #2, followed by extra strength #1, ending with extra strength decaf, instead of calling it extra strength #2.

Our poor user experience doesn't end there, and at this point this shouldn't be any surprise to you. Once the brewing starts, the screen that displays while the user waits for a dark, steaming mug of energy, offers more confusion. My go-to coffee #1 is now referred to as coffee A. You can't make this stuff up.

This list actually goes on from there. This machine has 2 spouts where mugs can be filled from, but for the life of me and my colleagues, we can't figure out how to use the spout on the right. Therefore, don't even try to use the second spout when someone else is waiting for their coffee to finish brewing, you'll just have to wait!

In closing, if you have anything to do with taking a product (or feature) to market, whether you are an engineer, a software developer, product designer, product manager, or anything else, please do right by your users. Take a moment to stop and review your products design. Remember that design isn't just about visuals and color, its about the experience a user has. Ask if you can remove steps, make things easier, or make things faster. Ask a customer, a friend, or a colleague to look at your work and point out any inconsistencies or oddities that you may not have noticed. A little bit of time spent here can have a small impact on the daily life of thousands, millions, or even billions of people.

A big opportunity for Amazon's Alexa powered Echo devices

December 27, 2016 by Jeff Martens in business

Update: On May 9th, 2017, Amazon announced the release of Alexa Calling, their device-to-device communication feature. While the feature appears to allow the equivalent of a phone call from one device owner to another, as I hoped they would do, it does not appear to offer the intercom like functionality I propose below.

The Amazon Echo, and Echo Dot come in white and black, and are powered by Alexa. The larger Echo offers music quality sound.

I love my Amazon Echo. I first bought the device because I wanted a small but good music speaker for my small studio apartment, and I liked the idea that I could play music from my Amazon music library. The Echo solved that need beautifully, and I soon fell in love with Alexa, the voice/AI software that powers Echo. I now also own an Echo Dot for my bathroom, and I use both of my Echo devices to do things like set a morning alarm, hear the news, get the weather, call an Uber, create shopping lists, get live updates on sports scores, assist me when cooking, hear my schedule for the next day, listen to recent tweets, and so, so much more. I believe we are still in the early days of what Echo/Alexa can do, we'll see an exponential addition of capabilities over the next couple of years.

This Christmas, I bought my parents an Echo Dot, and my sister received one for her home as well. I quipped to her that she'll love the Echo Dot so much, she'll soon end up with an Echo device in every major room of her house. I know I'd have more than 2 if I didn't live in a studio apartment!

The thought of my closest family members all having Echo devices, and the idea of my sister having one in each room of her bustling family home gave me an idea. Echo devices could do for voice-based communication what Apple's FaceTime did for video calling. In a world where we have an increasing reliance on text based communication such as SMS (texting) and Email, Amazon has the opportunity to usher in a new age of the telephone with device-to-device communication.

I'd love the ability to call my parents by simply speaking to my Echo and telling Alexa to connect me with them. On the other end, their Echo could tell them that I'd like to talk, and they could command their Echo to answer or take a message. As ridiculous as it sounds, removing the friction of dialing and holding the phone to my ear would lead me to more voice communication with my family, and less texting.

Anyone alive in the 70s, 80s, or 90s will recognize this!

Another device-to-device application is as an instant home intercom system. With Echo devices in each room of my sister's home, she'd have a network of devices that she could use to communicate with her children and husband, no matter where they are in the house. Using her voice to call the kids down from the playroom for dinner, or asking her husband to bring a screwdriver in from the garage, at just $49.99 for the Echo Dot, the Echo family of products could inexpensively and less obtrusively do what so many electronics companies and home builders did in the 80s and 90s with ugly, in-wall intercom systems.

Amazon has a lot of opportunity ahead with Echo/Alexa, and a lot of tough decisions to make about what to/not to build. I'd love to see them add device-to-device voice communication, would you? Like this post and share on social media if you agree!