- Hi everyone.

So I know this is probably a huge cliche since probably

every single speaker says this, but it's a huge honor

to be here.

I was sitting in your seats about 10 years ago which seems

like not that long and yet quite a long time.

My class, the class of '06 just celebrated our 10 year

reunion here like a couple months which was a lot of fun.

So it's really really great to be here.

I remember when I was sitting in your seats and you know

I had just come from Texas, that's where I was raised

and I had done some web design in the past,

but I didn't really know anything about Silicon Valley,

didn't know anything about this kind of tech hub

and what it means to have a career here and startups

and all of that prior to coming to Stanford.

And I remember sitting in the audience and listening

to the stories of people who had come before me

and in particular Marissa Moyer and Jeff Fitzpatrick.

They'd stand up here and they would take about their

adventures after leaving Stanford and all of the great

things they got to go and build and work on.

And I was just like wow, this is super super exciting.

And you know, now I'm excited to be here talking to all

of you guys and hopefully sharing a couple of my stories

along the way.

So as you guys heard, I was here, I did my computer science

degree, my bachelors and my masters and I was also lucky

enough to be part of the Mayfield Fellows Program.

So how many of you guys know about

the Mayfield Fellows Program?

Okay so for those of you who don't know, this is an awesome

program that is really about diving into entrepreneurship

and so one part of the program is that between your junior

and your senior year, you go and get an internship

with a startup somewhere in the Valley.

And along the way as we're interning at our respective

companies we're learning about entrepreneurship, we're

taking classes we're doing case studies.

And it's fabulous, it's awesome, it's taught by Tina.

I had a lot of fun doing it.

So at the time the start up that I chose was actually

Facebook and you know this is a little bit of a little

cheating because in 2006 Facebook was already

about 100 people, so it was a startup but on the larger end

of the startup.

But it was something I was really excited to work on.

It was a product that I and all of my classmates at the time

used very religiously.

So I went there and I remember my first day at Facebook

in fact, I was signed up to be an engineer and work on

some of their photos features and I had a mentor

and her name was Rudgy and on the first day she said,

okay there's been a change of plans I'm switching jobs,

I'm not going to be an engineer anymore, I'm going

to be a PM, I don't really know what that means for you,

but let me introduce you to this pod of people over here.

This is our design team, why don't you sit with them

and you know, chat with them.

I've got to go run.

And so she left me in this pod with this group of designers

and before that, I'm not a designer by trade, I didn't

really know anything about design, but I got to talking

to these people and I sat at that pod.

And low and behold, fast forward 10 years

and now my career's in design and when I look back on it

it sort of seems really quite random how it happened.

But for me what was so exciting about design was the chance

to work at the forefront and thinking about what are

the people who are going through the experience

that we're building, what are they feeling,

what are they thinking, how are they able to understand

the products that we've built.

And so to me that's what was super super fascinating

about design and I also wasn't that crazy because

at the time the designers that we hired were also

our front end engineering team, so it was a little bit

of both designing and a little bit of coding.

This is back in the world where we were still operating

with just websites, so you just had to do some CSS

in JavaScript and front end PHP and it wasn't nearly

as complicated of an ecosystem as it is today.

But we got to building and one of the first things I worked

on was photos and photo products, I also remember one

of my first big launches a couple months later,

which was Newsfeed back in September of 2006.

Over the years I've worked on things like the Facebook

platform and ushering a bunch of applications built

on top of Facebook including a lot of games,

back in the era of 2008 and 2009.

I worked on Profile and Timeline and I worked on Newsfeed.

And today the team that I lead, we work on design

for all of the core features of the Facebook application.

So when you go on Facebook and you want to catch up

with your friends, you want to share, you want to watch

videos or join a group, those are a lot of the things

that my team works on.

So all that said, that's a little bit of an intro

into kind of how I got here.

The thing that I think has been the most fascinating for me

as I look back on all the things I've worked on

is the moment when you're starting a project and you're

thinking about here's this awesome new idea that I have

and I can imagine how it's going to work and how people

are going to use it and I want to build it right now

and you rally a bunch of other people together with you

and you guys are all excited about this idea.

That's how everything happens.

That's how any idea ever sees the light of day.

But the question that I found super fascinating, is how

do we know at that point in time whether this is an idea

that's going to be successful?

How do we know after it's all said and done and we've

worked our nights and weekends and we've gotten it out

to the world, will it actually be something that people

find valuable and that they'll find easy to use

and that they'll find well-crafted?

And being at Facebook, we've had our share of features,

some of them that have gone on to be great success,

and some of them that haven't.

And a lot of times at the beginning, you know, it feels

like there's really no way to tell.

It feels like you're kind of rolling the dice a little bit.

And this is the thing that I wanted to really study

and reflect on over all of the different products

that we've built.

Is what were the patterns for the things

that were successful, are there ways that we can tell

as we are building whether this is something that's going

to work or not.

And what came out of that, and a lot of discussions

and a lot of postmortems and a lot of just looking at

the things that we had built, was a framework of just

three simple questions at Facebook that we now use

to ask ourselves whether the things that we're building

feel like that they're on track.

And they're three very simple questions because you know

it wasn't going to be a manual that everybody was going

to memorize and understand, but it was three questions

that we wanted everyone at Facebook, no matter what their

role was or what they worked on, whether they were engineers

or designers or product managers, to keep in mind

when they're having a team meeting or whether we're

reviewing the product or whether they're actually just

talking with a colleague about an idea to just think

of these three questions and to ask them.

And to make sure that we have really really good answers

to these questions.

So that's why I'm going to talk with you guys about today.

So the first question is the most basic and the question is,

what people problem are we trying to solve?

And the key word here is really the word people.

Because of course whenever we build anything we're trying

to solve the problem.

But what tends to happen is that you start to think

in the mentality of your team or your company and you start

to say things like, the problem we need to solve is that

we need to optimize the click through rate of our page.

And you know, you'll hear things like this all the time,

boil down in small ways and in large ways.

And that's not a people problem.

A people problem as we define it, is if you go out and you

talk to someone on the street and they were to articulate

a problem that they were having, that's how they would

say it, that is the people problem statement.

So there's a couple things that we look at to make sure

that this is a valid people problem statement.

The first is that it needs to be human and straightforward.

So we're not using words like CTR, we're not using words

like optimize or integrate, like these are not words

that people on the street would use, these are not words

that people who are outside of the tech community

are going to use to talk about their problems.

The second thing is we want to make sure

that it's solutions-agnostic.

A lot of times we start problems by saying I am going

to build an app that blank, or I'm going to design

a website that blank.

And already in that statement is an inkling of what

the solution is, but what if you know the app's not

the right way or what if it's not supposed to be a website?

So a good people problem statement gets away from trying

to already constrain it into a particular solution.

The third thing is that it shouldn't be about you know

Facebook or your company or your team or whatever winning.

And I think a classic example is if you say, our service

is going to be the best at blah blah blah.

A person on the street doesn't care if your service

is the one that is the best at that, they just want to know

hey for this problem that I have, what is the best solution?

So stating any problem as we, our team, our company,

whatever wants to win, is not getting close to the things

that people actually want.

The fourth thing is that it gets at the why, so sometimes

you might have a problem like people aren't discovering

this page and that is a problem that we need to solve.

But it doesn't go one layer deeper, it doesn't get at well

why, what's actually the root cause of why people aren't

discovering this page.

Is it too hidden for them, is it too confusing for them

to find, it's gotta get to not just what is happening,

but what is the reason why it's happening.

And finally a good people problem statement can not just

solve functional problems like a confusing flow,

but could also get at emotional or social problems.

Sometimes people just want to feel like they belong,

sometimes people just want to feel like they're validated.

Those are things that also constitute something that

when you ask people they might say.

So let's look at some examples.

So earlier this year I had the privilege of attending

the Mom 2.0 Summit and this is a gathering of a lot

of influential bloggers and journalists who are mothers

and who talk about parenthood and those topics.

And so I got a chance to meet a lot of the attendees

and be on a panel with some of them.

And one of the things that I heard over and over again,

was basically this, and this is an example to me

of a people problem statement.

I want to talk about an interest with other people who are

also interested, but I don't know where to find them.

And this is especially relevant at this conference