They use the Elo rating system, which dynamically calculates a player’s strength relative to other players based on the matches they’ve played. Imagine all players having an imaginary number that says how good they are at the game. If you win, your number goes up a little. If you lose, your number goes down a little.

But it’s not limited to that. It also matters who you beat or lose against. If you beat someone with a much higher number than you, your number jumps much more, indicating you must be really good. Unlike beating someone with a much lower rating than you, your number only goes up a tiny bit, as everyone expects you to win anyway.

It works the same way in reverse. If you lose to someone way better than you, it’s no surprise, your number barely drops. But if you lose to someone way worse than you, oops.

Dating apps used to have a similar rating system too. Tinder publicly mentioned that it used an Elo based ranking system for its users until it announced in 2019 that it no longer did, in favor of a more complex recommendation algorithm.

Early apps knew almost nothing about users, and they had to find a notion of desirability. Elo was a proven shortcut.

Yes, dating apps do rank users by “desirability”, even if it’s no longer a pure Elo score. It’s based on how much they’re swiped right on, and who is swiping right or left on them. Because, you know, being liked by someone who is swiped right on often is a signal of being desirable. And as mean as it sounds, vice versa. Being swiped left on by people who are rarely swiped right on can decrease a user’s ranking significantly.

Swiping, or sending likes, whatever you call it, isn’t just UX, it’s an incredible data generation machine. Instead of manually assigning scores, users trained the models.

You might have heard that Bumble founder and CEO Whitney Wolfe Herd confirmed a few months ago that swiping is going to be history soon. It feels like the optimization target is changing again. About a year earlier, she had also announced that they were working on a new concept focused on understanding users’ emotional attachment and relationship patterns. That includes their past experiences and dating behavior in general.

In simpler words, an app that tries to understand your dating patterns. How likely you are to ghost someone, fall for someone, how attached you get, how quickly you’ll lose interest, or whether you’re likely to commit.

Back then, it was about predicting attraction. Matching, and not really beyond. The new objective isn’t only learning users’ tastes, but also understanding how likely they are to make a relationship work, with the help of AI assistants.

We still don’t know what the end product will look like or how successful it’s going to be. But I can say that it sounds like the natural evolution of personalization.

Maybe, dating will simply be the first consumer product where this shift becomes obvious. It’s going from ranking desirability and predicting attraction to understanding the psychology behind our decisions.

But it won’t stop at dating.

If we step back and look at the bigger picture, products are moving from modeling what we are (skills, demographics, a CV, a bio) to modeling how we behave over time. Static traits to dynamic patterns.

Can’t this be applied elsewhere too?

Imagine recruiting. Not just matching a resume to a job description, but predicting the likelihood of a long-term click with a team. Do they tend to lose interest once the honeymoon phase is over? Do they thrive with autonomy or need structure? Do they confront conflict or avoid it?

Or education. Not just serving you the next topic, but understanding how you actually learn. Do you give up after one failed attempt or push through? Do you learn better from competition or collaboration?

In both cases, the question changes from “what can this person do” to “how will this person behave”.

That’s a much more intimate thing to model.

Preferences are easy to admit to, even to an algorithm. Patterns, motivations, attachment style, that’s the stuff we don’t always know about ourselves. Are we comfortable with products inferring it anyway?

Products used to model our preferences. Now, it looks like they’re trying to model us.

While we expect them to get better at predicting our choices, maybe they’ll get better at understanding the pattern behind our choices, and even influence them.

I don’t think they’ll be the long-term differentiator.

Technology has always become accessible, sooner or later. Like cloud infrastructure and open-source software did.

LLMs are already heading in that direction.

Eventually, most companies will have access to very similar intelligence.

So what happens when everyone has roughly the same brain?

If you assume product advantage came from building better technology, the answer might be confusing.

Deciding what not to build.

Knowing when to act, and when not to.

Refusing to add a feature everyone else would proudly ship because it makes the product worse.

Those decisions still come from the people building around it. AI can generate hundreds of possible interfaces. It won’t tell you which one feels right for your users.

It can suggest five new features. It won’t tell you which one makes your product lose its identity.

As intelligence becomes cheaper, authenticity becomes more expensive.

Competing on opinion instead of technology, maybe that’s where product management is heading too.

“Retention” itself isn’t the thing you actually care about, it’s a measurable stand-in for “people got enough value to come back”. Even your most “industry standard” metrics are just proxies.

A few categories of work resist measurable metric capture:

Foundational work. The value shows up downstream and gets attributed to whatever was built on top of it.

Risk reduction. You can’t easily measure the issue that didn’t happen, the churn you prevented, or the trust you didn’t lose.

Slow moving compounding things. Brand and trust pay off over years, with feedback loops too long to A/B test.

Strategic optionality. My favorite as a product person. Making it easier to have options while moving, keeping a door open. Real value, without a number (yet).

A culture that demands a metric for everything doesn’t just risk leaving these things unmeasured, it can encourage people to stop doing them. You drift toward small, locally optimizable, easily testable work because it’s easier to answer the “what’s the impact metric?” question for them.

So how do you know you’ve got good outcomes without traditional metrics?

Before you build something, see if you can phrase your theory as a simple sentence like this:

“We believe doing X will lead to Y because Z. If we’re wrong, we’d expect to see A.”

It is falsifiable even when it isn’t directly quantifiable. It tells you what you’d expect to observe if you’re right and what would convince you you’re wrong.

Quantifiable means you can put a number on it.

Falsifiable means there’s something you could go observe that would show the idea is wrong.

A goal can have one without the other. “This will boost results by 20%” sounds good because it has a number, but if you can’t actually trace the result back to your work, it can never really be tested. It’s precise and unprovable at the same time.

Instead of hunting for one perfect metric, combine a leading proxy (the thing one step closer in the causal chain that you can observe, like adoption rate, time-to-X, or support request volume) with qualitative evidence that you treat as real data. A collection of imperfect, independent signals pointing in the same direction can be more trustworthy than a single number.

A claim like “We’d know we’re wrong if A doesn’t happen.” has no number in it, yet it’s easy to check. You just go look for the things that would have to be true if it were right.

Name your “this would mean we’re wrong” signal in advance, before you’re attached to the outcome.

Figure out the cheapest thing you could observe that would tell you you’re heading the wrong way, and look at that first. The goal isn’t to be proven right at the end. It’s to find out you’re wrong while it’s still cheap to change course.

And just accept that some calls come down to judgment plus accountability, not measurement.

A good decision can have a bad outcome, and a bad decision can get lucky. If you only ever evaluate the outcome metric, you end up rewarding luck and punishing good judgment.

So no, not every impact is measurable, and the goal isn’t to force a number onto everything. It’s to be rigorous about your causal logic, honest about which signals are proxies, willing to count qualitative evidence as evidence, and comfortable saying “this was a judgment call” when it was one, rather than inventing a metric to launder the judgment into something that looks objective.

Many of tomorrow’s opportunities aren’t measurable before they exist. If we only fund what can be measured today, we risk never creating the conditions for tomorrow's opportunities to emerge.

The more they learn, the narrower they become.

You watch or engage with some content, and you’re shown more of it. Over time, your feeds become filled with the same creators, the same topics, and the same patterns. You’d expect it to work perfectly, as it’s doing what it’s designed to do. But we all end up finding ourselves drowning in the same content over and over.

Recently, Instagram announced a new feature called “Your Algorithm”, which lets users see and modify the topics Instagram thinks they’re interested in.

Reading Adam Mosseri’s thread about it, I realized we might be talking about the same phenomenon from different angles.

His argument is that recommendation systems have become increasingly one-sided. They observe what we click, watch, share, and save, but we have very few ways to tell them directly what we want.

For years, recommendation systems have relied almost entirely on behavior. Which makes sense. Don’t we, product people, love saying “Don’t do what users ask for, watch how they behave”?

Users click, the algorithm learns, they click something similar again because it’s there again, because it’s recommended, and the learning is reinforced. This doesn’t leave much space for new discoveries.

If you suddenly become interested in architecture, photography, or cooking, the algorithm has to figure that out indirectly. It waits for enough hints to appear before adjusting (although I feel like it’s been getting much faster lately).

Giving people a way to explicitly influence that process is a meaningful improvement. Instead of hoping the algorithm eventually notices a change, you can tell it.

But actually, the most interesting part for me was Mosseri’s explanation for why something like this is becoming technically feasible now.

We all know choosing interests isn’t new.

Platforms have been asking users to pick categories for years. You might remember picking them on Pinterest, Medium, or similar platforms. Countless products have done some version of it during onboarding.

The difference is that those ones started with category tags that had to be defined by someone first.

They decided what buckets existed, and users picked from those buckets.

Modern recommendation systems don’t really work that way anymore. Or at least, it’s not that simple.

Under the hood, they’re not organizing content into neat categories like “Photography”, “Travel”, or “Design”. They’re organizing content into enormous mathematical spaces where similar things end up close together.

Mosseri gives a simple example of how a photo of one of Colman Domingo’s outfits might sit close to a video from his stylist about menswear, which sits close to the broader topic of men’s fashion.

Or think about how a video about building a home office might sit close to a desk setup review, which sits close to a productivity creator discussing focus, which sits close to content about remote work.

Algorithms today can understand these relationships. But more importantly, they are able to communicate them to you, instead of fitting them into the best available bucket.

LLMs change this dynamic by translating what recommendation systems already know into language people can understand.

Instead of showing a cluster of coordinates in a vector space, they can potentially summarize those relationships as:

“You seem interested in men’s fashion.”

Or take it even further:

“You seem to enjoy creators who explain complex topics through storytelling.”

“You often engage with content about craftsmanship, especially cooking and woodworking.”

Being able to edit those sounds simple, but it’s actually a pretty significant shift and is different from selecting categories during onboarding.

One is declaring interests before the platform knows anything about you, and the other is reacting to a model that has already spent months or years observing your behavior.

It’s less like filling out a profile, more like reviewing and challenging somebody else’s assumptions about you.

Now with all these new changes, it makes me wonder, if LLMs become the interface to recommendation systems, what else becomes challengeable?

We’re starting to get a chance to edit our content tastes, but maybe tomorrow it’ll be more complex than this.

Imagine sitting in front of your TV on a lazy Friday evening, and instead of just scrolling through countless options until you give up, you just tell it:

“I’m in the mood for something lighter than usual.”

Or imagine instead of getting recommendations based on genres because “you watched” something in the same category, you can explain why you actually liked it, and maybe it was more than its genre:

“I really enjoyed La Passion de Dodin Bouffant, but it’s not because it was cooking-related or French. I like a complex romance set in the late 1800s. What else have you got?”

Knowing what we like is one thing. Understanding why we like it is another. Sometimes, I wonder whether there are patterns in our preferences that we can’t even articulate ourselves, but neural networks eventually might.

I’d be curious to see where that leads.

He was excited, saying that everyone seemed to be hooked on it right now.

And I was hooked by that particular interaction because, first, I love watching people share their obsessions. Second, it made me think that on the surface, nothing about the product was particularly new. Nintendo wasn’t introducing a new world, a new mechanic, or a new franchise. They were bringing back something people had already played decades ago.

So why does that work?

And maybe more importantly, why does it work for some products but not others?

At first, it’s tempting to think the answer is simple. Minimal work, maximum “remember this?” energy, hoping emotional memory does all the work.

If you already have the IP, the proven audience, and much of the original product, bringing it back is cheaper than building something new.

I think that’s partly true.

But the more interesting reason, for me, is that nostalgia can be such a high-ROI strategy because it collapses demand uncertainty, the hardest and most expensive problem in product.

You already know that millions of people paid for it once. They spent hundreds of hours with it. They even formed a kind of emotional relationship with it.

This is fundamentally different from a new product launch, because most products and features don’t even make it past the very first question:

Does anyone care?

Nostalgia gives you a prior.

When Nintendo rereleases Pokémon, they aren’t guessing whether people care about Pokémon.

They already know that millions of people have already paid for it once, spent hundreds of hours with it, and formed an emotional relationship with it.

That’s incredibly valuable information. It gives them the luxury of starting with evidence rather than assumptions and reduces the amount of discovery required.

But there’s a distinction.

Nostalgia can give you a prior on a past version of demand, which is not always reflected in current demand in the same way. That distinction explains why some nostalgia products succeed while others fail.

The common mistake is assuming that because people loved something once, they’ll love it again. Those aren’t the same thing.

The original Pokémon games weren’t beloved only because they were part of people’s childhoods. Nostalgia may bring people back, but the core experience is why they stay.

When nostalgia is for the feeling, not the thing

Sometimes people aren’t nostalgic for the product. They’re nostalgic for the moment, and that’s a much harder thing to revive.

People often say they want the old thing back, but what they actually want is the feeling the old thing gave them.

Those feelings are tied to context.

The game wasn’t just a game. It was summer vacation. It was being ten years old. It was discovering something for the first time.

No rerelease can bring those things back.

So if you misidentify what customers are attached to, you’re likely to revive only the artifact when the attachment was actually to the experience surrounding it.

Atari assumed that nostalgia for the brand would translate into demand for a modern Atari console. To be fair, the emotional memory was there. People remembered Atari as a foundational part of gaming history.

But remembering a brand and wanting to integrate it into your life again are very different things.

Yes, people knew exactly what Atari was, but the context had changed. The original Atari succeeded in a world where home gaming was new. The Atari VCS entered a world already dominated by Nintendo, PlayStation, Xbox, PC gaming, and mobile gaming.

People were nostalgic for what Atari represented, but that didn’t necessarily mean they wanted a new Atari device.

The question worth asking is, what did people actually love about this, and does that value still exist today?

Can you identify the specific characteristics that created the attachment?

Can you separate the product from the moment?

Can you tell whether people miss the thing itself or simply who they were when they experienced it?

Because even if nostalgia reduces demand uncertainty, those are ultimately the questions that determine whether the demand still exists.

Is this product good today, independent of the memory?

If the honest answer is no, nostalgia might delay the judgment. But it won’t prevent it.

For me, gut feeling is mostly pattern recognition. After years of product work, and probably because of how my ADHD brain is wired, I often notice signals and connections before I can fully explain them.

Something feels off, and I just know. A small detail catches my attention in a way I can’t immediately articulate. Everything looks fine on paper, but something nags at me.

Similarly, sometimes I just know something is worth paying attention to. There’s no clear connection to desired outcomes or anything measurable yet, but I can see the value before it becomes measurable and impactful. Eventually it does, and then everybody sees it too.

I don’t believe it’s intuition in a spiritual sense. I think it’s just accumulated experience making it easier for me to match the situation with previous situations and their consequences.

That doesn’t mean my gut feeling is always right. Of course, I can still be wrong.

I still want data. I still want evidence. I just don’t believe every decision has to start with numbers and percentages. Sometimes it starts with a feeling, and then we can (and should) still use data to figure out whether that feeling is actually pointing to something real.

So no, I don’t think gut feeling is an alternative to being metric-driven. I think it’s often what tells you which metrics to go look at in the first place.

In one of my previous articles, I wrote about how Google Image Search was born after an unexpected spike in searches for Jennifer Lopez’s green Versace dress. As I mentioned there, sometimes you notice users need something, or are trying to do something, that your metrics don’t yet capture.

Sometimes you keep working on something because you can already see its value, even though that value doesn’t fit neatly into your current understanding of what success looks like.

Some things are worth pursuing before you fully understand where they might lead. That’s all it is.

It’s legible.

You can turn it into a roadmap, a vision slide, a neat narrative about where you’re headed. It feels safe because it looks like a complete picture.

But real life doesn’t move like that.

A first date is not a marriage in miniature. You don’t meet someone and immediately know who they’ll become to you after grief, success, boredom, distance, or change. The relationship reveals itself through contact with reality. Through time. Through surprise.

Products are no different.

We stand at step 0 and act as if we already know where we’ll be at step 1000.

As if the road ahead is straight.

As if users won’t reshape the product.

As if the market itself won’t change while we’re building it.

Ten-step thinking feels less impressive because it’s messier. It looks like iteration. It looks like uncertainty.

Sometimes it looks like changing your mind. But changing your mind because real experience taught you something isn’t a failure of your vision. It’s the work you were supposed to do.

The map was never supposed to become the territory. It was only supposed to help you walk far enough to discover the terrain for yourself.

Maybe that’s why successful products and most meaningful things don’t need perfection or certainty to begin with.

They need curiosity strong enough to take the next few steps honestly.

No one falls in love by successfully predicting year ten. You get there, if you get there at all, by paying attention to what changes once it becomes real.

And if you don’t, no roadmap could have replaced what experience needed to teach you.

There’s this thing I used to say to myself constantly:

“If only I had the resources.”

“If only I could code everything by myself. If only I had a designer. If only I had more time.”

It was sometimes delusional thinking, sure, but it was also a natural filter. I just didn’t know it.

The gap between idea and execution was wide enough that mostly the real ones survived the wait. You’d sit with something for months, maybe years, and by the time you could build it, either you no longer cared about it or the market had already responded.

That gap is almost gone now. And I’ve been trying to figure out whether to mourn it or thank it.

I think I want to do both. It totally depends on what you do with the speed.

For a product person with ADHD, cheap and quick execution can be both a blessing and a curse. It’s also a hyperfixation hell. The dopamine hit of spinning up a new project is identical whether the idea is good or not. And now you can follow through on all of them. 5am before the gym, 6pm to 1am forgetting about dinner, without even telling anyone.

The old “if only” era made people stay delusional for years. The idea lived in your head, protected, never tested. You never had to find out if anyone cared. I’m not even talking about a long time ago. I’m talking about the near past, where you couldn’t even build an MVP or a fake gate for test users without at least some engineering and design work. You never had to find out if you still cared once the thing actually existed. The dream was safe because it was unreachable, or at least hard to reach.

Now you build on Sunday and might even get the answer on Monday. That’s brutal, but it’s honest.

You finally stop blaming yourself for not following through on an idea when sometimes the answer was simply that the idea wasn’t strong enough to survive contact with reality.

Five open terminal windows isn’t necessarily a sign that I’m productive. It’s a sign that I’ve been asking questions and using projects to answer them.

What I’m actually trying now

I try to use the speed to test, not just to get carried away building and polishing. Launch the thing to a few people before I open another tab. Stay in the loop long enough to hear back.

The friction that used to live between idea and execution now has to live between execution and feedback.

That’s where I’m doing my best to put the pause.

You show something you’ve come up with, like a mockup, a half-built feature, a rough prototype, and before you’ve finished your sentence, someone is already finding the hole in it.

“Yeah, but…”
“What about the case when…?”
“Why didn’t you put…?”

Like a reflex. It’s not even wrong half the time. But it lands like a punch to a bruise.

And if you’ve spent any time building products, you’ve felt the frustration: you’re trying to explore possibility, and the room immediately collapses into critique.

What makes this strange is that it’s the opposite dynamic from the one Rob Fitzpatrick describes in The Mom Test, where the goal is to avoid false positives and force people to reveal truth through skepticism when you share a potential idea. Because by default your friends say “yeah, that’s a great idea” when they mean nothing. Likewise, user interviews can easily skew toward false positives because people are conflict-averse.

But when you show what you’ve actually built, your very first MVP maybe, the room goes forensic. The feedback is too critical, too early, aimed at the wrong question.

Both are failures of calibration. And interestingly, both have the same root:

People respond less to the actual idea, and more to the social and psychological incentives surrounding it.

Our brains are wired to protect

The first explanation is evolutionary, and it’s real even if it’s overused.

Human cognition is dramatically better at spotting what’s wrong than imagining what could be right.

From an evolutionary standpoint, that makes a lot of sense. Missing a flaw could be dangerous. Missing an opportunity? Less so.

The brain is a prediction machine. It runs constant pattern matching against what it’s seen before, flagging deviations. When you show someone a new product idea, their brain doesn’t ask “what could this become?” It asks “where does this break from what I already know works?”.

But the thing is, most of the time, early ideas are, almost by definition, full of deviations from known things. That’s what makes them interesting. But the brain’s risk detector reads “interesting” as “threat”, and if you judge them purely through a risk lens, everything looks broken.

When someone looks at your prototype and says “this won’t work”, usually they’re not evaluating your product’s potential. They’re evaluating it against some implicit reference. Usually a finished product at scale. Maybe with full-time engineers and years of iteration behind it.

The social cost of optimism

There’s a second mechanism running alongside the cognitive one. Being critical is socially safe, and being enthusiastic is not, and I know it sounds counterintuitive. Let me explain.

When you point out what’s broken, you’re protected. If the idea fails, you saw it coming. If it succeeds, you were just being rigorous. There’s no bad outcome.

Pointing out flaws signals intelligence. It shows sharpness, experience, taste.

Besides, supporting an idea, especially an early one, feels riskier, and it might make you look naive if it fails.

When you support something early, when you say “this is actually interesting, here’s why it might work”, you’re exposed. You’ve attached yourself to something unproven.

Which is why random feedback, even with the best intentions, tends to drift toward autopsy mode.

There’s a version where the critic is right

Sometimes it’s you, the builder, who is wrong.

Sometimes the edge case someone raises isn’t premature, it’s actually the core problem.

The early-stage builder is just as capable of distortion as the early-stage critic, just in the opposite direction. Founders are famously prone to over-investment in their own ideas.

The same emotional attachment that keeps you going through hard periods can blind you to signals that something is broken at the root.

Criticism is not bad at all. It’s that most feedback conversations have no protocol, no shared understanding of what mode they’re operating in. No alignment on whether this is an exploration or an evaluation.

Two modes of feedback

There are two fundamentally different things you might need from feedback, and they require completely opposite postures.

The first is oxygen. Early-stage oxygen means:

What’s interesting here?

What could this become?

If this did work, why would it matter?

It helps you see what you’re actually building before you fully know.

The second is pressure testing. This is where “criticism” belongs, but it’s a later-stage question. Once you know what you’re building, you need someone to hit it hard. What breaks? What’s missing? What have you assumed that might not be true?

Expecting people to know which one you need and when is a stretch. It’s on us, product people, to know what we’re trying to validate, and ask accordingly.

Most of the time, you go into a feedback conversation and just say “what do you think?” which is about as useful as asking someone if an outfit works without telling them whether it’s for a wedding, the office, or a night out. The person in front of you has to guess what kind of response would actually help, and they’re running on social defaults.

One of the most underrated skills in product comes in here: knowing exactly what question you’re trying to answer in this moment, and naming it explicitly before asking anyone else to engage with it.

It’s okay to protect the “spark” until it becomes a flame, but we cannot outdo ourselves by being in friendlier rooms only. We can do it by being precise about what we need at each stage, and stopping outsourcing that judgment to whoever happens to be in the room.

The pile-on was predictable. If AI replaces humans, why are we hiring more people to manage it? Ha ha, tech bros, etc.

Here’s the thing though.

The obvious part first

The mockery is lazy, but so is the defense.

When something gets cheaper to produce, you don’t produce less of it. You produce way more. AI makes text, code, and images cheap, so now there’s more of all three and more of everything creates new problems. API bills, inconsistent outputs…

Someone has to care about that stuff. New roles emerge. This is just how it works.

Cloud computing didn’t eliminate infrastructure headaches, it created cloud architects.

Social media didn’t simplify communications, it created a whole profession.

Fine. That’s the easy answer.

But it’s also not simply “AI will create new jobs, so relax”

Because some of these jobs have an expiration date, and the cycle is moving fast enough that you might not even see it coming.

In 2020, GPT-3 came out. And I don’t mean ChatGPT. There was no interface, no “talk to an AI.” You had to apply for API access. Write a pitch explaining who you were, what your company did, why your use case was legitimate. Then wait.

When we finally got in, we were excited. We were building some app ideas and needed content generated at scale. GPT-3 was powerful but unpredictable. You couldn’t just ask it something and trust the output. You needed someone who really understood how to coax it.

We found a guy. He was technically skilled, almost artisanal about it, crafting prompts with this specific structure and logic that got GPT-3 to produce what we actually wanted. We still had to do a lot of cleanup because the results were nowhere near perfect.

It was real work, and he was really good at it.

It was also obsolete within two years.

I’m sure he found new ways to specialize. But the specific skill that made him valuable in 2021 got swallowed by the next wave of the technology. The thing he knew became something the model just did on its own.

So when someone says “prompt engineer” like it’s a stable career path being built right now, maybe. But maybe it’s also just another two-year window.

Nature of the new work itself

More AI-generated content means more noise, which means we need people to filter and verify. More AI-generated code means more bugs, which means we need more oversight. More scale means more cost management.

That’s real work. But there’s a difference between jobs that unlock new capability and jobs that exist because we created a mess. Both count. They’re not the same thing.

The “people said the same about SEO” defense is also doing too much work. The idea that SEO specialists or social media managers both sounded like made-up jobs before they became standard.

Sometimes that’s true, new categories of work look absurd before they become obvious. But sometimes new roles are inflated, or reactive, or straight-up corporate theater. Asking which is which is just a reasonable question.

So no, hiring a token optimization specialist isn’t ridiculous. Something real is forming.

But “technology creates jobs” is an aggregate truth that skips over who gets those jobs, how long the gap lasts, and who absorbs the cost while we wait for the economy to sort itself out.

Who actually gets these jobs? Because it’s not the same people. The junior dev whose tasks got automated isn’t the one optimizing inference costs at a startup. The content writer whose work got replaced isn’t pivoting to “AI output strategist”.

The economy adapts as an aggregate. Individuals don’t automatically adapt with it, and adaptation costs money, time, and access that aren’t evenly distributed.

The economy will figure it out eventually. It always does. The question is just who’s carrying the weight in the meantime, and whether we’re even willing to name them.

The same clunky rows of buttons we used to have before keyboards or even touchscreens, just sort of... floating in space. More elegant, sure. But still buttons.

Kubrick was undeniably ahead of his time, but it still makes me wonder:

Did he not imagine a world without buttons or keyboards? Or did he simply not question them?

The technology around the buttons had leaped centuries forward, but the buttons themselves came along for the ride, unchanged. Nobody stopped to ask if everything else is this advanced, why are we still pressing individual buttons one at a time?

Same thing with the “flying cars” fantasy. For most of the 20th century, “the future” meant flying cars. It was the default vision. Roads, but in the sky. Cars, but with wings. Looking back, it’s almost funny. It’s not a bad idea, but it reveals exactly how we think about the future. We took what we had (cars, roads, the frustration of traffic) and we scaled it up, literally. We solved the surface of the problem without questioning the problem itself.

The real question we should have asked wasn’t really “How do we make cars fly?”, it was “How do we spend less time getting from place to place?”.

Or think about how sci-fi imagined video calls. There’s a whole visual language for it: the big screen on the wall, someone standing in front of it, talking to a giant face. It looks futuristic. But watch it closely and you realize it’s just a phone call. The ritual is completely intact. The formality, the dedicated moment, the “I’m calling you now.” Nobody imagined that video communication would eventually mean someone half-awake in bed, laughing at a meme a friend just sent, a voice note fired off mid-walk. The “container” of the phone call survived even when the technology exploded past it.

When cars first appeared, they were literally called “horseless carriages”, and they looked exactly like carriages. The driver sat up high on a bench, there was no windshield, and the steering mechanism resembled reins. It took two decades before someone thought to lower the body, enclose it, and put the engine where the horse used to be.

It makes me wonder what we’re currently blind to.

And I think the answer, right now, is AI agents.

The dominant way people are building and imagining agents today goes something like this:

“Take a human workflow, replace the human with an AI.”

You get an “AI analyst” that produces the same PowerPoint decks a human analyst would. The interface is the same, the output is the same, the measure of success is:

“Does it do what a person would do, but faster and cheaper?”

This is the horseless carriage moment. We put the AI in the harness.

What gets missed is that the workflows being automated were shaped by human constraints that agents simply don’t have. A human analyst spends most of their time wrangling data into a format that can be communicated, because the bottleneck was always human cognition on the receiving end. Someone has to read the thing. An agent doesn’t need a deck. It can hold the entire dataset in context and just answer questions directly. The slide deck was a workaround for the fact that humans can’t share working memory.

We are using AI agents that “attend meetings”. Summarizing calls, joining Zoom, producing transcripts… The assumption underneath is that the meeting is load-bearing, that it needs to happen and someone (or something) needs to be there. But meetings exist largely because synchronous communication was the only reliable way to get a team on the same page. If you have an agent that can maintain perfect shared context across every person on a project, the meeting might be the thing that disappears, not the thing that gets a better note-taker.

The sharpest version of this is that most AI agent interfaces today are still built around a chat box. You type what you want and the agent responds. That’s the keyboard floating in space. We took the interaction paradigm from messaging apps and search engines and stretched it to cover something genuinely different, because it was the interface we already had.

What the “touchscreen moment” looks like for agents, the interface native to what agents actually are, probably hasn’t been invented yet. Or it has, somewhere, and it’s being dismissed as too weird.

We tend to mistake the symptom for the constraint. We saw traffic and imagined flying cars. We saw buttons and imagined them floating in space. We see slow, expensive human labor, so we’re building faster, cheaper versions of ourselves.

The more interesting question is always, what was the workflow trying to work around in the first place?

If you’re building with AI right now, it’s worth sitting with that question for a moment. What assumptions in your product exist only because a human was doing it before?

My teammates did most of the coding. To be fair, I had little interest in it.

What I did do was sit nearby while they debugged. They’d explain the issue, walk me through the logic, and I’d suggest alternative approaches without ever looking at the code itself. I stayed distant, but I did care about what we were trying to build.

One of them, still one of my best friends, kept pushing me to get more involved. She was convinced that if I could already help without touching the code, I’d be even better if I actually engaged with it.

I didn’t buy it then. For me, the reason I could come up with fixes was because I was able to look at their logic without bias. But in hindsight, she wasn’t wrong.

Back then, I didn’t know what a product manager was. But I was already orbiting that role, focused on outcomes, logic, and user experience rather than implementation itself. Eventually, I found my way there properly.

Fast forward to today.

We’re all watching AI reshape how things get built. You can go from idea to something that works in an afternoon.

That’s intoxicating.

For the first time, we all feel like builders.

But when execution stops being the biggest constraint, we realize that making the right call, deciding what to build and how, has been the biggest bottleneck in product development.

What to build, why it matters, who it’s for, and what makes it actually good. That’s the challenge now. It has always been, but now it’s obvious.

When everything becomes easier to build, it’s also easier to confuse making something with making something worthwhile.

We’re no longer blocked by not being able to build by ourselves, but now we’re distracted by the fact that we can build anything. So we do.

And sometimes it feels a bit like DIY crafts, where halfway through you wonder:

“Why am I even doing this? Didn’t someone already make this better?”

I know, the pleasure is in accomplishing it yourself, not necessarily the outcome.

This isn’t new, and you probably already know what this is: the IKEA effect.

We tend to place a higher value on things we partially create ourselves, even if the end result is objectively worse.

It’s the same reason food companies once struggled to sell fully ready baking mixes. In the 1950s, General Mills introduced “just add water” Betty Crocker cake mixes. Convenient, efficient, and a complete failure. Sales were low.

Psychologists like Ernest Dichter found that the process felt too easy. People didn’t feel like they were really baking. So the company made a counterintuitive move: they removed powdered eggs from the mix and asked consumers to add fresh eggs themselves. Suddenly, sales went up.

When you think about it, it wasn’t really a product improvement. It could even be considered a downgrade. But it worked because people felt like they had actually baked something.

We’re doing the same thing now with AI.

What some people call “vibe coding” was supposed to free us from implementation so we could stay focused on outcomes.

But in practice, we’re getting pulled back into execution. Because we can. Because it feels good and is satisfying.

It’s easier than ever to build something simple, and it’s also possible to build more advanced things than ever before.

Anyone can now build a prototype, but very few of us can build something genuinely better than what already exists. That still takes skill. In many ways, more than before.

The best product people I know aren’t detached from execution. On the contrary, they’re fluent enough in it to make better decisions. Not to do everything themselves, but to understand constraints and what “good” actually looks like in practice.

So now, when I sit in front of Claude, I like to remind myself that I’m not there to invent the wheel.

I’m here to decide which wheels are worth building and where they should go. I’m there to put wheels on the right things, things that used to take a lot more people and time to move, faster than before.

In a world where “everyone” can “build”, what matters is knowing what’s actually worth building, and having the taste and judgment to follow through.

Maybe they do, but most of the time, it’s more explainable than that.

Product intuition is pattern recognition. It’s seeing something and thinking, “this won’t work” or “this could be big”, without being able to fully explain it yet.

Don’t confuse it with a lucky guess.

Your “gut feeling” works because you’ve seen enough adjacent things, become very fast at analogies that aren’t easily seen by others, and your brain is connecting dots faster than you can articulate.

And sorry, but those dots don’t really come from a neat, linear process.

They come from messy thinking. You say half-finished ideas, I say noticing things that seem unrelated until they aren’t.

For a long time, I assumed this was an “area to improve”.

As someone with pretty severe ADHD, as you can imagine, my default mode isn’t structured focus. It’s more curiosity powered by motivation I don’t fully understand, and it’s mostly scattered.

I’ll read something unrelated, it’ll remind me of a feature I’ve seen before, then I’ll get pulled into a different problem, and connect it back to a product decision hours later.

It doesn’t look efficient or even relevant when I try to explain it. It definitely doesn’t look like how we are “supposed” to think. I don’t know how many times I’ve heard “But how is this relevant?” (in ruder or kinder ways) when I try to explain my thinking.

But over time, I realized that a lot of what we call “intuition” or “gut feeling” is just the output of that mess.

And now, with AI and how accessible LLM-based assistants have become, this matters more than it used to.

AI is incredibly good at structured thinking. Give it a defined problem, clean inputs, and it will generate solid, often better-than-average answers. It follows patterns extremely well.

But it’s still downstream of the patterns it’s trained on, and highly dependent on the questions you ask.

It doesn’t wander the same way. It doesn’t get distracted into something irrelevant that later becomes the insight. It doesn’t sit in that uncomfortable space where nothing quite makes sense yet, but something feels off.

That’s still a very human loop (and often a neurodivergent one).

More and more, I hear the question: “What about AI and product managers, will it take over that too?” Who knows. But I can share my take, at least for now.

If your edge is execution, you’re operating in a space that’s becoming easier to replicate. Defining problems, organizing work, moving things forward… These are valuable, but increasingly standardized. Over time, they’re less of a differentiator.

If your edge is pattern recognition built from messy, nonlinear thinking, and sometimes rapid associative thinking, you’re probably playing a different game.

I’m not saying structure doesn’t matter, or that being messy alone is a gift. No.

But if your default is unstructured, scattered thinking, your edge might come from embracing how your brain already works, rather than fighting it.

Maybe it’s time to stop over-correcting that. To allow a bit more mess in the process, see if it leads to better outputs in the end, and recognize that in an AI-shaped world, that mess might actually be the differentiator.

“We don’t sell to pets. We sell to pet owners.”

At first that sounds like a no-brainer. But when you think about it, you start to realize how the end consumer can be very different from the buyer, even if they still influence the decision. After all, you won’t buy the same dog food again if your dog rejects it or gets sick after eating it.

In the talk, he mentioned that most pet food bases are nutritionally similar. The differences are marginal.

Pets don’t compare labels or branding. Yet the market is full of differentiation: “grain-free”, “organic”, “human-grade”.

Why?

Because the product isn’t really competing at the level of the end consumer (the pet), but at the level of the buyer (the human).

Two different goals

In products like these, there are two distinct jobs:

1. The user job
Does the product work? Is it usable? Does it deliver value?

From our example above, does my cat actually eat it? Are there any problems after my dog eats the food? Do they leave food on the plate and stay visibly hungry?

2. The buyer job
Is this a safe decision? Can I trust this? Is this worth paying for?

From the pet owner’s perspective, are the ingredients trustworthy? Is it healthy? Can I feel good about feeding this to my pet?

These are not the same.

It is not only B2B, it’s everywhere

Employees use tools that their companies choose after comparing alternatives in the market, based on cost, security, and scalability.

But this is not only about B2B SaaS or enterprise software. Think about consumer products:

Kids use educational products that schools decide to pay for.

Babies play with toys that their parents choose after deciding what’s best for them.

Kids want what’s fun. But parents or caregivers buy what feels responsible.

That’s why toys are sold as “educational”, snacks as “healthy”, and apps are judged more on safety than engagement.

But does that mean your product should only convince the buyer?

Not quite.

Building for both

Good products explicitly design for both layers:

• The experience layer for the user

• The trust layer for the buyer

The experience layer needs to hold up after the purchase.

Coming back to the pet food example, you need to see basic engagement. Your pet eats the food and doesn’t have any health problems associated with it.

In pet food:

• Taste, smell, satiety for the pet (user)

• Ingredients, price, branding for the owner (buyer)

In software:

• UX, convenience, engagement for the user

• Security, ROI, compliance for the buyer

One product, two value propositions.

Where this balance can go wrong

One way this goes wrong is over-focusing on building the perfect product for the end user while giving buyers no reason to purchase.

User-first products
Loved by users, but struggle to monetize or sell. In other words: great UX, weak business case.

This usually happens when end users have little (or no) say in the purchase, or they aren’t the ones paying.

You design something students love, you even see strong engagement in interviews. But you haven’t given them a way to justify why it’s a safe choice, what educational value it adds, or why parents or schools should pay for it.

This is the same for any product where the users don’t directly have access to the budget. In those cases, you don’t have the luxury of focusing only on end users while ignoring everything else like value proposition or safety if you want your product to monetize.

Another way to fail is over-focusing on branding and persuasion for the buyer while offering little real value to the end user.

Buyer-first products
Easy to sell in the beginning, but poor retention. In other words: strong positioning and brand, weak user experience.

For example, in B2B, many enterprise tools get purchased because they check boxes like “good price”, “compliance”, “security”, and “vendor reputation”. But employees avoid using them because they are slow or frustrating. Over time, they start working around it instead of using it, which makes the solution more costly in the end.

On the consumer side, think about toys marketed as “educational” or “developmental”. Parents buy them, but kids quickly lose interest because they are not really fun.

So who is my customer?

When thinking about any product, I’d ask:

• Who uses it?

• Who pays (or is able to pay) for it?

• Who ultimately decides?

If those aren’t the same person, you’re building one product that needs to satisfy different priorities.

I feel stuck in a cage.

I keep seeing the same types of videos, the same creators, the same kind of music. And by “same”, I mean no nuance. Surface level sameness. Even things I don’t actively like anymore keep coming back.

It wasn’t like this a few years ago.

Back then, it felt easier to come across something unexpected. Now it feels like everything is optimized to keep me in a very narrow lane.

To be fair, I do like personalization. It saves me a lot of time and mental effort. It makes products feel relevant.

Of course, there is a trade-off here.

How much personalization still feels good, considering the discovery that’s lost in exchange?

Right now, it feels like everything is heavily biased toward personalization, at the expense of discovery.

And this isn’t happening by mistake. From a product perspective, optimizing for engagement is simply less risky this way.

The better products get at predicting what you’ll engage with, the more they limit what you can discover.

When a product learns what you like, it naturally starts showing you more of it.

You watched something. You stayed. It worked.

So it repeats.

Over time, this becomes a loop. You see similar content, you engage with it because it’s what’s there, the algorithm becomes more confident, and the feed gets narrower.

At some point, it stops feeling personalized and starts feeling limiting. You churn.

“You are what your recent behavior says you are.”

But that’s not how humans work.

We get bored. Our moods, and even our tastes change. Sometimes we don’t even know what we might like yet.

So what’s the sweet spot?

How do you inject uncertainty without breaking the feeling of relevance?

You don’t have to choose one side. You can design for both.

Netflix does this at the interface level. Yes, most rows are personalized. But you’ll still see “Trending”, “New Releases” or globally popular content. It reminds you that there’s a world outside your profile.

And then there’s TikTok, which takes a different approach. It doesn’t just react to what you like, it actively tests you.

Bytedance, TikTok’s parent company, has openly shared parts of the recommendation framework behind the product. One of the key ideas in its Monolith framework is real-time training. Instead of updating recommendations in slow batch cycles, it continuously learns from fresh user behavior such as watch time, likes, and skips. In their own framing, this helps capture the latest hotspots and allows users to discover new interests rapidly.

In other words, it’s not only reinforcing what already works. It is also built to react quickly to new behavior and surface new content before user taste gets stuck in a narrow loop.

Even when TikTok knows what you are likely to be hooked on, it keeps injecting content that’s slightly outside your known preferences. New creators, new topics, things that might not work.

If you engage, it learns. If you don’t, it moves on.

Think about how a baby develops taste.

If you only feed a child what they immediately like because they rejected broccoli once or twice, you end up narrowing their palate. Sure, meals become easier in the short term.

But over time, they don’t learn to enjoy new flavors. And eventually, even their “favorites” get boring.

The only way to expand their taste and make sure they continue enjoying food is to introduce new things. Not all at once, not aggressively, but consistently. A small bite here and there.

In other words, to learn about your user, you need a little room for doubt instead of staying in the same safe loop.

It will be hit or miss sometimes.

But if you get the balance right, introducing just enough novelty to avoid frustration while keeping the experience relevant, you expand what users can enjoy.

And that’s likely to be reflected in long-term engagement as well.

If a product only shows you what it’s sure you’ll engage with, it blocks itself from learning more about you over time.

And eventually, you stop discovering too.

“What problem are we solving by doing this?”

It sounds smart. With the rise of Opportunity Solution Tree type frameworks, which I personally benefited from a lot, I understand where it’s coming from.

“Let’s not find problems for solutions we fell in love with. Let’s fix real problems.”
For sure.

But more and more, it’s being used as a reflex, without really understanding the idea behind those frameworks.

Not everything valuable starts as a problem

Problem-first thinking works great when something needs a fix or improvement.

A gap you can fill because users are struggling or clearly need something. Improving a flow, or making it easier to do a certain task.

Reducing checkout friction in Amazon, improving team communication in Slack, making file sharing easier with Dropbox. Clear problems, clear improvements.

But not all products exist to fix pain.

Some products exist to create value where none existed before.

Entertainment is the best example:

• games

• streaming platforms

• social media platforms

They create desire, without solving any particular problem.

If your only question is “What problem are we solving?”, there’s a high chance you’ll miss entire categories of products.

Some of the biggest products didn’t solve obvious problems

Before short-form video platforms like TikTok, nobody was saying:

“I wish I could endlessly scroll 15-second clips from strangers.”

Or before social feeds:

“I need a better way to consume my friends’ updates all day.”

If you had asked “What problem are we solving?” too early, those ideas would have sounded weak, if not pointless.

Innovation often looks like a bad answer to that question

Innovative ideas don’t always come neatly packaged as problems.

They sound like experiments, or “this might be interesting”.

Think about things like Stories, first introduced by Snapchat and now everywhere.

At the time, stories wasn’t an answer to a specific user pain point.

Forcing it into a problem statement at that stage would just be a way of fitting it into product frameworks.

Because you don’t fully know the problem yet, or if there even is one, you’re exploring an opportunity.

Post-rationalized problem statements

Let’s be honest.

In many companies or teams, the sequence is usually:

idea → justification → problem statement

We come up with something interesting, then reverse-engineer a “problem” to make it defensible.

So whenever you hear a clean, well-written problem statement behind a successful product, think twice.

There’s a high chance the product didn’t start from that problem.

It likely started from an idea, an experiment, or an opportunity, and the problem statement came later to make it easier to explain.

Opportunity is a valid starting point

There are two legitimate ways to build products, and sometimes they can coexist:

Problem-driven:

• something is hard / hidden / broken → fix it

Opportunity-driven:

• new behavior

• new technology

• untapped desire

Problem-first thinking is great, but it’s not the only valid starting point.

Entire industries like gaming, social, entertainment, and even the creator economy are built on opportunity, not pain points.

A better way to approach it

Not every idea needs a clear problem on day one.

Some ideas need space to prove:

“Is there something here?”

“Do people care?”

“Does this create new behavior or even its own market?”

Because if you always need a perfectly defined problem before you start, it becomes very hard to discover anything new.

Higher engagement.
Better conversion.

More rides, more bookings.

But sometimes the metric you improve is perfectly logical for the product, yet the signal it sends to people is something completely different.

It could be okay if products existed only in spreadsheets, but they exist once they are in culture.

Uber introducing women drivers

Uber recently introduced a feature allowing riders to choose women drivers. Likewise, women drivers will be able to pick women riders only if they prefer to.

The idea is fairly clear. Many women feel more comfortable riding with another woman.

But people noticed lower-priced rides for this option after the rollout.

From a marketplace perspective, and considering how Uber’s pricing works, this likely means one thing: lower demand. Besides, discounts are a common way to encourage people to try a new option.

But that’s not necessarily how the public sees it.

Suddenly the feature looks like rides with women drivers are cheaper.

Which then invites jokes like the viral thread suggesting you’re “risking your life with a woman driver”.

The product may be optimizing feature adoption or adjusting pricing based on demand, but the signal people see can easily turn into a statement about the perceived value of women drivers.

Surge pricing during hurricanes

Another example from Uber is how high prices appear during disasters due to their surge pricing model.

The logic is textbook marketplace design:

• demand spikes

• prices increase

• more drivers are attracted to the area

In theory, surge pricing helps people get rides faster during emergencies.

But during hurricanes and disasters, people are unlikely to interpret this as supply balancing. What they perceive instead is profiting from a crisis.

The optimized metric might be supply-demand equilibrium, but the interpretation becomes opportunism.

Apple Batterygate

Almost everyone heard “Apple slows older iPhones on purpose to force people to buy newer models” from someone at least once, if not thought it themselves.

In reality, as batteries aged, they struggled to supply enough power. To prevent the phone from excessive power consumption and random shutdowns, iOS throttled performance, which could lead to slower app performance overall.

From an engineering perspective, this made a lot of sense.

But as the rumors showed, users didn’t see this as an optimization for their older phones. They saw intentional obsolescence.

Even though the product decision was technically reasonable, the signal it sent damaged trust and made users question the brand.

Apple later introduced battery health transparency and battery replacement programs to address these concerns.

Airbnb’s smart pricing

Airbnb introduced smart pricing recommendations to help hosts increase bookings.

They suggested lowering prices based on demand patterns.

From a platform perspective, this improves:

• booking rate

• liquidity

• marketplace efficiency

But many hosts interpret it differently.

They felt Airbnb was pushing them to undervalue their homes.

The platform-wide metric Airbnb was trying to improve was more bookings. The interpretation at the user level was that Airbnb was trying to optimize its revenue at the cost of the hosts’.

Product Challenge

When product decisions affect people’s identity, safety, or control over their business and revenue, interpretation becomes part of the product.

Don’t blame your users for not seeing the “big picture” and the optimization model behind your decision.

What matters most to them is that single moment when they use your app, or the main reason they use your product:

Their own benefit.

The signals they receive from your business decisions will shape their trust.

When building products, it’s not enough to ask:

Is this the right metric?

You also have to ask:

What story will this decision tell?

Because sometimes the metric improves while the signal quietly moves in the opposite direction.

This won’t be a historical recap of the day. Instead, I want to share a few things that come up often in organizations or life in general.

Let’s have more awareness together.

Women’s day was never meant to be just a celebration

International Women’s Day didn’t start as a celebration.

It started with labor protests and strikes in the early 1900s, when women demanded:

• better working conditions

• fair wages

• voting rights

We’ve come a long way since then.

Many of us work in companies where the culture is respectful and inclusive. Compared to many places and many moments in history, we are in a good place.

But like anything else, progress doesn’t mean what we have right now is perfect.

The mental shortcuts we all use

Bias is often misunderstood. Whenever we mention it, everyone gets defensive.

But it’s not always malicious.
Most of the time, it’s simply a mental shortcut.

Our brains do this constantly to process information quickly. We all have it.

But those shortcuts can create patterns we don’t notice.

For example, try this simple exercise:

Imagine you’re assembling a team for an important project.
You have two candidates: one man and one woman.
Without looking at their qualifications, who do you instinctively assume would be a better planner?

We don’t even notice the assumptions we make every day.

The power of repetition

One of the strongest forces in social life is repetition and reinforcement.

In psychology, this often shows up as a self-fulfilling prophecy.

When someone is repeatedly labeled as confident, capable, or leadership material, they tend to grow into that perception.

The opposite also happens.

If someone is subtly treated as less capable, they often receive:

• fewer opportunities

• fewer high risk projects

• fewer chances to practice leadership

Over time, the environment reinforces the stereotype it started with.

You can see this everywhere.

As a woman, if you grow up hearing that women are worse at driving, there’s a high chance you’ll eventually become bad at driving. And it’s not really about your lack of skills as a woman. You were conditioned throughout your life.

If boys are praised for math, more of them pursue related fields later in life.

If girls are rewarded for being well-behaved, fewer of them speak up publicly.

None of this requires intentional discrimination. Just the power of repetition.

The double standards we rarely notice

A lot of workplace bias appears through language and perception. For example:

When a man does it: Assertive, passionate, confident, ambitious

When a woman does it: Aggressive, emotional, arrogant, difficult

We can also see this in performance feedback.

Research and internal company reviews consistently show patterns like:

Men are given opportunities based on future potential. Women have to prove themselves over and over.

Men’s feedback:

“He has great leadership potential.”

Women’s feedback:

“She’s done a great job in her current role.”

Research has also shown that men get clear guidance on skills to improve, while women get vague, personality-focused feedback that doesn’t offer a path to career growth.

Men’s feedback:

“You should develop your strategic thinking by taking on cross-functional projects.”

Women’s feedback:

“You need to be more confident in meetings.”

Assertiveness is seen as a leadership strength in men, but a flaw in women.

Men’s feedback:

“He’s ambitious and driven.”

Women’s feedback:

“She’s too ambitious and should work on being more likable.”

These differences are subtle, but they accumulate over time.

The question that changes everything

One simple trick helps reveal unconscious bias.

Ask yourself:

“Would I react the same way if a man did this?”

Would I call it aggressive?

Would I question the confidence?

Would I doubt the expertise?

That single question can expose a surprising amount of hidden assumptions.

A few common questions

“Why isn’t there a Men’s Day?”

There is.
International Men’s Day is November 19.

But nobody really knows it, and it shows that nobody feels the constant urge to remind each other what men went through. In a way, that’s a good thing.

Women’s Day exists because historically women faced systemic barriers in:

• voting

• education

• leadership

• economic independence

Acknowledging that history doesn’t diminish anyone else’s experience.

“Isn’t this about merit? Shouldn’t the best person get the job?”

Absolutely.

The goal isn’t to create new advantages for underrepresented groups.

The goal should be making sure assumptions aren’t quietly shaping decisions.

If identical resumes receive different responses depending on whether the name sounds male or female, that’s not really meritocracy.

But we should also recalibrate our definition of merit, good, and bad.

Before I started driving in Istanbul, I was honestly shaking, partly because as a woman I had heard so many times that women are bad drivers. After a few weeks in traffic, I realized most people out there suck at driving. They just tolerate each other.

When a man makes a similar “mistake” to a woman, other men tend to think he’s just taking a shortcut because he must be in a rush, or he’s just being reckless.

But when a woman does the same thing, suddenly it becomes about her skills. She did it because she’s bad at driving.

“But aren’t there other groups facing worse discrimination?”

Yes.

And many women belong to those groups as well. Imagine them.

This argument sounds similar to fundraising for a certain disease and someone interrupting to say, “but there are other important diseases too”.

It’s irrelevant.

Bias often intersects with race, ethnicity, sexuality, disability, and socioeconomic background.

Recognizing one form of inequality doesn’t invalidate another.

What can we actually do?

The good news is the solutions don’t need to be big.

Amplify voices

If someone’s idea gets overlooked in a meeting, repeat it and give credit.

Challenge assumptions

If feedback sounds personality based instead of skill based, don’t accept it immediately. Question it.

Check reactions

Ask yourself and each other:

“Would we react the same way if someone else did this?”

Recognize privilege and pay it forward

Many of us have opportunities others didn’t. It’s not a fault, it’s because someone before us opened a door.

Let’s do it for someone else.

A final thought

Compared to many workplaces and many generations before us, we are in a good place.

And that’s something worth appreciating.

But good conditions don’t stay good automatically.

They improve because we, the people inside them, stay aware.

So maybe the spirit of Women’s Day is simple:

We’ve made progress.

Let’s keep going.

We talk about data. Opportunity cost. User research. Prioritization frameworks.

But behind many decisions, something else is quietly contributing:

Emotion.

You’re human. So are your stakeholders. As long as humans are involved, product work is social.

We defend a feature because someone championed it publicly, and now we’re attached.

We prioritize a roadmap item because it has high visibility, even if it’s not high impact.

We choose a metric to measure success because it reassures what we hope is true, even when it’s not the best signal.

We underestimate how much emotion shapes outcomes.

Ego. I proposed this, so it must succeed.

Insecurity. If their idea succeeds, where does that leave mine?

Fear. If we don’t launch something impressive, we look small.

Identity. We’re an AI company, so everything we build has to “touch” AI.

Status. This project is “cool”. It has executive attention.

It’s human.

When the emotions behind decisions are acknowledged, they become manageable. Like it or not, this is part of product management.

Instead of asking:

“Is this backed by data?”

Sometimes the better question is:

“What feeling is driving this decision?”

You can’t eliminate emotion from product work. But once you understand what’s underneath it, you can manage it deliberately.

We like to think we operate analytically. In reality, product is as psychological as it is strategic.

If this resonated, I’d love to know: where have you seen emotion quietly steer a product decision?

People weren’t looking for articles about the night or critiques of what Jennifer Lopez wore.

They simply wanted to see the dress.

At the time, Google was barely two years old. When you searched for something, you would see a list of ranked blue links. It indexed text. Images were part of the web, but not yet part of the product experience.

The demand was real, but the company was too small to act immediately. Infrastructure was still evolving. Engineering resources were limited. Building a separate image index meant storage costs, crawling complexity, ranking challenges, and real tradeoffs with other priorities.

In the summer of that year, a new graduate hire, Huican Zhu, teamed up with Susan Wojcicki, Google’s 16th employee, who would later become CEO of YouTube. With limited resources, they built and launched Google Image Search in July 2001.

Building image search did not promise immediate impact on revenue. It did not directly improve ad performance. It did not optimize the existing ranking model. From a quarterly planning perspective, other projects could add more direct impact.

If your decision filter is “what moves our key metrics this quarter”, making these types of calls becomes tricky.

But some investments change what your product is capable of doing. They widen the surface area of user behavior. They introduce new modes of interaction. Over time, those modes create entirely new metric categories.

Image search expanded the definition of search itself. It introduced visual intent into a text-first system. That expansion later enabled visual shopping, reverse image lookup, camera-based search, and image-based ad formats. None of those outcomes were guaranteed at the start.

But it didn’t stop Google from investing in Google Image Search because they had one important validation from the start: users were trying to do something the product could not yet support.

As much as metrics are important for measuring success, at the same time, they can be backward-looking if you’re not careful. They measure performance within the current frame. When user behavior begins to stretch beyond that frame, legacy metrics might underrepresent the opportunity.

Investing in these opportunities requires a high tolerance for ambiguity. You might struggle to explain the expected ROI to leadership. The upside is abstract, unlike the very tangible cost of investing in it.

This tension is part of the innovation process.

Some product decisions optimize the existing model and are easier to justify.

Others expand it and are easier to deprioritize.

The lesson from Image Search might seem, at first, to be about chasing viral moments. But the real lesson is recognizing when user behavior signals a structural shift and being willing to fund the capability before the business case is fully formed.

If every investment had to prove itself against the day’s KPIs, we wouldn’t have most of the products we use today.

Sometimes the right move is to back the expansion first and let the metrics catch up later.