Lecture 17 - How to Design Hardware Products (Hosain Rahman)

Very exciting, and thank you, Sam, for having me. Sam and I have known each other for a long time because we were fellow Sequoia companies and we met in the early days of when he was on his company journey, and so it was cool. So what he asked me to talk about today was a little bit about sort of the hardware journey of building products. And so what I wanted to do is give you guys a little bit of an overview of the job on what we do, how we think about the world, and that informs how we build products, and then go specifically into the process of how we design, how we develop, and how that all kind of comes together, and sort of what we do to change categories. So first off, I always like to start with sort of the broadest thinking, and 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. And that's at the intersection of even beyond design. We've been doing design products for, you know, well over a decade now. We think of it as going, the conversation has shifted even beyond design into beauty. And it's that intersection of engineering meets beauty, and the whole point is to help people with a better life with technology. And largely speaking, we do play in this world of what everyone's talking about now is the Internet of Things. We were there much longer before there was such a moniker. And the way we think about that is it's smart devices that have computing power and connectivity with sensors in them that are measuring all kinds of things. They're wirelessly connected, and they're all talking to you. And we started on this journey really, really early, right actually out of engineering school here, and we were developing core technology. We decided to build consumer products around that. Our first consumer product was a headset. We sort of created a headset that became a wearable computer. It was the first job on a headset. That was when we started thinking about wearable computing. We then invented the wireless speaker space around Bluetooth audio, and I'll talk a little bit about that journey. And then most recently, we focused our attention on sort of this whole 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. So our view of this world, having been here for a long time, is that it's a little bit of a mess in the Internet of Things. Everything in the world is smart and connected, and everything has an app built to it that doesn't mean that it's easy for users, right? Your microwave, your refrigerator, your car, your Xbox, your Xfinity Comcast, everything has an app. It doesn't talk to each other. It's really confusing for the user. So we think that there's a desperate need for an organizing principle around all of this. And this is sort of the core of when we start to think about how we build and opportunities to sort of create products. We think about where is the world going. And so if there is going to be such a world that everyone's talking about around the Internet of Things, which is happening, you do desperately need these organizing principles so that it's easier for users to understand how to come in and interact with these services. So we think the thinking needs to shift from being less about the actual things to being about the individual user. And so ultimately, when everyone's talking about wearables and you have things like Google Glass and you have the stuff that we do and Apple Watch and all this stuff, ultimately what we believe is that when you have things that are on your body 24-7, they become this kind of perfect context engine for everything in the world around you, right? So my phone is not on me. It's in my jacket or sometimes on the charger. But my app is on me. And it understands everything that's happening with me. It's tracking my heart rate. It's tracking my respiration. It's tracking all these different things. And when I say context engine, I know I can tell the smart thermostat in my nest that I'm hot or cold. That device doesn't have that understanding. I can tell it's hot. That device, I'm hot because I'm sick. I went for a run. It's hot outside. I can tell your car that you're falling asleep, that you're agitated or irritated. So this is ultimately where we think the world is moving is that wearables are going to be the center of this revolution around everything being connected and smart. And they're going to drive what a lot of those interactions are going to be and how they're going to work, right? And so that's sort of the first principle that we think about when we start to think about, OK, where are things going and what should we build and how do we think about new categories, right? So in order for the vision of what we're talking about 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. And these are hardware experiences that people have to keep on all the time, right? You have to wear them 24-7 because if you don't, then everything that I'm talking about is sort of a castle in the air, right? You can't actually create a service that people engage with or get lots of data off it to 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 absolutely powered by software. We have developed world-class software application expertise. We've got to be as good there from an engagement perspective as something like an Instagram or WhatsApp. And then on the data side, we've got to know what to do with this massive amount of information and process it and push it and have it work for the user. So we really see ourselves as being at the intersection for the first time of a company that's doing hardware, software, and data as three kind of equal stools that have to work together in order to unlock that experience around something that's on you, knowing what's happening, and then talking to the rest of the world around you. So that's a pretty key piece of what we do. I think it's different than what a lot of other companies do. And it allows us and requires us 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, how those things interact, how you build at scale, how you build tools, et cetera. They're not typically great at building software and services. It's a very different discipline, a very different skill set. So when we first put those pieces together, that created a lot of really 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 16 weeks. You can't just tweak stuff, and you can't hack it in the same way. And so what was interesting to see as we put all these pieces together, the hardware team learning to move faster, the software guys thinking more about how do they resolve experiences before you actually have to ship it, versus just throwing something out and A, B testing it. And then the data science informs all of that with more information to make different kinds of decisions. So how do we think about, how do we go, 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 discreetly just as a piece of hardware, discreetly as an application, or discreetly as a platform. We think about it across the whole thing. And so this is an example with Up, where we have these tracking sensors on the body, algorithms there. It connects to the phone where you have this engaging application and service experience. We use the sensors in the phone. That talks to a lot of stuff that we're doing in the cloud where we're taking all that information, driving insight on it. And then we have a huge platform of thousands of developers where they have thousands of apps that then plug in and also create more experiences. And so we think about it across the whole spectrum. And I'll come back to this system think in a second. So what does the actual process of creation look like? And this is fun for me because we don't actually talk about this very often. It's quite, you know, sort of we keep it confidential and private and I know that we are talking now that we're on sort of a live cast everywhere. So it's fun for me to talk about this for the first time because it's not, it's quite a deliberate process, right? And this is a little bit of what it looks like. And this is kind of a map where we are very unbridled in our imagination in the exploration phase. We start to validate some of our concepts, bring those ideas tighter and tighter and then we actually start to build a product, launch it, and then iterate, right? That's the simplest way to look at it. I'll take you through each of these steps. So in the exploration phase, it is very wild. It's imaginative. We think about the vision of where the world's going, what our strategy is, what does the brand stand for. And we think of a lot of what you guys do here. You're dreaming, you're imagining it, how do you disrupt, what's the future going to look like, right? It is a little bit science projecty sometimes and we talk about it in that way, right? And we do build from inspiration and insight and that, and it's sort of raw creativity and we want to create, we try to create a form where that's okay because a lot of times in companies that gets lost. And then when we start bringing it to early validation, I always say like, look, everyone, when you're doing this stuff, you have to now take those concepts and prove them a little bit like you do a PhD thesis, right? Where you have your conclusions, you've done your, you know, empirical data collection and you start to say, hey, look, here's where we see it going, here's what it's going to do, right? And you outline the story. And then once we've sort of signed off on that phase that we think, okay, you know what? This theory is right. We start to go into a concepting phase where we start to really think about what is the experience and what's possible. And this is another interesting opportunity for innovation at a more specific level of how this thing will come to life or what it is and how will we sell that experience and how would we tell that story? And then we decide that it's a program and it goes into a heavy planning phase where we start to look at it and say, okay, we're doing this, we've got to ship it, there is no turning back, right? What are the trade-offs between all the creativity and all the ideas we want versus what does the physics dictate? What do, you know, battery power or all the different constraints that we have and start making those trade-offs and start to look at, you know, how do we pull that together? And then we move into a development phase where it's a handoff between various stages and really various functional teams in the company and you pull it together and you're solving problems as you go implement this and you launch it and you learn and you see what users think. And then you start to think about where does this stand in that experience continuum that you've been imagining where the world's going to go? What have we achieved? What haven't? What have we learned from our users? How does that change what we're thinking? And then we start right over again, right? So that's the broadest way to think about it. A little bit deeper on the exploration phase, right? So it is very much like a building and tinkering process, right? And a lot of it is driven by what we call demo Fridays where people kind of have an opportunity to go showcase their work because we find that that's a great way to pull it together, pull it in a form that others can consume it and give feedback, right? And it's a really, it is a show and tell. Obviously hackathons are a big part of it. There's lots of data that gets driven and it's led by our strategic development team which is traditionally called sort of an R&D team. And there's 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, right? And the executives in 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, right? So and in this phase, in order to move to the next threshold, we think about it literally as, hey, would I give this guy 50 grand? It's a little bit like an angel investment, right? Would I give this guy 50 grand to go explore this and see if there's a there there? Is there something to do? And our CTO is a sort of final decision maker. He gets to sort of pick those things 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, right? So then we get into this validation phase and this is where it starts to get really interesting. Still led by R&D, but they're really poking at it and they're saying, how does this work? We have these 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? And you'll hear, this is really when we start formulating a really important tool that we use in the company, which is what we call WISE, defining the why are we doing this? Why does this exist? What problem does it solve? I'm going to come back to that in deeper in a minute, right? And so at this point, it's still an R&D lead, but this is when a lot of our industrial design team, Yves Behar and a few project guys, they come in and they start to think about, okay, how can I pull this concept into something physical if it's hardware and how is that going to interact with the rest of the pieces of the system? Our product experience team is still also driving a lot of the core values and what the storyboarding is, but it starts to become a lot more real. This is when we start thinking about, okay, how would we build this? How expensive is it going to be? What's the budget going to be, et cetera, right? And at that point, right, we start to really validate, can we actually build it or do we have to wait three years for batteries to be there or do we have to wait for this other innovation to happen or do we have to wait from a budget perspective or whatever it is? Is there a business viability? And then we start to really start to sketch kind of briefs and this is where I come in and make the final decision on, okay, I think there's really a there there and we can now take this to the next level and get it into a play. And then we go into the concept phase, right? And this is now when the responsibility shifts from the R&D folks to what we call product experience team. And the way we think about product experience at Jawbone is sort of what everyone thinks of as sort of conventional design. So from industrial design to software design to audio design to anything in that touches that experience. We have writers on that team, storytellers. We have, you know, ID people like Eve who are, you know, genius creatives. We have amazing, you know, app level designers, graphic designers, everything. It's all in one team and we call that product experience. And their job is sort of from bits to atoms and back and all the way through to unify as one organization. And that's when they sort of take a hold of this and they start to really kind of work out what is and this is what we call when you're starting to really drive the whys, right? Thinking about what's possible, there's a lot of innovation and creativity now in the actual implementation of how we're going to build and create a product. And we start to say, like, what are the most important things in that product? What are the most important problems we're going to solve? We call them hero experiences, right? What are we going to do? What is the bar that will be acceptable, et cetera, right? And at this point, we start to really resolve what we call these whys, which I'll show you again in a minute. And why is that different from what anyone else has done? From the competition, from the category, and then where does it go, right? We don't like to do just one-off things. We have to see a broader vision, and this is part of that creation experience is we look at where do we think the world is moving and how is this thing going to be a stepping stone to that ultimate end vision, and that's where the roadmap starts to get fleshed out. Again, I have the ability here to come in and sort of be the final decision maker with my team and say, yep, we're going to move this to this next phase. And here is also where we look at some of these things, and when I get into some of the specific examples, we have fast-track programs, right? So we took, for example, the Jambox when we were in this phase, and we said, we're not going to go through the other phases. We're going to go straight into the development process, right, because we want to get this thing out. We want to test it in market and move really quickly. So we have the ability to sort of circumvent our own process now and say, like, okay, let's go. Let's go really rapid and fast-track it and recalibrate kind of the go-to-market possibilities, right? So this is when we, after this stage now, it shifts from that product experience team to our product managers who are really defining the business plan. When's it going to launch? When's it going to get into the retail calendar? What is the software release cycle? Really prototyping, actually starting to feel it. And you're starting to make, as I call, a lot of those trade-offs where, like, okay, we wanted to build this. We can't do that, but here's what we can do. We want to be this way. We have to, you know, we want these functional experiences, but we're going to sacrifice battery life. Whatever it is, that's where we start to really kind of pull those decisions and start looking at it. And it's really a big juggling act, frankly, at that point, right? And so the product guys are driving that. And that's when, again, you know, we sort of look at and synthesize all of what we've put together and we say, okay, does it actually cross enough things off our list? Does it meet that minimum viability, right? Because we always start with a very, as you can tell, like this very big wish list of what's possible and what we can do. And then we start to whittle it down and say, does this cross enough of the value threshold that we think that it's worth pursuing and now can actually move it into the development phase where, again, product management continues to lead it. But now you're starting to really get deep. And this is where engineering comes in and is really starting to sign off on, like, we can build it. Here's a time schedule and how we ship. And then, again, you know, product team is looking at how should we go deeper on this? How can we increase engagement? What are the little innovations? What are the tuning? What are all the things that we need to do to sort of make that? You know, one of the things that we've been fortunate to have is a lot of wonderful response to the products that we've built. And we take a lot of care in time and detail, really in sort of this development and concepting phase around little details that create these magical experiences. So for example, when we turn on Jambox, you know, we have this pretty cool sound design And, you know, that took, you know, months to come up with the right audio tuning. We work with a lot of different, you know, choreographers to create that sound. But every time someone turns it on, I see them smile and they laugh. The feel of the rubber prototyping, you know, there's one manufacturer in the world that was able to make the rubber at the quality and durometer that we wanted and the colors that we wanted for the first Jambox, right? So all of those little magical details had a result even in software, right? When we had the first up and when it plugged in and your sleep graph showed up, even just the animations of how, you know, the bars would show up and the way the cards would flow in and out. That was a detail that we thought about. How is this going to interact? How is the user going to experience that? How are they going to feel it, right? So a lot of that kind of stuff happens even at this stage where you sign off on a program. It's going, but you're making those kinds of decisions all the way through and you're trading them off and you're doing it in the context of this bigger picture. So continued innovation is an opportunity to keep refining, keep doing all that stuff. So how do we think about it now, you know, kind of at a broader level? What is the framework for how we think about these signature experiences? Well, we do start with these whys, right? Which is that articulation of the problem that we're solving. And then the themes around how these become actionable concepts, right? And then there's what we do is 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. And they're kind of a person, this is the pod that owns that theme or that track. And they continue to sort of build that out against the hero features and inside features, and how we put that together. So I'm going to go in now into more specifics around what we call these whys, because this is where I spend a lot of my time really asking the question. And what it does is it serves as a really interesting framework for us to be able to come back and say, hey, do we meet those questions that we ask? Does this thing actually do it? And it serves also as a really good guidepost for a lot of our creativity and a lot of our innovation, so that's not unbridled, right? So it really comes down to a very simple question for us, which is what is the user problem that we solve through this experience, whether it's in hardware, software, data, platform, whatever it is, that once we solve it, people can't live without it, right? They may have an absolutely burning need to go solve this problem, and they can't, they're looking for a solution. Or it's things like that once you have it, you never thought you needed it, but now you can't live without it, right? And again, the Jambox is a great example of that. We talked to some people when we were thinking about making that product, and it was interesting because, a little story for you guys. When we launched the Jambox in the fall of 2010, the market for wireless speakers as a percentage of the overall speaker market was 0%, right, 0%. Last Christmas, which was Christmas of 2013, it was 78% of the market, right? And so in a few years, we were able to transform this entire industry that had been around since the 50s and 60s, turn it on its head. And if I had gone out and asked a bunch of people, and I said, who wants a $199 speaker for your mobile phone? I guarantee you that in that focus group 0% of those people would have said that I want that thing, or I need it, or I'd be willing to pay for it. But yet, when we did it, it transformed an industry, right? And so, and this is where these whys become super important, is just really focusing in on what you're doing, right? And I'll go through one example in the audio space, which is the Jambox example in audio. And then I'll take you through a little bit of how we did it in up, in particular up 24, but it starts with what we call kind of our category strategy. And this is the sort of experience framework, right? And our view was, look, all of your content and media experiences are now in your phone, right? They're no longer in your iPod or your computer. And so we need a different way to interact with it that needs to be as mobile, as portable, as high quality, right? That was our fundamental thinking. And then we said that experience needed to be seamless across time and space. You could go anywhere through it, different, your car, traveling, in and out of your house, around the house, that was fundamentally what we were doing. And we said, that's the whole point of why this category should exist, right? And that was the human problem. And then we said, okay, what's in it for Jawbone, right? Why, why should we do this? And so if you think about that broader macro context that I was talking around the Internet of Things, for us, this was our entry into your home, right? And so while everybody talks about all these new things in your house from, you know, lights and, and thermostats and cable boxes and fridges and, and, you know, whatever being connected, media is still the killer app in your house. It's where we sell millions and millions and millions of units, right? So we said, well, speakers can be our entry into that world that's around you. And, and it can be the hub of things that we wanna do from a software and service perspective in your home. So there's, there's this interesting strategy, both at solving user problem, but then why does it matter to Jawbone? So those two have to go together because, you know, A, we're not in, you know, philanthropic, not-for-profit industry. But B, this is, if you do this well, it allows you to keep doing great products, and allows you to keep moving forward and doing interesting things. So that's sort of how we put that together. And then we built this sort of, what we think the experience, what we call the experience continuum is, where is it today, right? And when we started, it was a Bluetooth speaker, right? That was the core enabling technology that allows us to connect to stuff. Where do we think that it's gonna go tomorrow? And then what happens when we can dream in the future, right? And we start to really try to live in tomorrow and the future, and then start to think about what we build today as a graduate, as a stepping stone. To graduate users starting in one place, continue to move, continue to move through that. And that gives us a view of how we also make these trade-offs, right? Cuz we say, you know what, we're not gonna put this into this product, but we got a space for it in the next one, and we know that we can move users to that, and they'll be ready for it, right? And, and that's, that's a lot of, of, of the way we build stuff, is we sort of define that experience continuum, right? And then, and then we, we do talk about this a lot. We don't think of ourselves as a hardware team, or software team, or data company, or whatever it is. We think of ourselves as an experiences company, right? It's not just about that physical device, or the feature, the object. It's about the system. It's about how the pieces come together. And so when we start to define these whys, they become the problem statement. And we say, okay, how do we use a piece of hardware? How do we use a service in the cloud? How do we use, you know, an application, a sound, a button, to solve this user experience problem that we have? And what's the right distribution across that system of where you should attack the problem, right? And where do we need to innovate, and where do we need to pull it together? So that's a big, big, big part of the thinking that helps us do it, right? And, you know, it's, when we think about these here experiences, right, we, we say it's, it's really around the context of why it's magical to the user, right? And then, like I said, the system is a flagship, and then it has to go to a level of emotional connection, right? Where you feel without it, you're lost. Like, I'm gonna go back home and get it if I don't have it, right? And so those are the kind of principles that govern all these things. And we have to keep asking ourselves those questions. Is it doing that? So we pull this all together in experience framework. This becomes essentially a brief for your engineering team and your design team and all the people that work on this in the company. That they can go back to and say, what are we doing? And why are we doing it? And how does that work? And then how do we create against that, right? And then we have a, a sort of whole process. Blueberry's one of the internal code names. But the user experience process starts with a bit of research. So we do actually listen to users and talk to them, but we talk to them in a very specific way. Start looking for those key insights. We concept it, and then we start to build, right? And 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? Could you talk about how you balance the fact that a user would never have told you they wanted to pay $200 for a wireless speaker. Yeah. With user research at the front of this process? Yeah. Well, there's two different, there's two different, there's a lot of layers to, to user research, right? So what we look at, that's a great question. So there's, there's, you know, you guys probably aren't familiar enough with this yet. But there are sort of standard tools for what people do in focus grouping. Where they say, you know, would you try this, would you do this, would you pay this, do you want this feature, do you not want that feature, what do you care about? That's one way to do it. And what you don't usually get there is really great answers. We ask different kinds of questions. We say, you know, how much music do you listen to when you are with other people? What, how do you play that music? Do you listen to it on headphones or do you listen to it on the speakers on, on your, on your phone? Okay. How often are you with other people? How often do you want to personalize experience? How often do you want to share? How do you? So we ask like, we ask a lot of questions. We just ask different ones. And 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? And you say to them, hey, if you had something that allowed you to take, you know, a great example is iPod. If you said to somebody, you know, 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 that, you know. So again, it's, it's at a price that was, you know, more than your phone, right? So, you know, you, you gotta, you, you sort of 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, right? And I think that's the real separation. Is it, it's not, no one's going to tell you what to build. If they do, then they should do it, right? And not you. And so you're, 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? Yeah. Okay. So, I'm going to switch over to some UP24, which is the product that we've had in the market. Our, our wireless products for health tracking. And the whys of UP24 are really simple, right? Well, 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, I feel terrible. Some days I sleep three, I feel awesome. Like, I, I just have no idea, right? And so I, 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. And so this, 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, and, and go and take action on it, right? 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, and I want that ongoing encouragement because everybody, you know, knows that they want to be better, but they fall down or do whatever. And they want a, a fluid way to interact with this. So this is what we were sort of building in Up24, right? 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. And our point of view was that it was going to, we had this sort of fundamental narrative going, going back to the experience framework where we said, everything we do in Up is about, you know, helping people track and understand them, track themselves. It was understand, which is taking all that data and converting it into knowledge, and then the third part was act. So track, understand, and act. That is our narrative for everything we do in the, in the kind of wearable health space, fundamental. And, and it will be for, for the entirety of what we do. It's sort of help people get more information about themselves. Data's great. Understanding is better. Convert that into things that they can have, create real knowledge that they can then take action on. So anything that we can do to keep the device on, get more information, help them be engaged, and then find ways of, of guiding that behavior was, was really, really interesting. And this is the sort of framework for the system. And then you can start to think about, well, that designs how you build your data infrastructure, your insight system, how you process it, how you build the application experience that surfaces it. And this is a little bit more of a blowout around track, understand, and act, right? So we gotta, and, and this is, the, the tracking part is really fundamentally about the hardware too. It's sort of, 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 keep, create the habit of keeping it on your body, right? Then you gotta take all that data, and it's not just visualization of information. Like, you know, if I told you your guys' heart rate was 75, is that good or bad? Who knows the answer to that question? I don't. It depends, right, on what you're doing, and who you are, and what's happening. So just the data surfacing is not enough. You gotta contextualize why that matters. Turn it into action, and that's the third part, right, is action is key. So let me understand the data. Let me understand that when I work out at 4 o'clock, I get four more hours of deep sleep at night. That's awesome. So let me, let, get Ryan Miner at 4 o'clock to go work out or do whatever, right? And that's what we've built, and that's a lot of infrastructure to sort of create that experience. But that's how we build software. That's how we build hardware. That's how we build sort of the whole system. And then often we, we will talk about different kinds of users and what they care about and what we think our user base is made of. And, you know, who's more into weight loss, who wants this sort of social acceptance, who are people who are vain, that just want to look better. And, and why, it's, it's true. So you know, there's lots of different things and we, and there are people who have sort of medical reasons for they use our product. And we design different kinds of experiences, right? And we think about using the platforms like the phones and, and ways to push notifications and as part of the system thing, right? We think of notifications as a tool for behavior change, right? And then we actually start to go map out these things. What is a smart action, right? Is it real time? Does it feel customizable? Does it feel progressive? Does it help me? Is it really tailored to me, right? And then for this particular type of user, we go out and storyboard. And then these storyboards go to our, our design engineering teams who work together. And they actually start to build off of this. And what this does for us is it creates a nice set of constraints. You know, 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 is, that it will solve a user problem in the simplest way, right? And so we, we create a lot of those constraints around what we're doing. This is, this is the, the sort of storyboarding for, you know, getting someone to the goal, and, and how they do it, and what we use in, in real time. So, and then, and then we put in sort of the secondary experiences, right? Which is if we can do this, and we can fit it in, and it's not too cluttered or confusing, we'll put it in. So, that's a little bit of a snapshot into, into how we build. And we have a few minutes left, so I'd love to answer any questions or. Yeah, my question's for you. Yeah. We've got about a half a minute. Go ahead. So, let's say you have this product, right? You have all of these features that you want to do, right? All these things. Yeah. To satisfy. And you're about to attend to a design process, right? How do you approach the whole problem, right? How do you break it down so that, okay, you solve this, and satisfy, you know. It's gonna fix this problem, it's gonna go this way, right? But then, because each design feature is not mutually exclusive. How do you like approach it holistically, while solving these problems? Can you repeat the question for the report? Yeah, I mean, so that, I think the question was, when you have a number of different features and functions that you're trying to build, how do you look at it at a system level to understand, not within that one silo, what the trade-offs are, but what the trade-offs are across the entire system? I think that's the answer to your question. You do exactly that. You don't think about it in one silo. You have to force a lot of, you know, when it's a small team, it's really easy, because you guys are all sitting around a table. You're looking at each other. You're making those decisions in real time. As you get bigger in a larger company, you have to force a lot of communication where everyone's in a room, and that person says, you know what? If you build, if you constrain me in this way, then I can't get the quality spec that you need me to make. And this guy's going to say, well, if you do that and you give me that much space, then I can't fit all the algorithms in at the battery performance that you want. And so when you start to look across the system, you start to see everyone has to share what their pains are. And they have to understand, if I make this trade-off, it's going to affect me over here. And so you have to put them all together in a room and start hashing that. But what's on the board and on the walls and on everywhere is, what are we trying to do? And does that trade-off still meet it, right, across all those different silos? Because everyone's thinking about the trade-offs in their bin. They know what they need to accomplish, right? But again, it's how does that affect the whole thing? We just went through this with Up3, which is a product we're shipping in a couple weeks that sort of defined the next wave of what's 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 productized really fast. And even just trade-offs on what the electrode materials were had effects on reliability, sourcing, signal performance. And these guys weren't talking to each other. We had to get in a room, do daily calls for three hours where they're going through each other's things. It's tedious, but we're figuring it out and we knock it down. So when you're small, it's really easy because you just draw a look at it. But you have to always have that definition of what you're trying to do across the system. And that's why a lot of what I was talking about was much higher level. What problem are we solving? Where does it go over time and how do all these pieces inform it? Go ahead. If a startup wants to build a system eventually, should it start focusing on one small thing or should it start looking at the systems itself and how to build it all together? I think system think is, it's a way, it's a mindset, right? It's not actually a system, right? There are simple systems, there are complex ones. A plane is a very complex system, a car is a very complex system. There's other products we make that are much simpler. But a phone is a complex system. An application, you should think of as a system, right? And how all the pieces work together. Your storage, the front end experience, what you're doing, the connectivity, that's all a system, right? And so that's more what we mean about system. Yes, for us, system is hardware, software, and data. But I think within even anything, there's always system think. And so it's more just thinking about how the tradeoffs work across all the different pieces as they come together. Does that make sense? Yeah. I have a question. What's the decision making process between creating related products in the same space, so for fitness tracking, there's different versions of, or for Jambox, there's different versions of Jambox. What goes into that? We do have a grand unified theory, at some point, around how these experiences come together and what happens. And it touches a little bit that point that I was making to you around a context engine, when you have things on your body, that can make everything in the world around you smarter. Like if I know the emotional state of a user, I can tell Spotify what song it should play you on the Jambox, right? I can tell the TV that you didn't like that commercial, they should fast forward to the next one. Or I can tell you not to watch Game of Thrones on a Sunday night, because you don't sleep well, right? So you start to see how, I'm serious, right? And so these pieces start to go together. And so we do think at that level, and then we start to say, what are the building blocks that get there? And how do we establish credibility? How do we establish a distribution system? How do we establish manufacturing scale? How do these pieces start to come together? So there is a grand unified vision for us. And we look at different categories. And different categories have different dynamics. They move at different paces. They have different replacement cycles. A great example of this right now is what's going on with iPad and iPhone. We're all very used to replacing our phones every single year. iPads are not following that same trajectory, right? So the replacement cycle is different. The use case is different. The problem it's solving is different. So you gotta adapt to that, right? You don't replace your Nest every year. It's a 15 year install. So how do they build in that kind of a world? And how do they think about? So it's just, you gotta think about your category, the replacement cycle, the usage, how these things come together. And the dynamics are different, right? Go ahead. First of all, how do you come with this unique pattern of the job at being a PVT background in the first place? And do you think it's a better design if you have this idea? Or do you think that the functionality is somewhat important? Which piece are you talking about? You're talking about the texture? Yeah, the texture, yeah. So it's unique texture of, it's like signature of every job or product. Yeah, and a lot of that was developed by Eve and her design team and sort of coming up with a branded look so that you saw the icon. And you knew what it was, right? Whether it's here or anything. So that was part of sort of our mission. We wanted to convey a certain emotional quality, etc. Some people like it, some people don't. That's sort of the nature of design. But that was all part of the same process, right? Go ahead. Sorry. Yeah, so this is kind of building up on the other questions. But when you iterate on a certain product, how does your process necessarily change? And how do you take into account information that you might have learned from, let's say, like, 24 was developing up to three? Like, how does the framework of the process change? That's a good question. I'm actually going to go back to that slide. The question was, it's sort of not on the initial product, but as you've launched the initial product, what happens to your thinking? And how does that evolve the process, right? So I'm going to take it back to that slide that shows kind of how we create the process flow right here. So, sorry, I've got to go through these builds. So, it's actually a great question. So, say this is you starting something totally new from scratch, and you come out here, and you do all this stuff, and you get it to here. And then you learn a lot. And in the first iteration of Up, in 2011, it broke. It didn't work, so we had to actually go back to the drawing board. And so what that did here is we actually ended up telling these guys a bunch of things that they should be thinking about. And sort of unlocking a lot of problems we had to solve, that they then started working on at a different pace. Because sometimes this will take years to come to fruition. We can dream a lot faster than what's possible, right? And so even at core technology levels, it's sensor, batteries, I mean, chips, right, processing, what we can do with storage, all that kind of stuff. We'll say, well, you know what? If we have those are the problems that we're facing, what if we start running different parallel threads to go fix that? And so we'll start doing some work here. They'll look at it in different parts of the process. So there's room for innovation in all these different things. But we may see something here that we say, let's go straight into planning and development. We don't need to go all the way back, right? So we have the flexibility to sort of jump through and say, we don't need to do these things. We know that, like it wasn't a big struggle for us to know to go from a solution that plugged in to go to wireless. Like I wasn't concerned that we had to do a lot of concepting and validating, I knew that was going to work, right? So we can kind of skip through those steps. If you know how to make those decisions. What this is more, for us in a lot of ways, is a way of kind of taking a lot of innovative spirit and creativity and giving it a very focused way to actually get out, right? And so that's what we think about it. We have the ability to sort of go back and forth and skip over steps as necessary. Go ahead. I'm just curious how large is Job Run now in terms of the number of employees? And then as you've added more employees, what were some of the kinks that you encountered of having not just a group of five, but more people working on one project, and then everybody getting heard, or some of the organizational tools to facilitate that? Yeah, yeah, that's a good question. So the question is, how big are we? And then as we grew from few to many, how did it change our thinking around process and tools and how we kind of work together, right? So we're about 500 people, and we have a very remote setup. We've got an office in Sunnyvale, headquarters in San Francisco, office in Seattle, Shanghai, Pittsburgh, London. And so we have a very distributed team that poses a lot of interesting communication challenges, but also allows us to get where the talent is and where there are interesting people in specific areas that we're doing. I would say the single biggest thing that we continue to always try to get better at is that communication between all these different people working in different ways and forcing them to sit at the table and say, here's what I'm working on, here's where my trade-offs are, this is what I think it should affect you. Listening to other people and sort of understanding it, and then remembering that we are building this system, and here's what happens when all the pieces come together, and then how do we solve problems. But it's a lot of that forcing that communication. And doing things, like I literally on Up3 have a daily call that's two and a half hours with the entire team from materials, sourcing, manufacturing, design, sensor, firmware, mechanical engineering, all together. And they all have to sit through each other's updates, but then understand what those trade-offs are, and I sort of force that communication. So, go ahead. What, at what point did you decide to expand? And how did you decide where to expand to first? You're talking about, so the question is, how do we decide to expand and when? Or is that geographical, is that our team, is that markets? How did you find the connections with each other? I mean, I think a lot of it, some of it's deliberate. You know, we sort of say, obviously, we build a lot of things in China, so we need to have a presence there and manage things. So at some point, we got big enough that we wanted our own team on the ground. We've expanded sales. I think we're in 56 countries globally, 100,000 points of sale. So that was, we started in North America, we went to Europe, we went to Asia. Now we think a little bit differently about when we launch, what geographies we go to. So some of it's deliberate and planned, some of it takes time. And again, it's part of that, we want to be here, here's how we want to grow, we want to migrate our business this way. And then a lot of it is also opportunistic, right? There are markets that we've entered where we had a really good partner or we had a really strong proposition or the culture was really well suited to what we were doing. For us, China's a huge market for us. We went in with Apple, in Apple stores, and that was a great stamp of credibility, and we sort of rode that wave. So again, but we knew we wanted to be in China, and that was a great entry point for us. So I think it depends on what you're doing specifically and what's appropriate for that situation. Go ahead. Why haven't you made any headphones? I mean, for us, any category, I get asked about a lot of different things, and headphones is sort of one. For us, it's like when we come into a space, we want to blow it wide open and make sure we have a proposition that makes it better for the user than what's there today, and make it better in sort of an order of magnitude or two order of magnitudes and do stuff. So sometimes the market's not ready. Sometimes the technology base isn't ready. Sometimes we're not ready. We don't have the right capabilities to synthesize and pull those pieces together. So it's a combination of factors, whatever the product or the category is. All right, one more question. Go ahead, in the red sweater. Yeah, hi. For a hardware company or a system company, the product in one cycle is always a headache. Sam mentioned one early capacity. We're trying to run a hardware company like a software company. I was wondering if there's anything you could share there. Are you trying to run Java more like as much as close to a software company to get user feedback along the way in your development process? So I think the question was, hardware companies are sort of hard to run. They're different from software companies. How are we trying to run Java, right? I would say there's no model for what we're trying to do. It's never been done before. So we feel like we're at the tip of the arrow. We're putting together disciplines that have never had to work side by side to create experiences. It's very painful sometimes. It's very fun. We try to take the best of everything. Try to take the best practices of what make rapid software iteration, testing and development, deployment, try to apply that to hardware. We try to take the resolution that you require in hardware and apply that to software design. Because web software is very different than mobile software. It turned out that building mobile software was actually a lot more like building hardware, where you actually had one shot and you had to get it right, right out of the gate. So we try to take the lessons from each place and make ourselves really good. And that's my job and that's the job of some of the other senior leadership is to look at those opportunities of how you kind of take the best of everything and put it together. But I don't think there's ever been a company that's been great at, equally great at hardware, software, and data. And that's what we're trying to do, so. Do one. All right, thank you guys. Good.