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

1. HRHosain Rahman0:00

   So very exciting. Thank you, Sam, uh, for having me. Sam and I have known each other for, for a long time because we were fellow Sequoia companies, and we met in the early days of when, when he was on his, uh, company journey. Um, and so it was cool. So what he asked me to talk about, um, today was a little bit about sort of the hardware journey of building products. And so what I wanna do is give you guys a little bit of an overview of Jawbone, what we do, how we think about the world, um, 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 kinda comes together and sort of what we do to, to change categories. So first off, I always like to start with, with sort of the broadest thinking. And, and the way we look at the world, um, is we think of ourselves at this intersection of, of really crafted innovation, um, 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. Um, and largely speaking, we, we do play in this world of what everyone's talking about now is the Internet of Things. We were there much longer, uh, before there was such a, a moniker. Um, 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, uh, engineering school here. Uh, and we were developing core technology. We decided to build consumer products around that. Our first consumer product was the headset. We, we sort of created, um, a headset that became a wearable computer. It was the first Jawbone headset. Um, that was when we started thinking about wearable computing. We then, um, invented the wireless speaker space, um, around Bluetooth audio, and I'll talk a little bit about that journey. Uh, 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, in the first generation of headsets and applying them to other parts of the body to understand more about users. So our view o- of this world, having been here for a long time, is that it's a little bit of a mess, um, in the Internet of Things. Everything i- 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 I- 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 gonna be such a world that, 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, you know, Apple Watch and all this stuff, ultimately what we believe is that when you have things that are on your body twenty-four/seven, 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 Up is on me, and it, 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, when I say context engine, I know I can tell the smart thermostat, my Nest, that I'm hot or cold. That device doesn't have that understanding. I can tell it's hot, b- uh, it-- 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 gonna be the center of this, this revolution around everything being connected and smart, and they're gonna drive what a lot of those interactions are gonna be and how they're gonna work, right? And so that's sort of the first principle that we think about when we start to think about, okay, where are things going and what we should, should we build and, 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, at what we call the full stack. We have to be amazing at, at building hardware, um, and these are hardware experiences that people have to keep on all the time, right? You have to wear them twenty-four/seven, 'cause 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, you know, these magical experiences in hardware. They're absolutely powered by software. We have developed, um, world-class software application expertise. Um, we've gotta be as good there from an engagement perspective as something like an Instagram or a WhatsApp. And then on the data side, we've gotta know what to do with this, this massive amount of information and process it and push it and, 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 kinda 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, it allows us and requires us to play at all levels of stack. Now, this was a complicated thing for us to put together because typically, you know, people who are great at hardware understand mechanical engineering, electrical engineering, how those things interact, how you build, um, at scale, how you build tools, et cetera. Um, they're not typically great at, at building software and services, right? 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 our application team was so used to moving really, really fast and iterating, whereas in the hardware world, you've gotta 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. And so what was interesting to see as we put all these pieces together, the hardware team learning to move fasterThe software guys thinking more about how do they resolve experiences before you actually have to ship it versus just throwing something out and AB testing it. And then the data science sort of informs all of that with sort of 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, right? We don't think about it discreetly just as a piece of hardware, or discreetly as an application, or discreetly as a, as a platform. We think about it across the whole thing. And so this is an example with Up, right? Where we have these tracking sensors on the body, algorithms there. It connects to the phone where you have this engaging application 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, I'll come back to this system thing in a, in a second. So what does the actual process of, of creation look like? And this is fun for me 'cause we don't actually talk about this very often. It's quite, you know, sort of, um, we keep it confidential and private, and I know that we're-

2. SPSpeaker7:26

   Now with the entire-

3. HRHosain Rahman7:26

   Talk-- Now that we- we're on sort of a live cast everywhere, so it's fun for me to talk about this for the, for the first time 'cause it's not or it's, it's quite a deliberate process, right? Uh, and this is a little bit at what it looks like. And, 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 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, um, and we think of a lot of, of, of what you guys do here. You're dreaming, you're imagining it. How do you disrupt? What's the future gonna look like, right? It is a little bit science project-y sometimes, and, and, and we talk about it in that way, right? And we do build from inspiration and insight and that, and, and it's sort of raw creativity and we wanna create and we try to create a forum where that's okay, 'cause a lot of times in companies that gets lost. And then when we start bringing it to early validation, where 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, "Look, here's where we see it going. Here's what it's gonna 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? There, there, 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, 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 it, 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 gotta 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, and start making those trade-offs and start to look at, you know, how do we pull that together? And then we move into, um, a development phase where it's a handoff between various stages, um, and, and re- 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, uh, and you learn, um, 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 gonna 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 s- start right over again, right? So that's the broadest way to think about it. Um, a little bit deeper on the exploration phase, right? So it is very much like a building and tinkering process, right? And, 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, 'cause 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, it's a, it's a really, it is a show and tell. Um, obviously hackathons are a big part of it. There's lots of data that, that gets driven, and it's led by our, our strategic development team, which is traditionally called sort of an R&D team. And there's participation from product and engineering, both hardware, software, um, 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 sounding board. They're there to poke and prod and tell people, "Hey, think about this," or "Did you thou-- 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 fifty grand?" It's a little bit like an angel investment, right? Would I give this guy fifty grand to go explore this and see if there's a there there? Is there something to do? And our CTO is the, is a sort of final decision maker. He gets to sort of pick those things internally and say, "You know what? I, I like all the feedback. This is the one I wanna 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, you know, why this works, why, why is it gonna happen?" And, 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 whys. Defining the why are we doing this? Why does this exist? What problem does it solve? I'm gonna come back to that in deeper in, in a minute, right? Um, and so at this point, it's still an R&D lead, but this is when a lot of our, um, industrial design team, you have Bahar and a few project guys, they come in, they start to think about, "Okay, how can I pull this concept into something physical if it's hardware, and how's that gonna 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, 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? You know, how expensive is this gonna be? What's the budget gonna be?" Et cetera, right?Um, 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, 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, um, briefs. And this is where I come in and, and make the final decision on, okay, I think this is, there's really a there there, and we can now take this to the next level and get it into, into a play. And then we go into the concept phase, right? And this is now when the, 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, you know, software design to audio design to, you know, anything in that touches that experience. We have writers on that team, storytellers. We have, you know, ID people like Eve who are, um, 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, as one organization. Um, and that's when they sort of take a hold of this and they start to really kinda work out what is, 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 gonna build, uh, and create a product, and we start to say like what are the most important things in that product? The, what are the most important problems we're gonna solve? We call them hero experiences, right? What are we gonna do? How, what is the bar that, that will be acceptable, et cetera, right? Um, and at this point we start to really resolve what we call these whys, which I'll show you again in a minute. Um, and why is that different from what anyone else has done? From the competition, from the category, and then what is, where does it go, right? It's, we don't like to do just one-off things. We have to see a broader vision and this is part of that, that creation experience is we look at, at, at where do we think the world is moving and how is this thing gonna 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 gonna move this to this next phase." And here is also where we look at some of these things, um, and, and when I get into some of the specific examples, we have fast-tracked programs, right? So we took for example the Jambox when we were in this phase and we said, "We're not gonna go through the other phases. We're gonna go straight into the development process," right? Because we wanna get this thing out, we wanna 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," um, 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 gonna launch? When's it gonna get into the retail calendar? When do, what is the, you know, software release cycle? Really prototyping, you're actually starting to feel it. Um, 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 gonna sacrifice battery life." Whatever it is, that's where we start to really kinda pull those decisions and start looking at it and, and it's really a big juggling act, uh, frankly at that, at that point, right? And so the, the product guys are, are driving that. And that's when again, you know, we, 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, that minimum viability?" Right? 'Cause we, 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, it's worth pursuing?" Um, 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, um, 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? Um, [lip smack] you know, one of the things that, that we've been fortunate to have is a lot of wonderful response to the products that we've built and, and, and we take a lot of care and time and detail really in, 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 that goes whoa, whoa and you know that, that took, you know, months to come up with the right audio tuning. We worked with a lot of different, you know, choreographers to, 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, how to resolve 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, and the way the cards would, would flow in and out. That was a detail that we had thought about. How is this gonna interact? How is the user gonna experience that? How are they gonna feel it, right? So this, 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, of this bigger picture. So, um, and continued innovation is an opportunity to keep refining and keep doing all that stuff. So, um, so how do we think about it now, you know, uh, kind of at a broader level? Sort of what is the framework for how we think about these signature experiences? Well, we do start with these whysRight? Which is that articulation of the problem that we're solving. Um, and then the themes around how these become actionable concepts, right? Um, and then there's, 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 pers- There's, 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, um, and how we put that together. So I'm gonna go in now in, into more specifics around what we call these whys, 'cause this is where I, 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, um, guidepost for a lot of our creativity and a lot of our innovation so that it'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 a absolutely burning need to go solve this problem and they can't, you know, they're either looking for a solution, or it's things like, you know, that, that once you have it, you never thought you needed it, but now you can't live without it, right? Um, and again, the Jambox is a great example of that. We did, you know, we talked to some people when we were thinking about making that product, and it was interesting because... 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, you know, 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 for, you know, 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, 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 that I'd be willing to pay for it. But yet when we did it, it transformed an industry, right? And so what we, and, 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, um, in Up, uh, in particular Up 24. But it starts with what we call kind of our, our category strategy, and this is the sort of experience framework, right? And, and our view was, look, all of your content and media experiences are now on your phone, right? They're no longer on your iPad, 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, our fundamental thinking. And then we said that experience needed to be seamless across time and space. You go anywhere through it, different, your car, you know, traveling, in and out of your house, around the house. That, 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. Um, 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, smoke alarms or whatever being connected, media's 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. Um, and then we built this sort of what we think the exper-- 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, and continue to move through that. And that gives us a view of how we also make these trade-offs, right? 'Cause 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? Um, 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? Um, and then ex- and then we, we do talk about this a lot. We don't think of ourselves as a hardware team or a software team or a 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 a- 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, i- i- it's, when we think about these hero 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 feelWithout 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? Um, and then we have a, a sort of whole process. Blueberry is one of the internal code names. Um, 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, uh, what are the solutions, and then what's required in the product to make that happen. Sam.

4. SPSpeaker25:20

   Could, could you talk about how you balance the fact that a user would never have told you they wanted to pay two hundred dollars for a wireless speaker-

5. HRHosain Rahman25:26

   Yeah

6. SPSpeaker25:26

   ... with user research as a part of this process?

7. HRHosain Rahman25:28

   Yeah. Well, uh, 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 it? 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? W- 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 a personalized experience? How often do you wanna share? How often do..." 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, at a price that was, you know, more than your phone, right? [chuckles] So, you know, you, you gotta... You sort of have to separate what are questions that you can ask that are gonna 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's that... No one's gonna tell you what to build. If they do, then they should do it, right, and not you. Um, 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? You got it. Okay. So I'm gonna switch over to some Up24, which is the, the product that we've had in the market, um, our, our wireless product, um, for health tracking. Um, and the whys of Up twen-twenty-four 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, et cetera, 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 our, our thought was, could we take a lot of this sensor technology, m- 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 wanna be better, but they fall down or do whatever. Um, 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 gonna... 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 kinda wearable health space, fundamentally, 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, um, guiding that behavior was, was really, really interesting. And this is the sort of framework for the system. Um, 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. Um, and this is a little bit more of a blowout around track, understand, and act, right? So we got it 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, the 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 seventy-five, 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, 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 four o'clock-I get four more hours of deep sleep at night. That's awesome. So let me, like, get a reminder at 4:00 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. Um, and then often we, we will talk about different kinds of users and what they care about, um, and what we think our user base is made of. Um, and, you know, who's more into weight loss, who wants this sort of social acceptance, who, um, are people who are vain, that just wanna look better, um, and, and why... It's, it's true. So, um, 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 think, right? We think of notifications as a tool for behavior change, right? Um, 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. Um, you know, my experience has been constraints are really great 'cause 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, uh, this is, uh, the, the sort of storyboarding for, you know, getting somebody to the goal and, and how they do it and what we use in, in real time. So, um, and then, 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, 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. Now we have a few minutes left, so I'd love to answer any questions or...

8. SPSpeaker32:43

   Yeah. Questions would be great.

9. HRHosain Rahman32:44

   Yeah.

10. SPSpeaker32:44

    We've got about, uh, fifteen minutes.

11. HRHosain Rahman32:47

    Go ahead.

12. SPSpeaker32:48

    So let's say that you have this product, right, and you have all these features that you want it to do, right, all these things-

13. HRHosain Rahman32:53

    Yeah

14. SPSpeaker32:53

    ... to satisfy. Um, and you're about to enter into your design process, right? How do you approach the, the whole problem, right? How do you break it down so that, okay, solve this and gonna satisfy, you know, uh, it's gonna fix this problem, it's gonna go this way, right? But then, like, 'cause each design feature is not mutually exclusive, how do you, like, approach it holistically while-

15. HRHosain Rahman33:14

    Yeah

16. SPSpeaker33:14

    ... solving problems with this?

17. HRHosain Rahman33:15

    Yeah. I, I-

18. SPSpeaker33:16

    Can you, can you repeat the question so everyone can hear?

19. HRHosain Rahman33:18

    Yeah, I mean, so that... I think the question was, um, 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. [laughs] 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 'cause 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 and a larger company, you have to force a lot of communication where everyone's in a room and they, that person says, "You know what? If you build... If I, i- if, if you were constraining me in this way, um, then I can't get the quality spec that you need me to make." And this guy is gonna 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 actually understand, if I make this trade-off, it's gonna 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, does that trade-off still meet it, right, across all those, 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, the whole thing? We just went through this with Up 3, which is a product we're shipping in, in a couple of weeks that sort of defined the next wave of what's happening in the wearable space on the health tracking side. We, 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, like, what the electrode materials were had effects on reliability, sourcing, you know, signal performance, and it just... 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 of those things. It's tedious, but we're figuring it out, and we knock it down. So it's a... When you, when you're small, it's really easy 'cause you just sort of all 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.

20. SPSpeaker35:31

    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?

21. HRHosain Rahman35:41

    I think, I think system think is, is, it's a way, it's a mindset, right? It's not a, i- it's not actually a system, right? There are simple systems. There are complex ones. Um, you know, uh, the, there, you know, a plane is a very complex system. A car is a very complex system. There's other products we make that are much simpler. Phone is a complex system. An application you should think of as a system, right? And how all the pieces work together, your storage, you know, the front-end experience, what you're doing, the connectivity. That's all a system, right? And so th- 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 trade-offs work across all the different pieces as they come together. Does that make sense?

22. SPSpeaker36:26

    Yeah.

23. HRHosain Rahman36:26

    Yeah. Go ahead.

24. SPSpeaker36:28

    I have a question. Um, what's the decision-making process between creating, like, uh, related products in the same space? So, like, for fitness tracking, there's different-... versions of, uh, or for Jambox there's different versions-

25. HRHosain Rahman36:42

    Yeah

26. SPSpeaker36:42

    ... of Jambox and, you know, what goes into that?

27. HRHosain Rahman36:45

    Um, we do have a grand unified theory, um, at some point around how these experiences come together and what happens, and it touches a little bit that point that I was making too 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 'cause you don't sleep well, right?

28. SPSpeaker37:15

    [laughs]

29. HRHosain Rahman37:15

    So you start to see how... I'm serious, right? And so these pieces start to, 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, um, for us. And, 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, and the dynamics are different, right? Go ahead.

30. SPSpeaker38:13

    Yeah, so, uh, first of all, how you came with this, uh, unique pattern of the Jawbone? I mean, the 3D background and the crystal face. And do you think it's a, it's a better design to have this idea, or you think that the functionality is more important?

Episode duration: 47:15