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.
