Lecture 17: How to Build Products Users Love, Part II

Hosain Rahman

Thank you Sam for having me. Sam and I have known each other for a long time. We met in the early days when he was on his company journey. He asked me to talk today about the hardware journey of building products. I want to give you guys a little bit of an overview of Jawbone: what we do, how we think about the world, and how that informs how we build products. I'll then go into the process of how we design, how we develop, and how that all comes together through what we do to change categories.

I always like to start with the broadest thinking. The way we look at the world is we think of ourselves at this intersection of really crafted innovation in engineering that's almost invisible to the user in terms of its functionality, even beyond design. We have been designing products for well over a decade now. We think that the conversation has shifted even beyond design into beauty. It's the intersection of engineering meets beauty. The whole point is to help people have a better life with technology.

Largely speaking we play in this world of "The Internet of Things." We were there before there was such a moniker. We have smart devices that have computing power and connectivity with sensors that are measuring all kinds of things. They're wirelessly connected and they're all talking to you. We started on this journey really, really early. Right out of engineering school here, we were developing core technology. We decided to build consumer products around that.

Our first consumer product was the headset. We created a headset that became a wearable computer. It was the first traveling headset. That was when we started thinking about wearable computing. We then invented the wireless speaker space around Bluetooth and audio. I will talk a little about that journey. Most recently, we focused our attention on the wearable health revolution and using a lot of the sensors that we did in the first generation of headsets and applying them to other parts of the body to understand more about users.

Our view of this world, having been here for a long time, is that it is a little bit of a mess. In the internet of things everything is smart, connected, and has an app built for it, but that doesn't mean that it is easy for users. Your microwave, your refrigerator, your car, your Xbox, your Xfinity Comcast, everything has an app. They don't talk to each other. It's really confusing for the user. We think that there is a desperate need for an organizing principal around all of this. This is the core of when we start to think about how we build and opportunities to create products. We think about where the world is going. If there is going to be such a world that everyone's talking about on the internet of things which is happening, you desperately need these organizing principals so that it's easier for users to understand how to come in and interact with these services. So we think that is the shift from less about the actual things to being about the individual user.

When everyone is talking about wearables and you have things like Google Glass and Apple Watch, ultimately what we believe is that when you have things that are on your body 24/7, they become a perfect context engine for everything in the world around you. My phone is not on me. It’s in my jacket or sometimes on the charger. But my Up is on me. And it understands everything that is happening when it's tracking my heart rate. It's tracking my respiration. It's tracking all these different things. When I say context engine, I can tell the smart thermostat, my Nest, that I am hot or cold. That device doesn't have that understanding. I can tell it I am hot but that device doesn't know if I'm hot because I'm sick, I went for a run, or if it's hot outside. I can tell your car that you're falling asleep, agitated, or irritated. This is ultimately where we think the world is moving. Wearables are going to be the center of this revelation around everything being connected and smart. We are going to drive what a lot of those interactions are going to be and how they’re going to work. That's the first principal that we think about. Where are things going? What should we build and how should we think about new categories.

In order for this vision to happen, you actually need to be great at almost everything. We need to be great at what we call the full stack. We have to be amazing at building hardware. These are hardware experiences that people have to keep on all the time. You have to wear them 24/7 because if you don't, then everything that I am talking about is a castle in the air. You can't actually create a service that people engage with or that gets lots of data that can then go power all these other things if it doesn't start with great hardware. So that's where we start, we try to build these magical experiences in hardware that are powered by software. We have developed world class software application expertise. We have to be good there, from an engagement perspective, like an Instagram or WhatsApp.

On the data side we have to know what to do with this massive amount of information. We have to know how to process it, push it, and have it work for the user. We really see ourselves at the intersection of hardware, software, and data. These are three equal stools that have to work together in order to unlock that experience around something that is on you, that knows what's happening and then talks to the rest of world. That's a key piece of what we do. It's different than what a lot of other companies doing. It allows and requires to play at all levels of stack.

This was a complicated thing for us to put together because typically people who are great at hardware understand mechanical engineering, electrical engineering, and how those things interact. They understand how you build tools at scale. They're not typically great at building software and services. It's a very different discipline and requires a very different skill set. When we first put those pieces together, it created a lot of interesting friction in the company. Our software and application team was so used to moving really, really fast and iterating, whereas in the hardware world you've got to take your time because your iteration cycles are much more deliberate. You have tooling that takes sixteen weeks. You can't just tweak stuff and you can't hack it in the same way. It was interesting to see that when we put all these pieces together, the hardware learned to move faster. The software guys thought more about how they could resolve experiences before they actually shipped it, versus just throwing something out and A/B testing it. Then the data science informs all of that with more information to make decisions.

So how do we think about and how do we build products? How do we change categories? First of all, everything for us is a system. We don't think about it discretely as a piece of hardware or discretely as an application or discretely as a platform. We think across the whole thing. This is an example with Up. We have these tracking sensors on the body out rhythms there it connects to the phone where you have this engaging application service experiences. We use the sensors in the phone. That talks to a lot of stuff we are doing in cloud where we are taking all that information, driving insight on it and then we have a huge platform of thousands of developers - where they're thousands of apps that then plugin and also create more experiences. And so we think about it across the whole spectrum. And I, I'll come back to this system think in, in a second.

What does the actual process of creation look like? This is fun for me because we don't actually talk about this very often. We keep it confidential and private and I know that we're on a live cast. It's fun for me to talk about this for the first time. It's a quite deliberate process. This is a little bit of what it looks like. This is a map where we are much unbridled in our imagination in the exploration phase. We start to validate some of our concepts, bring those ideas tighter, and tighten them. And then we actually start to build a product. Launch it and then iterate. That's the simplest way to look at it. I'll take you through each of these steps.

The exploration phase is very wild. It's imaginative. We think about the vision of where the world is going and what our strategy is. What does the brand stand for? You're dreaming. You're imagining it. How do I disrupt? What's the future going to look like? It is a little bit of a science project and we talk about it in that way. We build from inspiration, insight, and raw creativity. We want to create and we try to create a form where that's ok because a lot of times in companies that gets lost. Then we we start to bring in early validation, where I say, " Look everyone, when you're doing this stuff, you have to now take those concepts and prove them like you do in a PhD Thesis." You have your conclusions, you've done your empirical data collection, and you start to say here's where we see it going. Here's what's its going to do. You outline the story.

Once we sign off on that phase, we start to go into a concerting phase. Where we start to really think about the experience and what's possible. This is another interesting opportunity for innovation at a more specific level. How will this come to life and how will we sell that experience? How will we tell that story? Then we decide its program. It goes into a heavy planning phase where we say, "Ok. We're doing this. We've got to ship it. There is no turning back." What are the tradeoffs between all the creativity and all the ideas we want versus what the physics dictates? What are all the different constraints that we have? We start making tradeoffs and we look at how to pull that together.

Then we move into a development phase. It's a hand off between various stages and very functional teams in the company. You pull together and you're solving problems as you implement and launch it. You learn. You see what users think. You start to think about where does this stand in that experience continuum that you've been imaging where the world is going to go. What have we achieved? What haven't we achieved? What have we learned from our users? How does that change what we're thinking? And then we start right over again.

That's the broadest way to think about it. The exploration phase is very much like a building and tinkering process. A lot of it is driven by demo Fridays where people have an opportunity to showcase their work. We find that's a great way to pull it together, pull it into a form where others can consume it and give feedback. It's a really it is a show and tell. Obviously hack-a-thons are a big part of it. There's lots of data that gets driven. It's lead by our Strategic Development Team, which is traditionally called an R&D Team. There is participation from product and engineering, both hardware and software. But they're sort of taking a back seat and they're looking at what these explorations are. The Executives at the company at this phase are more of a signing board. They’re there to poke and prod and tell people, “Hey think about this." Or "Did you try that? How does that work?"

In this phase, in order to move to the next threshold, we think, "Would I give this guy 50 grand?" It's like an angel investment. Would I give this guy 50 grand to go explore this and see if there's is there something to do? And our CTO is the final decision maker. He gets to pick internally and say, "You know what? I like all the feedback. This is the one I want to go chase down and see what happens."

Then we get into the validation phase. This where gets really interesting. It's still led by R&D but they're really poking at the idea and saying, “How does this work? We have leadership meetings with the broader cross functional team. I have to show results. I have to go through a scientific process to outline why this works. Why is it going to happen?" This is when we start formulating an important tool in the company, which is what we call WHYS. Defining the WHY of what we are doing. WHY does this exist? What problem does it solve? I'm going to come back to that in a minute.

At this point it's still an R&D lead, but this is when our industrial design team and a few project guys come in and think, "Ok how can I pull this concept into something physical, if it's hardware? How is that going to interact with the rest of the pieces of the system?" Our product experience team is still driving a lot of the core values and the story boarding, but it starts to become a lot more real, when we start thinking, "Ok, how we will build this? How expensive is this going to be? What's the budget going to be?" At that point, we start to really validate if we can actually build it. Do we have wait three years for batteries to be there? Do we have to wait for this other innovation to happen? Do we have to wait from a budget perspective? Is there a business viability? Then we start to really sketch briefs. This where I come in and make the final decision. "There’s really a there there. And we can now take this to the next level and get into play."

Then we go into the concept phase. This is when the responsibilities shift from the R&D folks to what we call the product experience team. The way we think about product experience at Jawbone is what everyone thinks of as conventional design. So from industrial design to software design to audio design to anything that touches that experience. We have writers on that team. Story tellers. We have ID people like Eve who are Genius creators. We have amazing app level designers, graphic designers, everything. It's all one team and we call that product experience. Their job is to unify us as one organization. That's when they take hold and start to really drive the WHYS. They think about what's possible. There's a lot of innovation and creativity in the actual implementation of how we're going to build and create a product. We start to say what the most important things in that product are. What are the most important problems we're going to solve? We call them "Hero Experiences." What are we going to do? What is the bar that would be acceptable?

At this point we start to really resolve the WHYS, which I will show you again in a minute. Why is this different from the competition? From the category? Where does it go? We don't like to do one off things. We have to see a broader vision. This is part of the creation experience. We look at where do we think the world is moving and think about how this is going to be a stepping stone to that ultimate end vision. That’s where the road map starts to get flushed out. Again, I have the ability here to be the final decision maker with my team and say, "Yup. We're going to move this to this next phase."

Here is also where we look at some of these things. I want to get into some specific examples. We have fast track programs. We took, for example, the Jambox when we were in this phase and we said, “We’re not going to go through another phase. We're going straight into the development process because we want to get this thing out. We want to test it, market it, and move really quickly." So we have the ability to prevent our own process and say let's fast track it. We can recalibrate the go to market possibility.

After this stage it shifts from that Product Experience Team to our Product Managers, who are really defining the business plan. When is it going to launch, when is it going to get into the retail calendar, what is the software release cycle. They are prototyping. They're starting to make a lot of those tradeoffs. "Ok we wanted to build this. We can't do that but here's what we can do. We want to be this way. We want these functional experiences. We are going to sacrifice battery life, whatever it is." That's when we start to really pull those decisions and start to look at it. It's a big juggling act at that point.

The product guys are driving that. That's when again, we look at and synthesize all of what we put together and we say, "Ok. Does it actually cross enough things off our list? Does it meet that minimum viability?" Because we always start with, as you can tell, this very big wish list of what's possible and what we can do. Then we start to wheel it down and ask, "Does this cross enough of the value threshold that we think it's worth pursuing?"

Now can we actually move it into the development phase where again Product Management Team continues to lead it. But now you're starting to really get deep. This is where engineering comes in and is really starting to sign off on building it. Here's the time schedule and how we ship. The Product Team is looking at how we should go deeper. How can we increase engagement? What are the little innovations? What are the tuning? What are the things that we need to do to make all that happen?

We've been fortunate to have a lot of wonderful response to products that we've built. We take a lot of care and time in the details of this development and concerting phase, around little details that create these magical experiences. For example, when you turn on Jambox, you have this pretty cool sound that goes "WOOO." It took months to come up with the right audio tuning. We worked with a lot of different audiographers to create that sound, but every time someone turns it on I see them smile and laugh.

The feel of the rubber retyping: there's one manufacturer in the world that was able to make the rubber at the quality that we wanted and the colors that we wanted for the first Jambox. All of those little magical details. How do you resolve them, even in software? When we had the first UP, when you plugged it in your sleep graph showed up. Even just the animations of how the bars would show up and the way cards would flow, that was a detail that we thought about. How is this going interact, how is the user going to experience it? How are they going to feel it? A lot of that stuff happens even at the stage where you sign off on a program. You're making those kind of decisions all the way through and you're trading off and you're doing it in the context of this bigger picture. Innovation is an opportunity to keep refining and to keep doing all that stuff.

How do we think about it at a broader level? What is the framework for how we think about these user signature experiences? Well we start to think of these WHYS. Which is an articulation of the problem that we are solving. And then the themes around how these become actionable concepts. Then we build these cross functional pods that take a person from the Product Experience Team, a person from Hardware Engineering, a person from Software Engineering, a person from the Data Team, and we put them together. This is the pod that owns that theme or that track and they continue to build that out against the hero features and the inside features.

I am now going to go into more specifics around the WHYS because this is where I spend a lot of my time. Where we are asking a question. It serves as a really interesting framework for us to be able to come back and say "Hey. Did we meet those questions that we asked? Does this thing actually do it?" It also serves as a really good guide post for a lot our creativity and a lot of our innovation so it’s not unbridled. It comes down to a very simple question for us: "What is the user problem that we solve through this experiment?" Whether it's in hardware, software, data, platform, whatever it is, once we solve it, people can't live without it. They may have an absolutely burring need to solve this problem and they can't. Either they are looking for a solution or you never thought you needed it but now you can't live without it. Again, Jambox is great example of that. We talked to some people when were were thinking about making that product.

A little story for you guys, when we launched the Jambox in the fall of 2010, the market for wireless speakers as an overall speaker market was zero percent. Zero percent. Last Christmas, which was Christmas of 2013, it was 78% of the market. In a few years we transformed an industry that has been around since the 50's and 60's, we turned it on its head. If I had gone out and asked a bunch of people, "Who wants a $199.00 speaker for your mobile phone?" I guarantee you 0% of those people would have said, "I want that thing. I need it and I would be willing to pay for it." But when we did it, it transformed an industry. So this is where these WHYS become super important. Focus in on what you're doing. I'll go through one example in the audio space, which is the Jambox example, and then I'll take you through a little bit of how we did it in UP. Particularly UP24. It starts with what we call category strategy. This is the experience framework.

Our view was that all your content and media experiences are now in your phone. They are no longer in iPads, iPods, or your computer. So we need a different way to interact with it that needs to be as portable on mobile, as high quality. That was our fundamental thinking. Then we said that that experience needs to be seamless across time and space. So you could go anywhere through it, in a different car, traveling, or around the house. That was fundamentally what we were doing. We said that’s why this category should exist. That was the human problem.

Then we said, what's in it for Jawbone? Why should we do this? When you think about the broader macro context, the internet of things, this was our entry into your home. This is why everybody talks about all these things in your house from lights to thermostats to fridges to anything that is connected media is still the killer app that's in your house. It's where we sell millions and millions of units. So we said speakers can be our entry into that world that's around you and it can be thumb of the things that we want to do from a software and service perspective in your home. There's an interesting strategy for solving user problems but then why does it matter to Jawbone. Those two have to go together because A) we're not a philanthropic not-for profit-industry and B) if you do this well, it allows you to keep making great products, to keep moving forward, and to keep doing interesting things. That's how we put that together.

Then we built what we call the experience conium. Is where it is today? And when we started it was a Blue Tooth speaker. Right? That was the core enabling technology that it allows us to connect to stuff. Where do we think it's going to go tomorrow? What happens when we can dream in future? We start to really try to live into tomorrow and the future and sort of the thing that we built today as a gradual - stepping stone to graduate users starting one place continue to move - continue to move through that. That gives us a view of how we also make these tradeoffs. Because we said we're not going to put this into this product but we have a space for it in the next one. We know that we can move users to that and they will be ready for it. That’s a lot of where we build stuff is we sort of define that experience contain.

We talk about this a lot. We don't think of ourselves as a hardware team or a software team or a data company. We think of ourselves as an experiences company. It's not just about this physical device or that feature. It's about the system. It's about how the pieces come together. So when we start to define these WHYS, they become the problem statement. We say, "Ok how do we use a piece of hardware? How do we use a service in the cloud? How do we use an application? A sound? A button? How do we solve this user experience problem that we have and what’s the right distribution across that system? Where should you attack the problem? Where do we need to innovate and where do we need to pull it together" That's a big, big, big part of the thinking that helps us in doing.

When we think about these experiences, it's really about the context of why it's magical to the user. Like I said, the system is a flagship and then it has to go to a level of emotional connection where you feel that without it you're lost. I am going to go home and get it if I don't have it. Those are the principals that govern all these things. We have to keep asking ourselves those questions. Is it doing that? We pull this all together to create an experience framework. This is essentially a brief for your engineering team. for your design team, and they can go back and say, "What are we doing and why are we doing it? How does that work? How do we create it?"

And then we have a whole process, Blueberry is one of the internal code names. But the user experience process starts with a better resource, so we do actually listen to users and talk to them. But we talk to them in a very specific way, we start looking for those key insights. We concept them and then we start to build. This is why we go to find those lists of consumer problems. The principles, how do we think about approaching that? What are the solutions?And then what's required in the product to make that happen. Sam?

Sam Altman: Could, could you talk about how you balance the fact that a user would never, told you they wanted to pay $200 for a wireless speaker.

Hosain Rahman: Yeah. With user research in front of this process. There's a lot of layers to user research. That's a great question. You guys probably aren't familiar enough with this yet, but there are standard tools for what people do in focus grouping, where they say, "Would you try this, would you pay this, do you want this feature, what do you care about." That's one way to do it. We don't usually get really great answers. We ask different kinds of questions. We say, "How much music do you listen to when you are with other people? How do you play that music? Do you listen to a headphones, or do you listen over the speakers on your phone? How often are you with other people? How often do you want a personalized experience? How often do you want to share? How often do you?"

We ask a lot of questions. We just ask different ones. We don't ask them specific things about, do you want this or do you want that. We ask them: how do they behave? How do they live? A great example is the iPod. If you said to somebody, "If you could put a thousand songs in your pocket and take them anywhere," that's cool. Not, "Do you want a digital portable music player?"

Again it's at a price that was more than your phone. So you have to separate what are questions that you can ask that are going to help make you smarter about your thesis versus trying to get somebody to validate it for you. That's the real separation. No one's going to tell you what to build, if they do then they should do it and not you. You're the one who's making that decision, you've got the thesis, you've got the creative idea, you've got the innovation. You gotta use these people to help you make it better and to refine your thinking. That's the difference. Make sense?

I'm going to switch over to Up24, which is the product that we've had on the market, our wireless products for health tracking. The WHYS of Up24 are really simple. First of all, let me start with the WHYS for Up. The idea there was there's so much that we know about the world today, through Twitter, Facebook, social media, access to the internet, Google, etc, but we know nothing about ourselves. We have no idea why some days I sleep eight hours and feel terrible, but some days I sleep three and feel awesome.

Our thought was: could we take a lot of this sensor technology, help people understand more about themselves, and start to then make better decisions about how they live better? That was the first product. This was the second product we said: okay, great, now that we have wireless connectivity, it's not just about Bluetooth or wireless, it's about the fact that I can use that real time flow of information to understand what's happening with me and take action on it. I can get the data in a more meaningful, relevant, contextually important way at the moment that it matters. I can also get back guidance in a structured way that can help me go do things. I want that ongoing encouragement, because everybody knows that they want to be better, but they fall down. They want a fluid way to interact with this.

This is what we're building in Up24. We had this very crisp set of five things that were the WHYS of why we're building this product and why we're doing it. Our point of view was that it was going to, we had this sort of fundamental narrative going back to the experience framework where we said everything we do in UP is about helping people track and understand them, track themselves, was understand, which is taking all that data and converting it into knowledge.

The third part was act, so track, understand, and act. That is our narrative for everything we do in the wearable health space and it will be for the entirety of what we do. It's help people get more information on results. Data is great, understanding is better. Convert that into things that they can create real knowledge that they can then take action on. Anything that we can do to keep the device on, get more information, help them be engaged and then find ways of guiding that behavior was really, really interesting and is the framework for the system.

Then you can start to think about designs how you build your data infrastructure, your insight system, how you process it, how you build the application experience that surfaces it. This is a little bit more of a blowout around track, understand and act. This is the tracking part, which is really fundamentally about the hardware too. It's how do you design the batteries? How do you design the embedded systems and materials? The way it latches on you, how easy is it? So that you create the habit of keeping it on your body. Then you have to take all that data, it's not just visualization of information. If I told you guys' your heart rate was 75, is that good or bad? Who knows the answer to that question? I don't. It depends on what you're doing and who you are and what's happening. Just the data surfacing is not enough. You have to contextualize why that matters, turn it into action. That's the third part. Action is the key. Let me understand the data. Let me understand that when I work out at four o'clock, I get four more hours of deep sleep at night. That's awesome. Let me get a reminder at four o'clock to go work out. That's what we've built. That's a lot of infrastructure to create that experience. That's how we build software. That's how we build hardware. That's how we build sort of the whole system.

Often, we will talk about different kinds of users and what they care about and what we think our userbase is made of. Who's more into weight loss, who wants the social acceptance, who are people who are vain, that just want to look better. There's lots of different things. There are people who have medical reasons for the use of our product. We design different kinds of experiences. We think about using platforms like phones and ways to push notifications as part of the system. We think of notifications as a tool for behavior change. We actually start to go map out these things. What is a smart action? Is it real time, does it feel customizable, does it feel progressive, does it help me, is it really tailored to me? For this particular type of user, we'd go out and storyboard. These storyboards go to our design engineering teams. We work together and they actually start to build off of this. What this does for us is it creates a nice set of constraints. My experience has been constraints are really great because they serve as opportunities to resolve, to refine, to simplify, and push you to find the right answer that will solve the user problem in the simplest way.

We create a lot of those constraints around what we're doing. This is the storyboarding for getting someone to the goal and how they do it and what we use, in real time. Then we put in the secondary experiences, which is if we can do this and we can fit it in, if it's not too cluttered or confusing we'll put it in. That's a little bit of a snapshot into how we build and we've few minutes left so I'd love to answer any questions.

Audience Member 1: So let's say you have a product. You have all these features that you want to create. You're about to enter to the design process. How do you approach the whole problem? How do you break down how it is going to solve the problem? But then, each design feature is not mutually exclusive. How do you approach it holistically? When you have a number of different features and functions that you are trying to build, how do you look at them on a system level rather than in a silo to understand what the tradeoffs are across the entire system?

Hosain Rahman: That's the answer to your question. You do exactly that. You don't think about it in a silo. When it’s a small team, it's really easy because you all are sitting around the table. You're looking at each other. You are making those decisions in real time. As you get bigger, in larger companies, you have to force communication where everyone is in a room and a person says, "If you build it, if you were to constrain me in this way, I can't get the quality spec that you need me to make." And another guy is going to say, "Well if you do that then I can't fit all of the rhythms in at the battery performance that you want."

When you look across the system, everyone has to share what their pains are so you actually understand, "If I make this trade off, it's going to affect me over here." You have to put everyone in a room and start hashing that out. That's what’s on the board and on the walls on everywhere, that's what are we trying to do. Does that trade off still meet it across right across all those, all those different cylos. Because everyone is thinking about the trade off in their bend. They know what they need to accomplish. But again how does that affect the whole, whole thing. We just went through this with UP3 - which is a product we are shipping in a couple of weeks that sort of define the next wave of what happening in the wearable space on the health tracking side. We invented a totally new sensing system. Right? There was RAW science that had been developed that `we productive really fast and even just trade off on what the electro materials were. How it affect so n reliability. Source sing. You know, signal performance. And just - these guys weren't talking their way to get in a room. Do daily calls for three hours where they are going through each of their thing. It's tedious. But we're figuring out and we're knock it down. So it, its - when you're small it's real easy you just draw and look at it. But you have to always have that definition of what you trying to do across the system. That's why a lot of what I was talking about was a much higher level. What problem we're solving. Where does it go? And how all of these pieces are formed.

Audience Member 2: Should we start focusing on one small thing or should it focus on the system itself?

Hosain Rahman: A system is a mindset. It's not actually a system. There are simple systems. There are complex ones. A plane is a very complex system. A car is a very complex system. There are other products we make that are much simpler. A phone is a complex system. An application you should think of as a system. Storage. The front end experience. What you're doing is connecting. That’s all a system. So that’s more what of what I mean about systems. For us, a system is hardware, software, and data but I think within anything there's always a system. It’s more just thinking about how the tradeoffs work across all the different pieces that work together.

Audience Member #3: What’s the decision making process between making unrelated products and saving space for fitness tracking, for different versions of or Jambox. What goes into that?

Hosain Rahman: We have a grand unified theory about how these experiences come together. What happens, it touches a little bit on the context engine, when you have things on your body that can make everything in the world around you smarter. If I know the emotional state of a user, I can tell Spotify what song it should play on the Jambox. I can tell the TV that you didn't like that commercial and they should fast forward to the next one. Or I can tell you to not watch Game of Thrones on a Sunday night because you don't sleep well.

I'm serious. These pieces go together. We do think at that level. We start to say, "What are the building blocks to get there? And how do we establish credibility? How do we establish a distributing system? How do we establish manufacturing scale? How do these pieces come together?"