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.

“We need an ‘export to CSV’ option.”

I ask what you’re going to do with that CSV. You say you might visualize the data somewhere else. Then maybe what you actually need isn’t a CSV, maybe you need better charts inside the product.

When I’m told what to build,
I don’t see a feature. I see an assumption about users that needs to be made explicit.

“Let them choose what they want.”

So we assume they know what they want. Or we assume they have the mental energy to think about what they need from the product. I’d rather test that first.

When I’m told what to build,
I assume we might be solving the wrong problem. Features are often symptoms of a deeper pain point we can’t name yet.

“Let’s make the logic smarter. Maybe then it’ll have a bigger impact on metrics.”

Maybe the real issue isn’t even reaching that point. Maybe users can’t engage with the logic enough yet because they can’t discover it. Let’s first see how it performs for the user group that already discovers it. Funnels, funnels, funnels.

When I’m told what to build,
I check whether we’re doing patchwork to cover a leak quickly or fixing the foundation for the long term. Those two feel similar in the moment, but the former leads to more leaks later.

“Let’s make this field mandatory so we don’t struggle later when we need that input.”

We go live with the mandatory field and then realize all the not-so-edge cases where it simply doesn’t apply. We were too focused on the users we needed that input from. Suddenly, people can’t proceed. They start to churn.

When I’m told what to build,
I try to protect us from building something that looks like progress and feels productive, but isn’t.

It is satisfying to launch something visible. Abandoning it and watching it become a legacy feature that nobody uses or maintains, on the other hand, is sad.

When I’m told what to build,
I remember that my job is to make the call on whether we’re saying yes to the right thing, even when saying no feels harder.

Because every yes closes another door we won’t have time to open.

When I’m told what to build,
I know the real thinking work hasn’t started yet.

But moving fast isn’t the same as skipping the thinking work.

I don’t like rushing to ship because “we’ll figure it out later”. What actually happens is that decisions don’t disappear, they just get postponed. And postponed decisions have a way of coming back at the worst possible time.

Speed, for me, doesn’t mean shipping the most. At best, that’s just a correlation.

Being fast is about closing decisions as quickly as possible. My personal cheatsheet:

Close decisions that are reversible and foundational.

Delay decisions that are irreversible and cosmetic.

In other words, being opinionated enough to move, and confident enough to change course when needed.

For example, I’ll pick a direction early. The first version of an architecture or a user journey. Even knowing it’s probably going to change.

That first decision lets everything else move faster. If new information comes along, I change the decision before it becomes legacy.

There’s nothing wrong with changing direction. In my experience, what slows people down is refusing to make a decision that eliminates other options in the first place.

What do we lose as things become more efficient, more automated, more standardized?

As things scale, a lot of the ad-hoc decisions disappear, for better and for worse. Easier to manage, but harder to adapt. Less chaotic, more predictable. And while everyone is tired of chaos, it’s also where a lot of creativity, judgment, and entrepreneurship come from. When everything is optimized for efficiency, you start losing things that are harder to measure.

We see this in different ways all the time, across products we use and processes we interact with daily. A few examples that came up in our conversation:

• Conversations about scale that turn into rigid buckets, instead of asking what actually needs judgment versus automation

• Automation decisions being made far from where the real context lives

• Edge cases slipping through the cracks because the system wasn’t designed to handle them

• The cost of fixing automation when it’s set up wrong being higher than the cost of doing it manually in the first place

Processes designed to work for everyone, but that no longer feel owned by anyone.

So what is it then? Should we stop automating and making things sustainable? No, not that either.

When we scale decisions too early, we lose local judgment. When we standardize everything, we flatten important differences. And when we optimize for everyone, we often end up serving no one particularly well.

With this conversation, I realized how my mentality changed the same way over time without even putting into words: not everything needs to be uniform to be scalable.

Core flows should scale. Repetition should be automated.

But edges matter. Exceptions matter. Context matters.

Earlier in my product career, I used to look for one ultimate solution. One framework. One formula that would work for everything. Over time, I realized that this mindset misses a lot of important edges. Some things shouldn’t be fully formalized. Some things need room to be handled differently.

How do you decide what to standardize and what not to?

A good rule of thumb:

Standardize what removes unnecessary work.
Automate what’s repetitive, predictable, and doesn’t require judgment.

Automating the obvious

An example of automation done right is order tracking and status updates in food delivery apps.

Once an order is placed, the system automatically updates the user when the restaurant accepts it, when the courier is on the way, and when the order is nearby. These updates follow rules, happen in real time, and don’t require interpretation. Same with ETA calculations, route updates, and basic delivery notifications.

In these cases, automation works because the task is repetitive, predictable, and low-stakes. Users don’t expect a conversation or an explanation. They just want quick information.

Standardization gone too far

On the other hand, an example of over-standardization is how food delivery apps usually handle customer support.

When an order is late, missing items, or incorrectly prepared, customers are routed through predefined support flows. Refunds or credits are decided by rules rather than the specific situation. In edge cases, users feel stuck. The solution works fast for common problems, but breaks down when the issue doesn’t fit the template. It is efficient, but frustration comes from not being able to explain what actually happened.

These are exactly the moments where users expect judgment, and where rigid standardization feels most painful.

Trying to be everything

But be careful not to go too far the other way by focusing on edge cases too much and making the product overly flexible for everyone.

A well-known example of over-flexibility is Evernote. What started as a fast, simple place to capture notes gradually expanded to support many different use cases: tasks, documents, scanning, collaboration, templates, teams. In trying to be flexible enough for everyone, the product accumulated features that most users didn’t need. The result was a heavier product, where basic note-taking became slower and less obvious. The core job of the product, helping users remember everything, became buried under endless options meant to cover edge cases.

They tried to build a product that had something for everyone instead of focusing on a few core user profiles. Over time, many users left for simpler tools that did one thing well. And Evernote just stopped being the go-to choice.

Flexibility only works when the product doesn’t lose sight of what it’s for.

If standardizing something removes repetitive work while preserving judgment, it’s worth scaling.

If it saves time but removes human judgment and nuance, be careful.

We pick preferences during onboarding. We customize settings. We choose goals, interests, themes. Then we see an animation saying, “We’re optimizing your experience.” It feels personal. If you’ve ever used education, fitness, or calorie tracking apps, you know what this is about.

“Choose your goal.”
“Let us assess your level.”
“Tell us what you care about.”

In reality, most of these choices map us into a small number of predefined paths. The core experience barely changes. Customization? Mostly around the edges.

The product learns more from your behavior in the next 10 minutes than from these onboarding answers, but these prompts reduce cold-start anxiety.

But why do they still do it?

To create a sense of involvement and commitment before the experience even begins.

Real customization is expensive. It fragments behavior, ruins comparability, and increases long term complexity. Products need predictability to measure, iterate, and scale. So instead of adapting to each user, they offer something safer:

The perception of control.

But users… they actually like this.

Because full control is a burden. It requires understanding tradeoffs, revisiting decisions, and taking responsibility when things don’t work out. Most people don’t want that. They will say they want it, but they don’t.

What looks like “fake”, or partial customization offers exactly what users need: action without cognitive cost.

You can see this more clearly if you imagine the opposite.

What if Netflix didn’t suggest anything? No ranked rows, no autoplay, no “Top Picks”. Just a giant catalog. It looks like more freedom, but it’s also much more trouble. Most users would scroll, hesitate, and leave.

What if Spotify stopped deciding what plays next, and you had to manually choose every song? What if you had to decide what to learn next in Duolingo?

In all these cases, removing guidance would increase the number of options. But also anxiety, effort, and churn.

If you’re old enough, you probably remember how people used to get hooked on TV channels or radio. You didn’t know what was coming next, you didn’t have much control, and that uncertainty was part of the appeal.

As content moved from broadcast schedules to on-demand formats, first with physical media, and later with streaming, that feeling gradually disappeared.

So instead of removing choice, products started shaping it for you.

People don’t want to design their own experience, even if they claim the opposite. The goal shouldn’t be adapting to every user.

Users want someone to quietly tell them what they need, what they want, and what to do next. So the goal should be to reduce complexity for them.

Give users room to engage, while deciding just enough for them.

Funny how it’s common to hear “AI company” or “AI-based product” now. Back then, I didn’t personally know anyone else working with any type of AI, not even integrations, let alone training their own models. I remember being overwhelmed in the beginning and feeling very incompetent during meetings where we had to talk about results or solutions.

Then the pandemic came. Perfect timing. Staying home all day, all week, I finally had time to learn more. I was working more than 12 hours a day during that period, and I enrolled in online machine learning courses, watching classes at 6am and 11:30pm, yes. Deep learning with Keras, NLP in Python, tree-based models, TensorFlow… In a few months, I finished them all and completed real projects successfully using Python to get my certificates.

I remember nothing.

Well, not as in I don’t understand how these concepts work or what different approaches can be used for certain problems. I still know those today, if not even better. But I don’t remember how I completed those projects, how to actually execute them, or what I would do now if I were given those datasets again.

Even though I don’t regret doing it, I personally think the best way to understand something is to get your hands dirty, I have to admit it wasn’t the smartest move.

Fast forward to today, where “AI” is used by everyone, even though most of the time they refer to LLM-based AI assistants (ChatGPT, Gemini, Claude, etc.) or AI-powered coding environments and product builders (Replit, Lovable, etc.). We can now do in hours what I was trying to do in months six years ago. Product managers can sketch, make prototypes, write scripts, or even build things in hours.

On social media, there are a lot of arguments around this. “Do we really need product managers to become junior engineers or designers by using AI? Shouldn’t they focus on what they normally do instead of shipping low quality engineering work through vibe coding?” I don’t find this a smart argument. If it takes 10 minutes for a product manager to build a prototype to share with engineers, instead of writing a long spec and having a two-hour meeting to explain it, leave them alone and let them do it.

But is this the most important benefit of AI in product management?

I was a product person working in AI, trying to learn the engineering behind it without AI assistants available. Now I’m a product person working in a different domain with multiple AI assistants available. I think I can share my two cents on this:

The biggest change AI brought to my PM work is where I spend my thinking energy.

The improvement curve is exponential. And even next year, what we’ll be capable of doing with AI will probably be unbelievable compared to today. I rarely think about technical limitations now compared to the past. Knowing that technology will follow at some point, I make stronger decisions about what needs to be done rather than fitting ideas into current technical possibilities. I have never felt more empowered and independent in my life as a product person.

While years ago I felt the need to deeply understand tools and how to use them, now I don’t invest heavily in mastering any of them unless they’re core to what I’m doing. I still strongly believe that having skills in at least one or two of design, engineering, or data is a must-have asset in product management. Today, though, it’s more about being able to ask the right questions.

So yes, a product manager must be able to frame a hypothesis and define what success metrics will prove the version they’re testing is successful. But it’s no longer about writing the perfect query to retrieve them, because AI assistants can help whenever they’re stuck.

Similarly, a product manager still needs to understand user behavior. They need to be able to ask questions like which flow reduces churn or where users might get confused. What they no longer need is to describe an experience purely in text. A PM can now use AI to generate a rough flow or interface representation in minutes. With this thinking artifact, designers already have a starting point. It’s up to them how much they pivot from there, but it saves a lot of time and confusion.

Instead of having hypothetical conversations with engineers, product managers can now use AI to sketch a simple logic flow or pseudo-code to explore how an idea might work, even if they’re not technical. It’s not the final solution, and it doesn’t have to be. But it lets them identify bottlenecks, constraints, dead ends, or gaps in logic much faster.

In the story I shared at the beginning, I was chasing execution skills. Today, I believe the skill that matters most is judgment. PMs aren’t becoming engineers or designers, they’re becoming faster at deciding what not to build. This is an era where product managers have never been able to do more product work, and I can’t wait to see what’s next.

“Would you use this?”

“Do you like this idea?”

They sound like the right questions to ask if you want users to agree with you.

But they consistently produce useless answers.

Your users are not lying. These questions just give them nothing real to react to.

Saying “yes” is cheap. It costs no effort, no commitment, no memory. So people say it. Then you walk away feeling validated and build the wrong thing with confidence.

With bad questions, you extract what you want to hear, or what users think you want to hear.

With good questions, you have a chance to uncover real behavior.

Here are some examples of both, to show the difference is not subtle.

Bad:

“If we added a filtering feature, would you use it?”

People will almost always say “sure” to questions like this. It costs them nothing.
Saying yes doesn’t mean they need it, want it, or will actually use it.

What reveals real needs is what they already did when they ran into the problem.

Better:

“The last time you looked at this list, what were you trying to find? How did it go?”

Bad:

“Do you want a page that shows all your metrics in one place?”

This is a “why not” question.
A yes here doesn’t mean it’s the right solution, just that it sounds reasonable in isolation.

Opinions don’t tell you as much as behavior does.

Better:

“How do you currently check your metrics? Walk me through it.”

Bad:

“Is this workflow confusing?”

Yes/no questions kill investigations.
On top of that, framing it as “confusing” subtly puts the blame on the user. People get defensive.

Never make it about their competence. Make it about the product.

Better:

“What part of this workflow took you the longest to figure out?”

Bad:

“Wouldn’t it be easier if this were automated?”

This is a leading question. Don’t do this.
You’re suggesting a solution and offering help. Most people will say yes out of politeness alone.

That tells you nothing about whether they actually need it or would use it.

Better:

“What’s the most annoying part of doing this manually?”

Bad:

“Would you pay for this?”

They can say yes because, again, it’s free to say so.
They might also be trying not to discourage you.

Past behavior is a much better signal than future promises.

Better:

“Have you paid for something to solve this before? What was it?”

Bad:

“How do you usually manage your tasks within the team?”

This is too vague.
You’ll get generic answers that hide all the important details.

Zoom into a real moment instead.

Better:

“What did you do the last time a task was missed by a team member?”

Bad:

“Would notifications help you stay on top of this?”

You’re pushing your solution before understanding the context.
Now the conversation is biased.

First understand how the problem is handled today.

Better:

“How do you currently know when this needs your attention?”

Bad:

“Why didn’t you use this feature?”

Too generic. Most people don’t know the answer themselves.
You won’t get insight without walking through what actually happened.

Better:

“What happened when you tried to use this feature?”

Bad:

“Do you think this is a good idea?”

People try to be nice.
Even when they dislike something, they’ll soften it or avoid saying it directly.

Don’t ask for validation. Create a safer space for honesty.

Better:

“What would make this a bad fit for you?”

Bad:

“Is this problem painful for you?”

If there’s even a chance it might get fixed, people will say yes.
That doesn’t mean it’s important enough to act on.

Look for concrete cost.

Better:

“What does this problem cost you? Time, money, something else?”

Don’t let users speculate. Force them to remember.

When users describe what actually happened, what they tried, where they got stuck, what they did instead, you stop debating hypotheticals and start seeing patterns.

You don’t need users to design your product. You don’t need them to approve your ideas.

Ask about the last time.

Ask about the workaround.

Ask about the cost behind the pain.

Don’t settle for a nice conversation that leads nowhere.