One of the stories we used to tell in the early days of Facebook was how a small, two-engineer project came to dominate the entire photo sharing landscape in the late 2000s.
Thread ๐ 1/10
Let's zoom back to 2005, when pre-mobile Internet photo sharing services were one upping each other on storage, features, and slickness.
Across Photobucket, Shutterfly, Flickr and Picasa, there were high-res uploads, preview navigation, theme tags, search by color, + more
2/10
Facebook Photos, built by a scant team over two months, was extremely bare-bones in comparison. It only supported low-res photos. No comments. No likes. It didn't even have a nice full-screen view.
There were no bells and whistles, save one...
3/10
The one feature Facebook Photos *did* have, even in its earliest incarnation, was this: photo tagging.
You could upload a photo and say who was in it by tagging their profiles.Then, those people would get a notification that you uploaded a photo of them.
4/10
What a simple feature. And yet. It made all the difference. Facebook Photos skyrocketed in popularity.
Within a few years, it was the most popular photo sharing service on the Internet.
Why?
5/10
When you go to someone's house and look at their proudly-displayed photos on the mantel, what strikes you?
Is it the lighting? The beauty of the subjects? The artistic composition?
Or is it the fact that it contains their family and friends?
6/10
Growing up, my most treasured photos were the ones that reminded me of my happiest memories with people I love: backyard BBQs, family vacations, school trips.
Sometimes I was squinting. Sometimes the lighting sucked. I didn't mind.
7/10
For the vast majority of people, *people* were the most important feature of their photos.
Later, when News Feed was introduced, photo tagging shone even brighter. If I'm friends with Alice and she never takes photos herself, I could still see photos of her by others.
8/10
The reason we told this story often (thank you @aaron_!) was to remember a fundamental product truth:
It is not about how many features you add or how much work the team did.
What matters is: did we understand the users' needs well enough to give them what they wanted most?
It's easy to dream up thousands of things we'd like to build. It's fun to imagine the possibilities.
But good product discipline comes from knowing how to prioritize and pinpoint the most important thing(s).
Do this well, and even if you're small, you can still win.
1) I loved the people 2) I was continuously challenged and learning 3) The mission spoke to me 4) I felt deep loyalty
But there was another big reason that was hard for me to admit then...
(1/10)
The hard-to-admit reason was this: my sense of identity was deeply tied to my job.
I felt I *belonged* there.
I had a great career there.
I'd made many wonderful friends there.
And so, it was terrifying to imagine: who would I be if I *didn't* work there?
(2/10)
"My identity = My job" is a common thought pattern for folks (more likely founders or young) who...
1) have invested tons of time/capital/energy into the job 2) are ambitious 3) are recognized for their job 4) have mostly work friends 5) believe deeply in job's mission
I've participated in too many conversations about the role of design / pm / eng to count.
Of course there are differences.
But every tech manager role, regardless of discipline, ends up converging at higher levels.
What does this mean for you as a manager?
Thread below ๐
If you climb the management ladder to the very top, guess what? Youโre the CEO. And you manage *every* function.
So if your goal is to be CEO someday, or even VP or director within your discipline, you need to get out of your box and learn how other disciplines work.
(2/9)
The most thoughtful designs donโt get used if engineering doesn't build them.
The most sophisticated algorithms donโt help people if they can't be put into a clear product.
The tightest roadmap doesnโt get you customers if the experience isnโt good, or you can't sell it.
Your launch date is in a week. Your whole team's credibility is riding on your collective ability to make it happen. Leadership is Eye-of-Sauron-ing this project.
There's just one problem.
You suspect the product sucks.
What do you do? A thread ๐ (1/9)
Prior to a launch, saying "Our product sucks" is not what your tired, overworked colleagues want to hear. But if you feel this way, you need to bring it up.
Align the team around the launch goals. Ask: "What are we aiming for?" Then frame your concern around that.
Ex... (2/9)
"We want to fail fast and get learnings asap" โ Are we well set up to get new learnings if we already know so much is broken?
"We want to make a big splash and get tons of new users" โ Will these new users retain if our product is buggy?
My co-founder Chandra Narayanan's quote has become something of a product-builder's mantra for us: Diagnose with data and treat with design.
There is so much packed into those sentences! Thread going deeper ๐ (1/15)
First: "diagnose with data." The job of data is to help you understand the ground truth of what is going on (with your product, user behavior, the market, etc.)
Typically, we humans run on intuition, a rudimentary kind of pattern-matching. This is insufficient in many cases.
Intuition works if you've studied something deeply (think Serena playing tennis.) But it does not serve you well in:
1) Making decisions for contexts you don't understand 2) Generalizing predictions at huge scale / complexity 3) Optimizing the impact of many tiny decisions