Thread by @HeyChelseaTroy

So, this thread put some ideas on the table about how to approach product & business development from the exec/director angle.

Now let's talk about it from the angle of a product manager, engineer, or designer.

Thread. (this one will be a little bit stop-and-go today :)

https://twitter.com/HeyChelseaTroy/status/1396503832255942656

Once upon a time, during the dawn of the internet era, early web products often came from some college kid. The kid was almost always wealthy & well-connected, but he wasn't MARKET-savvy.

These people, now billionaires, have given beaucoup interviews on how they got started.

/2

Look: I'm as concerned about survivorship bias in drawing conclusions from these interviews as you are. But one thing stands out.

Asked how they got started, they all go "I was playing around and made a thing I wanted to use. Other people liked it. That was literally it."

/3

Compare that to the way tech companies (particularly large ones) endeavor to approach product development today.

Today's product development wants to be "data-driven." The focus is on QUANTITATIVE methods to finding product-market fit, usually by way of...

/4

...interviewing people who use the product, or interviewing people who represent majority groups that the org would LIKE to see using the product.

(Or, if we're brutally honest, attempting to triangulate info about one of these two groups from product surveillance data).

/5

Today's product managers contrast their data-driven approach with that "I built this for me" we heard in interviews with founders from the '90s.

Despite its empirical strategic success, "build for yourself" now gets cast as immature and shortsighted.

What changed?

/6

I think I can articulate a piece of what happened here. Understanding this piece reveals a false dichotomy between "build for yourself" and "build based on your focus group data."

I quoted a thread at the top of THIS thread in which we conclude that...

/7

1. Building for the majority group identified in summary statistics doesn't work for inclusive decisions.

2. Orgs can incur costly failures, and even product irrelevance, by doing that.

3. Orgs can achieve momentous victories by prioritizing MARGINAL business cases.

/8

Now, those of you who have had your coffee already might be getting an inkling of where this is going 😈

Because #1 up there? Building for the majority group identified in summary statistics? That's EXACTLY the trap that modern product thinking can fall into SUPER easily.

/9

But WE'LL GET THERE, LOVES, WE'LL GET THERE

Back to the question: "What changed?"

Well, what changed was who constituted the "marginal case" we talk about in #3 up there.

Stick with me here.

/10

In the 90s, personal computers as a mainstream thing were brand new.

That's when we get the paradigm-shifting "visionary" internet successes—well, and then apple a decade and a half later, but we'll get there, too.

You know where visionary ideas come from?

/11

Let's break this down, because I need you to see this.

We describe ideas as "visionary" when they break from majority logic to imagine a completely different future—one that serves currently unserved needs or poorly served needs in a completely new way.

/12

You know who has unserved needs or poorly served needs?

MARGINALIZED people. People that the current systems ignore or rebuff.

Visionary ideas derive directly from centering people at the margins.

Read it again, please.

/13

Now, what the hell does "centering people at the margins" have to do with wealthy, well connected college kids making shit up for fun?

To understand that, we need to talk about what marginalization meant in the 90s when the consumer web was new.

At that time...

/14

...in situ "applications" like bookstores, post offices, and auctions had a service gap...location dependence.

You had to be AT THE PLACE. That limited access to folks with time & transportation.

That limited access, that is, even for wealthy, well-connected college kids.

/15

The location of these founders might have exacerbated the effect.

See, the U.S. looked different then. The Big Stuff from a STEM perspective was still largely Boston or NYC. Silicon Valley was GROWING, but it wasn't what it is now. Even now, BART lags the MTA and the T.

/16

These founders were in Silicon Valley—often, they were the children of electrical engineers who moved from Boston to do computer hardware research for defense companies.

So...

/17

...for a glimpse of time, these privileged kids experienced a marginalization that the web suddenly made addressable.

By building for themselves, in that glimpse of time, they centered a marginal need—to access resources and communities without being cotemporal colocation.

/18

For that glimpse of time, in other words, because EVERYONE experienced a marginalization that the web addressed, even the most privileged person building for themselves WAS centering a marginalization. WAS visionary.

Now, of course...

/19

...since rich, well-connected white men got to build the web from their dorms and parents' garages, they're already centered there.

Building for already-centered people doesn't produce visionary ideas. Tech has noticed, and so it has discounted "build for yourself."

/20

And THIS, my friends, is the false dichotomy.

Product teams forget the context of the "build for yourself" spirit that they discount in favor of data-driven decisions.

And this has tragically obscured their potential for actual visionary work.

Here's how:

/21

It's not "building for yourself doesn't shift paradigms."

It's "building for yourself doesn't shift paradigms IF you are ALREADY the main character."

Product/design/eng teams are overwhelmingly led by people who are ALREADY main characters in tech.

SO...

/22

Those main characters building for themselves DOES produce incrementalist, weak-willed, un-visionary work.

BUT:

A data-driven approach that centers mainstream opinion ALSO produces incrementalist, weak-willed, un-visionary work!

THAT'S RIGHT, PARTY PEOPLE

/23

OUR BEST PRACTICE DOES THE SAME THING AS THE PRACTICE WE SHAT ON FOR A DECADE!

So what does an individual product manager, engineer, or designer take away from this?

A couple of things. Allow me to enumerate:

/24

1. If you fit the archetype of the web's main character, do not tell, like, a formerly incarcerated black parent not to build for themselves.

"Don't build for yourself" applies to YOU. Not to THEM. Tech systematically rebuffs their needs.

They have vision you don't have.

/25

To generalize that example:

We DESPERATELY NEED marginalized voices to build for themselves if we want to inject vision into our languishing internet of personalized ads decorating stalkery stadiums hosting free-for-all rhetorical cage matches.

https://twitter.com/HeyChelseaTroy/status/1406304986422784002

/26

Apropos of the above, here's the second thing to do:

2. FOCUS product development NOT on what you want, and NOT on what some weird average of your current constituency or desired constituency wants, but on what the MOST MARGINALIZED person needs from your thing.

IN FACT

/27

And I know I've used this example before, but I love it because everybody uses it while completely miscontextualizing it

Remember how I said I'd come back to the whole Apple iPhone thing? People LOVE the 2007 iPhone announcement as an example of vision.

TURNS OUT

/28

Jobs wasn't some kind of genius visionary who independently thought that thing up.

Nope.

All of the things you love about your smartphone started as accessibility features dreamt up by disabled people.

Most famously...

/29

...the iPhones capacitative multi-touch screen that broke the market for existing phones came from FingerWorks, an accessible human-computer interaction company that Apple bought.

Not Apple's idea. Designed for, literally, a disabled mom.

And on YOUR team this means...

/30

...2 things.

In the long term, get marginalized people into seats of power to make product decisions. Not just because it's nice of you, but because ONLY their perspectives can deliver a visionary product in an industry already optimized for mainstream perspectives.

/31

And in the short term, if you don't have that yet, START your product discussion with "Who are we building this for?" And make sure your answer to that question is somebody people don't typically build for.

As I said in the linked thread...

/32

...I built my class for students who typically struggle in graduate classes.

Build your medical insurance app for people who typically struggle to get or use their insurance.

Build your [X] for people who have had it up to HERE with [X].

You'd be SHOCKED how often...

/33

...your fear about losing "your base" by making this decision proves unfounded.

Sure, when you establish a perspective, you might lose a few folks who just have an opposite perspective.

But more often, building for the margins produces something better for everybody.

/34

So, sure. Don't build something for you.

But don't let that push you to build something for NO ONE.

And don't retreat into incrementalism based on your survey data.

Instead, if it's VISION you want, ask "Who is left out of current solutions and why?"

Advocate for them.

/35

Woo! I'm glad you found this helpful.

I wrote a piece about who I am, how it informs my work, and how I apply the ideas in this thread as an engineer currently at @Pocket. If you liked this, you might like that.

Content Warning: gay.

36/36

chelseatroy.com/2021/06/03/wha…