“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.

Here are some actions to get out of common decision fatigue you are going to fall into.

If you can’t decide between UI designs

If the difference is purely cosmetic, colors, spacing, visual style, stop.

This is a low impact decision that looks more important than it is.

Don’t debate taste. Don’t try to prove one is “better”.

Pick whatever:

• helps you launch sooner

• the majority of the team already prefers

• aligns with your existing design system

If it doesn’t change usability or behavior, it doesn’t deserve more time. Ship it and move on.

If you can’t decide between two UX experiences

Stop discussing it in a meeting for a minute.

Build very simple versions of both. Not polished. Just enough to try. Not to launch yet, but to:

• use them yourself

• ask a few colleagues to try them

• watch where they hesitate, get confused, or ask questions

That first hand observation will tell you more in 15 minutes than hours of discussion.

Once one option feels better in practice, start from there and iterate. You don’t need the perfect answer yet, just the one that works better in reality.

If you can’t decide because “we need more data”

Someone asks for more research, more numbers, more validation. Fair. But they can’t say what result would change the decision.

Shortcut, ask one question:

“What result would make us choose the other option?”

If no one can answer, you already have enough data. Decide and move.

If you can’t decide because everyone has a reasonable opinion

Long discussions where everyone is kind of right.

Pick a single decision owner and time box it.

“We’ll discuss for 20 minutes. Then X decides.” Maybe it is you.

Not consensus. Not voting. One person, one call.

This removes fatigue by design.

If you can’t decide because the decision feels irreversible

Let’s be honest, often we just don’t want to be the person who made the wrong call. But what is “wrong”?

Explicitly classify the decision you need to make:

• reversible in a day/week

• reversible after launch

• hard or impossible to reverse

Unless it is in the last category, speed is more important than making the perfect call. Go for it.

If it is in the last category, revisit the decision. It might be too comprehensive. Try breaking it down into smaller decisions until the pieces feel reversible.

If you can’t decide because of edge cases

Force the decision through one core user journey.

“Does this edge case block the primary journey?”

If not, it doesn’t get to delay the decision. It is noise. Visit it later.

If you can’t decide because scope keeps expanding

Write down what this decision is not allowed to include. Simple.

Make it explicit. This decision does not include:

• new personas

• monetization

• mobile, tablet, or other platforms

• localization

• …

If it’s not allowed in, it can’t block the decision.

Decision fatigue usually means the decision is still abstract.

If you make decisions smaller, reversible, and concrete, they stop feeling heavy.

You don’t need better arguments. You need fewer imaginary problems and more real feedback.

Ship something tangible faster than you ship opinions.

Over time, you’ll realize this matters more than being smarter, more experienced, or better at slides.

Stop waiting until you’re confident about users

You can read recipes, watch videos, and imagine flavors all day. But you build confidence by serving food and watching what comes back empty.

Confidence won’t come before exposure. It will eventually come from real experience.

Step by step:

• Write your biggest assumption in one sentence.
  “We believe users will ___, because ___.”

• Decide what would prove you wrong this week.

• Put the smallest possible thing in front of users that creates a real reaction. No survey fantasy.

• Watch what they do. Don’t ask what they would do. They don’t know either.

If you don’t put something in front of users, you’re not learning.

Don’t overcomplicate it to protect yourself

You overplan your trip to avoid uncertainty. Every possible restaurant, every possible scenario…

But the trip only becomes real once you arrive. You adjust based on weather, mood, and energy.

Overthinking edge cases is comforting because it feels like real work.

“But what about…?” is often your fear, dressed as “perfection”. It’s just a way to postpone making the call.

Unless you are:

• breaking something core

• harming trust or safety

• shipping a really bad experience

you can ship something incomplete. Not a half baked product. Just one that doesn’t try to cover every case or please everyone.

Most of your cases are tied to assumptions you haven’t proved yet.

Step by step:

• Define the one core user journey you are validating.

• Forget everything that is not required for that journey to happen.

• Ship to a small group. A beta, a waitlist, just one segment.

• Fix what reality breaks first. Ignore imaginary breakage.

You don’t need a complete product yet.
You need a complete loop. Build, ship, observe, adjust.

Choose one bet, then build a shipping rhythm

You’ve probably failed at least once by trying to overhaul everything at once. New diet, new routine, new goals. You’ve also probably noticed you only succeed when you do one small thing consistently.

Likewise, most roadmaps fail because they try to change everything at once to make it perfect. Don’t try that. It never works. It’s another fantasy people use to feel better about their planning.

Do one thing. Weekly, or whatever rhythm works for you. Just don’t make it quarterly.

Step by step:

• Pick one metric that matters. Activation, retention, revenue. Or whatever makes sense for your product.

• Pick one lever you believe drives it.

• Make one change per cycle to test that lever.

• Note what you learned in one sentence. What backed up your assumption, what proved you wrong.

• Repeat.

By February you probably won’t be more confident. But you’ll be less delusional. And that’s the whole product game.

Some assumptions validate and unlock massive success. Others fail hard, and nothing that comes after matters. Many products, services, or games we know today wouldn’t have survived if one key assumption behind their design hadn’t been validated.

Let’s deep dive into the gaming ecosystem to uncover some of those assumptions and what we can learn from them.

Clash of Clans

The free-to-progress model

Assumption: Players will tolerate long timers if the core loop is rewarding and social.

You can play Clash of Clans for free, and the monetization never directly breaks fairness. The whole model relies on a small percentage of spenders funding the ecosystem while everyone else is willing to grind. And players accept that grind because the game gives them enough reasons to wait.

Timers aren’t just friction, they are part of the engagement loop. Waiting brings players back multiple times a day, which makes clans more meaningful and turns progress into a shared experience. And because spending only accelerates progress, most players tolerate the grind.

Slow progression almost becomes an advantage. It stretches the lifetime value of players instead of hurting it. The game always gives you a clear next step. There’s always another upgrade, another goal, another thing to push toward. That sense of forward momentum keeps players emotionally invested for months, even years.

Pokémon GO

Real-world movement. For a while.

Assumption: Players will physically move in the real world to play a game.

At first it looked like the assumption worked. But was it really the gameplay loop convincing people to go outside and move? Or was it the hype, AR novelty, and nostalgia?

The problem was simple: the assumption wasn’t backed by a sustainable long term motivation. As novelty decayed and there weren’t enough long term goals to justify the effort required to go out and play, which is a hard requirement, the behavior faded.

Microsoft Mixer

A reverse network effect case study

Assumption: If big names move, their audiences will follow, and then smaller creators will follow them.

Now we know that live streaming doesn’t work like that. Viewers don’t choose platforms only based on creators, their friends and community play a big role too. So when Microsoft bought some big creators, it wasn’t enough for the audience to app-hop from Twitch or YouTube.

Small and mid-sized creators didn’t want to rebuild from zero either. Culture and community turned out to be not just sticky but non-transferable.

Diablo III’s Auction House

The danger of optimizing the wrong value loop

Assumption: Players want a safe, official way to trade valuable loot.

Diablo II had rampant item duping, black market trading, and scammers. Blizzard assumed that if they provided a secure trading system, players would love it.

Instead, they replaced loot hunting with loot shopping. The Real Money Auction House killed the ARPG fantasy: the joy of discovery, unpredictability, and dopamine. Because you could buy a better item in seconds. Players didn’t want efficient trading. They wanted meaningful loot drops.

Steam Marketplace

A player driven economy that actually works

Assumption: Players will reliably assign real value to digital cosmetic items and participate in a regulated secondary market.

This is an example where a player driven economy and network effects actually work.

Valve bet on a bold premise: players wouldn’t just collect in-game items but they would trade them, speculate on them, and form a functioning economy around virtual goods. This wasn’t obvious. Most player driven markets collapse due to fraud, inflation, or lack of trust.

But Steam’s Marketplace had two stabilizers:

• A creator ecosystem (Steam Workshop) continually introduces fresh supply and novelty.

• Money stays inside Steam’s economy, increasing spending instead of draining it.

The result: a liquid, self-sustaining trading economy backed by strong network effects.

In the end, every product runs on assumptions. Just make sure yours aren’t shallow. The real user need is usually hiding underneath the one you think you’re solving. Look deeper, test early, and let the truth surprise you.

Stop trying to force frameworks onto an idea you already like

Opportunity Solution Trees, Double Diamonds... They’re great if you’re really exploring user problems or opportunities. But most teams reverse-engineer them to make a solution they’re already attached to look more legit.
Don’t use frameworks to justify your assumptions. They are only there to reveal opportunities for you to develop solutions.

You’ll assume a lot, just don’t get stuck in assumption hell

Momentum matters more than perfectly modeling every edge case.
If you try to map out every scenario, you’ll fall into a black hole where assumptions depend on more assumptions, and once one collapses, everything breaks.
Pick a direction. Ship something. Own the outcome. Adjust as you learn.

Observe and listen without blaming your users

If users don’t understand how to use your product, that’s on you.
Watch how they behave: in usability sessions, in analytics, in support or feedback tickets. Reality always beats whatever you imagined in a meeting room.

Be ready to be humbled

People will complain. Loudly. Sometimes aggressively.
Remember how annoyed you get when YouTube redesigns something? Exactly.
Don’t take it personally. Frustration is a signal. Learn from it. But...

Don’t get carried away by a single piece of feedback

One loud user does not equal the whole market.
Yes, they’ll say they hate the new thing.
Yes, most will get used to it in days if it actually solves a real need.
Stay calm. Ignore the noise, pay attention when it becomes a pattern.

Keep iterating, your first version is never the final one

Except for a few rare cases (yes, even physical products iterate), your first release is not your masterpiece.
Changing what you shipped isn’t failure. It’s part of the process.
Your users will evolve. The market will evolve. If you don’t evolve with them, legacy features will trap you before you notice.

Get comfortable being in the spotlight of criticism

This isn’t like coding in the background. When you build something people can touch and judge, they will judge it.
Don’t jump at feedback from people who aren’t your users. It will very likely pull you in the wrong direction.
But stay humble and listen closely to feedback from the people who might actually rely on your product. That’s where your real learning starts.

Because they wake up thinking about deadlines, resources, and “who’s building what” chaos. So when they feel overwhelmed, they look for someone who can organize that chaos.

A project manager organizes.
A product manager? Not necessarily.

So they think they need a product manager, while what they actually want is someone to track timelines, unblock engineers, coordinate releases, run meetings, and keep everyone on the same page.

Unfortunately, that is execution management, not product management.

A product manager’s actual job is completely different. In very basics:

• define the problem or potential opportunity

• understand the user

• prioritize opportunities

• make trade-offs

• validate assumptions

• decide the route and pivot when necessary

• keep shaping the product so the team builds the right thing

A product manager’s job is to decide what to build in the first place, rather than making sure what’s already been designed gets built on time.

If you are looking for someone to take care of a backlog full of predetermined solutions like:

“add a filter”
“add a button for X”

This is project management territory: organizing tasks.

A product manager should instead ask:

“What problem is this solving?”
“Which user segment is struggling?”
“What is the assumption behind it, and how can we validate it easiest?”

Product manager work is often invisible: “What do you guys even do?”

A project manager’s output is tangible: timelines, documents, checklists.
A product manager’s output is direction. Direction looks like nothing until you compare teams with and without it.

Often you will see product managers given project manager tasks, because instead of delegating product decisions, teams delegate coordination. It feels safer. But when there is no product vision, no strategy, and no clear direction, hiring a product manager can’t fix it.

When product managers are brought in at the wrong phase

Teams often bring in a product manager right before a big launch:
“We need someone to write the specs and manage the rollout.”

But the product manager’s real job is to ask:

“Why are we doing it?”
“What’s the smallest slice we can test before we overhaul everything?”

Many features fail because they were beautifully executed but solved the wrong problem.

Unblocking timelines vs unblocking thinking

Yes, both product managers and project managers reduce chaos, but in very different ways.

A project manager reduces execution chaos.
A product manager reduces decision chaos.

Imagine the team wants to build a complex new dashboard.
A project manager will plan timelines, resources, and delivery.
A product manager will ask, “Do users actually need a dashboard, or do they just need access to one key metric at the right moment?”

If the product manager’s tradeoff decision leads to cutting the full feature into one small validation step, the whole team moves with momentum because the scope is smaller, clearer, and rooted in a real user need.

In the end, helping the team build the right thing is the most valuable thing a product manager can deliver.

Here is why, with 3 real life product examples.

1. Your highlight might not be the product you planned

No matter how well you plan, real usage will surprise you.

Slack started at Tiny Speck, not as a plan to build a communication tool, but as the internal chat system for a game project called Glitch.

When Glitch failed to gain enough traction and was shut down in 2012, the team noticed something important. The internal chat tool worked. It solved real problems like scattered communication, lost context and inefficient collaboration.

So they pivoted. In 2014, Slack launched as a standalone product. What began as a supporting project grew into a global tool now used by millions of teams.

Sometimes the feature you built to support your actual product is the idea worth building instead.

2. Users invent use cases you never planned

Your product may already have market fit, your users may love it, and yet they will still find paths you did not design. The more they use a product, the more they create workarounds to solve problems you never anticipated.

Early on, Twitter had a strict character limit (140) and was built around short messages. But users didn’t always want to stay short. Around 2014, some users started posting sequences of replies to themselves to write longer thoughts in “tweetstorms”. Marc Andreessen was one of the earliest to popularize this format.

It began as a hack. People manually chained tweets together because the product did not support long form content. As “tweetstorms” became normal, Twitter recognized the behavior and formalized it in 2017 as Threads.

What was once a user-created workaround can turn into a core product feature, because real behavior outgrows original design.

3. Early versions are discovery, not the final product

Duolingo started with an unconventional business model: teach languages for free and crowd-source translations.

Early users translated real web content as part of their lessons, and Duolingo sold those translations to partners like BuzzFeed to help localize articles into new languages at scale.

As they grew, they realized what users actually valued wasn’t translation labor, but the learning experience itself. The translation model didn’t scale the way the team hoped, so they moved consumer learning to the center and translation to the background.

They refocused the product on learning: gamified lessons, free for all users. That shift turned into massive growth. Today, Duolingo is the world’s biggest language learning platform.

The first version of a product doesn’t have to be the final one. Sometimes it is a probe.

Launch, observe real behavior, and let usage show you what matters.

Same with studying. Planning your study schedule feels better than actually studying.
Same with learning something new. Watching ten YouTube videos about it feels like the right thing to do instead of simply starting.

I’m not saying you shouldn’t make lists, plans, or consume educational content. I’m saying: be careful with the trap of feeling like you’re moving in the right direction while you’re not taking any real steps toward your goal.

The same thing happens in product development.
We make roadmaps, plan quarters, outline dependencies, create sequences: first this, then that. There’s nothing wrong with roadmaps, they’re great for direction and communication.

But if talking, writing, and aligning takes more of your time than actually building, you’re doing it wrong.

The illusion of progress

This is a form of procrastination. Productive procrastination.
You’re avoiding execution because it feels uncertain or uncomfortable.
Planning, meetings, and roadmap discussions give you a little dopamine hit. It feels like progress, even when nothing has moved.

Feedback velocity

The more time you spend planning, the more you delay real world feedback.
Building and starting from somewhere, anywhere, is the only way to uncover truths you will never get from documents or interviews.

Over-specification

Too much planning locks you into too many assumptions.
And your roadmap will likely fall apart as soon as the first assumption fails.

“We need more clarity”

Do you? Or are you scared to deliver because it opens you up to judgment?
Often “more clarity” is a socially acceptable way of saying “I’m afraid to be wrong.”

Then what should you do?

First, learn to be comfortable with discomfort.
Shipping without full certainty is intimidating, but planning an entire feature set only to drop it later is a bigger risk.

Break things down into digestible pieces.
It becomes much easier to move back and forth when you realize an insight or gut feeling was wrong.

Start pushing.
Start learning from users as early as possible and iterate on top of real signals.