Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Lecture 17 - How to Start a Startup

0 (0 Likes / 0 Dislikes)
Very exciting, and thank you, Sam 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 he was on his company journey and so it's cool. So what he asked me to talk about today, was a little bit about sort of the hardware journey of building products. So what I want to do is give you guys a little bit of an overview of Jawbone. What we do how we think about the world, and that informs how we build products and goes specifically into in 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, with sort of the broadest thinking and, and the way we look at the world. As we think of ourselves at this intersection of, of really crafted innovation in engineering that's almost invisible to the user, in terms of it's 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, we do play in this world of what everyone's talking about now is Internet of Things. We were there much longer before there was such a, 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 the headset. We, we sort of created a headset that become a wearable computer. It was the first Jawbone 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 through 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, 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, 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 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 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 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, 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, 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 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 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 will 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 that absolutely powered by software. We have developed world class software application expertise. We've gotta be as good there from an engagement perspective as something like an Instagram or 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 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 somethings 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. 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, wow you build at scale, how you build tools, etc. They're not typically great at building software and services, right. It's a very different discipline and a very different skill set. So when we first put those pieces together, that created a lot of interesting friction in the company. Our software and application team was so used to moving really, really fast and iterating. Whereas in the hardware world, you gotta 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 is 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 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, discreetly as an application or discretely 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'll, I'll come back to this system think in a, in a second. So what is 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, we keep in confidential and private and I know that we are talking, now that we, 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 or it's, it's quite a deliberate process, right. 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. 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 it a lot of, 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's, it's sort of raw creativity. And we want to create, and we try to create, a form where that's okay. because a lot of times in companies, that gets lost. And then, when we sort of bring 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 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 it off on that phase that we think okay, you know what, there, there, this theory's 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 a, 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 would 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 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 are the 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 hand off between various stages. and, 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, 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, it's a, it's a really, it is a show and tell. Obviously hack-a-thons are a big part of it, there's lots of data that, that gets driven. And it's lead by our, our strategic developments, in 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 sounding board. They're there to poke and prod and tell people, hey think about this, or did you thought, did you try that, how does that work, right. So, in, 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 the, is the 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 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, you know, why this works. Why, why is it going to 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, why's. 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, 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, you have Bahar, and, and a few project guys. They come in, they start to think about, okay, how can I pull this concept into something physical that'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, and what the storyboarding is. But it starts to become a lot more real, and this is when we start thinking about, okay, how would we build this? You know, how expensive is going to be, what's the budget going to be, etc, 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, 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, and make the final decision on, okay, I think this is the, there's really a there there. 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 in Jawbone is sort of what everyone thinks of this 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, story tellers, 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, 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, what is, and this is what we call, when you're starting to really drive the why's, 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? That, what are the most important problems we're going to solve? We call them hero experiences, right? What are we going to to do. How, what is the bar that, that will be acceptable, etc, right. And at this point we start to really resolve what we call these why's, 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 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 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 road map starts to get fleshed out, get, 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, 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 we said, we're not going to go through that phase, we're going to go straight into the development process, right. Because we want to get this thing out, we want to test it and market it, 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? When do, what is the, you know, 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 pool those decisions and start looking at it. And, and it's really a big juggling act 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? because we, we alway 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, is this cross enough of the value threshold that we think that it's, it's worth pursuing. And now can we 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 with a little innovations. Or 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, 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 go 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 and there's one manufacturer in 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's this going to interact, how's the user going to experience that, how're they going to 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 and continued innovation is an opportunity to keep refining, keep doing all that stuff so. So how do we think about it now you know it, 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 why's. Right, which is that articulation of a problem that we're solving. And then the themes around how these become actionable concepts, right? 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 person, 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 into how we put that together. So, I'm going to go in now in, into more specifics around what we call these why's, because this is where I, I spend a lot of my time really asking a 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 guide post 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, they're looking for a solution. Or it's things like, you know, 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 of 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. So in a few years we were able to transform this entire industry that'd 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 $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 why's 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 the audio, and then I'll take you through a little bit of how we did it in op in particular UP24. 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. All right, they are 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. All right, that was our, our fundamental thinking. And then we said that experience needs to be seamless across time and space, so anywhere through it, different 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. 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 want to 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 Java? 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 it 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 allowed us to connect to stuff. Where do we think that it's going to 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 the sort of thing about what we build today as a gradu, 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? because we said, you know what, we're not going to put this into this product, but we got a spacer 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 it's, 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 the 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 together? So that's a big, big, big part of the thinking. It helps us do it, right? And, you know, it, it, it's when we think about these here experiences, right, we, we say 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 the level of emotional connection, right? Where you feel without it you're lost. Like, I'm going to 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 sort of whole process, Blueberry is one of the internal code names. But the user experience process starts with a better resource, so we do actually listen to users and talk to 'em. But we talk to 'em in a very specific way. Start looking for those key insights. We concept 'em 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, could you talk about how you balance the fact that a user would never, told you they wanted to pay $200 for a wireless speaker. >> Yeah. >> With user research in front of this process. >> Yeah. Well, there's two different, there's two different, there's a lot of layers to, to users 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, would you pay this, do you want this feature, do I want this feature, what do you care about. That's one way to do it. And we 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? Wha, how do you play that music? Do you listen to a headphones, or do you listen over the speakers 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 want to share? How often 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 gotta, 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's that, 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, 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? Okay. So, I'm going to switch over to some Up24, which is the product that we've had on 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, et cetera, but we know nothing about ourselves. We have no idea why some days I sleep eight hours and feel terrible some days I sleep three and feel awesome. Like I just have no idea, right? And so I, our thought was: could we take a lot of this sensor technology, ma, help people understand more about themselves and start to then make better decisions about how they live better. 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 to, a fluid way to interact with this. So this is what we, we're 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, 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 on results. Data is 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 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 got it in 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 you 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, 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 the 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 four 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 the 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 the use of 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? And the we actually start to go map out these things. What is a smart action? Right, is it real time, is 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'd go out and storyboard and then, these storyboards go to our, our design engineering teams. We work together and they actually start to build off of this. And what his 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 the 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, it's not too cluttered or confusing we'll put it in. So that's a little bit of a snap shot in the, into how we build and we've few minutes left so I'd love to answer any questions or. Yeah the person's great. >> Yeah. >> Got about 15 minutes. >> Go ahead. >> So let's say you have this product right, you have all these features that you want to do right, all these things. >> Yeah. >> To satisfy and you're into your design process right? How do you approach the whole problem right? How do you break it down so that it's all business? To satisfy, you know, this problem in this way, right? But then, cause each design feature is not mutually exclusive. How do you project holistically? >> Yeah. >> Sort of. >> Can you repeat the question for the recording? >> Yeah. I mean, so that, I, 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 the 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 is in a room and they, that person says, you know, what if you build, if I, if you were contraining 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 actually don't understand. If I make this tradeoff, 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, does that tradeoff still meet it, right? Across all those, all those different silos. Because everyone's thinking about the tradeoffs in their and they know what they need to accomplish, right? But again, it is how does that affect the whole thing. We just went through this with three, which is a product we are shipping in a couple of weeks that sort of defined the next wave of what is 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 prioritized really fast, and even just trade offs on what the electrode materials were. How it affects on reliability, sourcing, you know, signal performance. And they 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 thru each of their things. It tedious, but we're figuring it out. We knock it down. So it's a little. When you, when you're small it's really easy because your just, sure I'll 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's it go over time and then 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 systems itself and how to do them altogether. >> How do you get, I think system think is, is, it's a way, it's a mindset. Right? It's not a, it's not actually a system like the simple systems, there are complex ones. You know, I, the, the, you know, a plane is a very complex system, a car is a very complex system. There's other products, we make that a more simpler phone as a complex an application, you should think of as a system. Right? And how all the pieces work together. Your storage you know, the fun and 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 things. And so it's more just thinking about how trade offs work across all the different pieces as they come together. Does that make sense? >> Yes. >> Go ahead. >> I have a question. What's the decision making process between creating like related products in the same space? Like for fitness tracking, there's different versions of, for, for Jambox. Use different versions of Jambox. And, you know, 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 jam box, 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? And so you start to see 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? Now 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, 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 its solving is different. So you've 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. >> First of all, how you would canvas this unique. Community of Babylon was to face? And it's a you have this idea, or you think the functionality is somewhat important? >> Which piece are you talking about? You're talking about the texture? >> The texture, yeah. >> Need a tech show. Succeeding at every job and product. >> Yeah, I know. A lot of that was developed by, by Eve and our design team. And, and sort of, you know, coming up with a branded look. So that, you know, you saw the icon and you knew what it was, right? Whether it's here or, or anything. So that was part of, sort of, our, our mission. We wanted to convey a certain emotional quality, etcetera. Some people like it, some people don't. That's sort of the nature of the design. But that was all part of the same process. Right? Go ahead. >> Sorry. >> yeah, so. This is kind of going off of the other questions. But when you get a certain product, how does your processing unnecessarily changed, and how do you take into account information you might have learned from, let's say, like,. Like how does the framework and processes work? >> that's, it's a good question. I'm actually going to go back to that. So 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, going to take it back to that, that slide that shows the kind of the how we create and the process flow, right here. So, sorry I gotta go through these builds. So it's actually a great question. So this is, you know, say this is you're starting something totally new from, 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, you know, 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 it at a different pace because sometimes this will take years to come to fruition. We can dream a lot faster that what's possible, right? And so even at core technology levels it censored. Batteries, I mean, chips, right? You know, processing. What we can do with storage. Like, 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 parallel threads to go fix that. And so we'll, 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 to plug in to go wireless. Like I wasn't concerned that we had to a lot of concept evaluating. Right? So we can kind of skip through those steps if you know how to make those decisions. But 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, that's what we think about. 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 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 you know, not just a group of five. But more people working on one project, and then everybody getting heard, or some organizational tools to, to facilitate that. >> Yeah, yeah. That's a good question. So the question is how big are we. >> And then as we grew from, you know, few to many how did it change our, 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 is Sunnyvale, headquarters in San Fransisco, offices in Seattle, Shanghai Pittsburgh, London. And so we have a very you know, distributed team that poses a lot of interesting communication zones. But also allows us to get where the talent is and, and where there are interesting people in specific areas that we're doing. I would say the single biggest thing that, 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 tradeoffs 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, we solve problems? But it's a lot of that, forcing that communication. And doing things like, I, 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, you know, firmware, mechanical engineering, all together. And they all have to sit through each others updates and but then understand what those tradeoffs are and I sort of for, 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 geo, so the question is, how did we decide to expand and when? Are you, is that geographical, is that our team, was that markets? >> Yeah who, how did, how did you find the connections to each other in the other? >> I mean, I think a lot of it some it's deliberate. You know we, we, we sort of say obviously we, 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. You know, we've expanded sales. I think we're in 56 countries globally, 100,000 points of sale. So that was, you know, 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 it's, it's some of it's deliberate and planned, some of it takes time. And again, it's part of that, you know, 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 you know, we had a really good partner. We had a really, you know, strong proposition. The, the culture was really well suited to what we were doing. You know, we, we, for UP, China's a huge market for us. We went in with Apple in, in Apple stores. And that was a great stamp of credibility and we sort of rode that wave. So, you know, again, it's, it's, it, 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, and, and, you know, what's appropriate for that situation. Go ahead. >> Why haven't you made any headphones? >> I mean, you know, for us, like any category, I get asked about a lot of different things, you know, headphones is, is sort of one. First it's like, you know, 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 a order of magnitude or two order of magnitudes and, 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, whatever the product or the category is, all right? >> All right, one more question. >> Go ahead, in the red sweater. >> Hi, for a hardware company or a system company the product in recycle is always a headache. Sam mentioned one early faculty who had tried to run a hardware company and a software company and I was wondering is there anything you can share there? Are you trying to run Jobo more like a close a software company to get user feedback along, along the way or along the process? >> Uh-huh. 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 Jobo, 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, you know, 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. And 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 or software data. And that's what we're trying to do, so. >> Okay, thank you very much. >> All right. Thank you guys.

Video Details

Duration: 47 minutes and 15 seconds
Country: United States
Language: English
Genre: None
Views: 40
Posted by: pulak on Nov 19, 2014

Lecture 17 - How to Start a Startup

Caption and Translate

    Sign In/Register for Dotsub to translate this video.