Stop building features. Start building opinions.

Name a product you love. Not one you use. One you love.

I'll bet it has a point of view. It has opinions about how things should work. It says no to things its competitors say yes to. It doesn't try to be everything for everyone. It picks a side and commits.

Now think about a product you "use but could switch from tomorrow." It probably does a lot. It probably has every feature you'd put on a checklist. And it probably has zero personality. Zero conviction. Zero reason for you to care if it disappeared overnight and got replaced by something identical.

That's the difference between a product with opinions and a product with features. One creates loyalty. The other creates indifference.

And most founders, most PMs, most product teams are building the second kind without realizing it.

Features are easy. Opinions are terrifying.

Building features is comfortable. Someone requests something, you build it. A competitor launches something, you match it. An investor asks "do you have X?" and you add it to the roadmap so next time you can say yes.

Every feature feels like progress. Your changelog gets longer. Your marketing page gets more bullet points. Your product gets wider and wider and wider.

But wider isn't better. Wider is just more. And more, without a point of view behind it, creates something bloated and forgettable.

Opinions are different. Opinions require you to believe something. To stake a claim. To say "we think this is how it should work" knowing that some people will disagree. That's scary. Features get applause internally. Opinions get pushback.

A feature says "we added dark mode." An opinion says "we only ship in dark mode because we believe it's better for focused work and we're not going to compromise that for people who prefer light mode."

One adds a toggle. The other tells you what the product believes. You might disagree with the second one. But you'll remember it.

The products you love are full of opinions

Look at the products that have cult followings. Every single one has strong opinions baked into how it works.

Basecamp decided project management should be simple. Not flexible. Not customizable. Simple. They actively removed features that other tools competed on. No Gantt charts. No time tracking. No resource allocation dashboards. Every competitor looked at that and thought "weakness." Every loyal Basecamp user looked at it and thought "finally, someone gets it."

Linear decided that issue tracking should feel fast. Not powerful. Not comprehensive. Fast. Every interaction is keyboard-first. The UI is dense on purpose. They didn't build for people who want to click through menus. They built for people who want to fly through their workflow. If you don't like that, Linear is not for you. And that's the point.

Superhuman decided email is worth $30 a month. While every other email client was free and trying to win on integrations, Superhuman said "email is important enough to pay for, and we'll make it so good that the price feels irrelevant." That price is itself an opinion. It filters the audience. It sets expectations. It tells you this is not Gmail with a skin.

Apple decided you get one charging port. The entire internet lost its mind. Apple didn't care. They had a vision for where the laptop was going and they committed to it years before the market caught up. That's an opinion so strong it survived millions of angry tweets.

None of these products won by having more features. They won by having fewer features and stronger reasons for the ones they kept. The opinions created the product. The features just expressed them.

Why "saying no" is the actual product skill

Every PM talks about prioritization. Frameworks. Scoring models. RICE. ICE. MoSCoW. Whatever acronym makes the spreadsheet feel rational.

But the real skill isn't prioritizing what to build. It's having the conviction to not build things that seem obviously good.

That's a completely different muscle.

Prioritization says "we'll build this feature in Q3 instead of Q2." It's a scheduling exercise. It assumes everything on the list eventually gets built.

Saying no means "we're never building this. It doesn't fit what we believe this product should be. Even though customers are asking for it. Even though our competitor has it. Even though it would probably increase some metric short term. We're not doing it."

That takes guts. It also takes a clear product philosophy. Because without one, you have no rational basis for saying no. Every request seems reasonable. Every feature seems like it could help. You end up saying yes to everything and building a product that stands for nothing.

A product philosophy gives you the filter. When someone asks "should we build X?" you don't evaluate X in isolation. You evaluate it against what you believe. Does it fit? Does it reinforce the opinion we've staked? Or does it dilute it?

That filter saves you hundreds of hours in debates, planning meetings, and "let's discuss this async" threads that never resolve. The philosophy resolves them before they start.

How to find your product's opinion

Most founders I talk to know their product's features. Very few can articulate their product's beliefs.

Here's a simple exercise. Answer these five questions and don't be diplomatic about it.

What do we believe that our competitors don't? Not what do we do differently. What do we believe differently. Doing differently is tactics. Believing differently is identity. If you can't name a belief that would make a competitor say "that's wrong," your product doesn't have a real opinion yet.

What will we never build? Write a "not-doing" list. Things you've been asked for that you're deliberately excluding. If this list is empty, you haven't made any hard decisions. You're just building everything that comes up.

Who is this NOT for? The scariest question. Defining your audience by exclusion forces clarity that defining by inclusion never does. "We're for small teams" is vague. "We're not for enterprises and we'll never add permissions, SSO, or admin dashboards" is an opinion.

If our product could only do one thing, what would it be? Strip away everything except the core. What's the one job this product does better than anything else? Now look at your roadmap. How much of it actually serves that one thing versus how much is drift?

What hill would we die on? Every great product has at least one belief it won't compromise on, even under pressure. Simplicity. Speed. Privacy. Affordability. Beauty. Pick yours and make it non-negotiable. If nothing is non-negotiable, nothing is sacred, and if nothing is sacred, the product will slowly become average.

Write down your answers. Put them on a wall. Reference them in every planning session. I'm not exaggerating when I say this exercise can save a company.

Opinions compound

Here's what nobody tells you about opinionated products: the opinions compound.

When you decide your product is about speed, every subsequent decision gets easier. Should the onboarding be thorough or fast? Fast. Should we add a confirmation dialog? No, that's a speed bump. Should we support complex configurations? No, complexity kills speed. Each decision reinforces the last one.

A product without opinions has to evaluate every decision from scratch. There's no through-line. No momentum. Every feature request opens a fresh debate because there's no philosophy to settle it. Teams spend more time discussing what to build than actually building. Sound familiar?

Opinionated products also attract the right people. Users who share your beliefs become evangelists. They don't just use your product. They defend it. They explain it to others. They feel like it was made for them because, well, it was. You picked a side and they're on it.

Users who don't share your beliefs leave. And that's a good thing. A user who wants your product to be something it's not will generate more support tickets, more feature requests, and more internal confusion than ten users who love what you've already built. Let them find the product that matches their worldview.

Your team benefits too. When the product has clear opinions, designers don't need to ask "what should this feel like?" They know. Engineers don't need to debate architecture trade-offs endlessly. The philosophy guides them. New hires onboard faster because the product's beliefs are legible, not trapped in the founder's head.

Opinions create alignment. Alignment creates speed. Speed creates advantage. It all starts with having something to believe in.

The courage problem

I keep coming back to this word. Courage.

Building features doesn't take courage. It takes effort, yes. Skill, yes. But not courage. You're giving people what they asked for. That's safe.

Building opinions takes courage because you're telling people what you believe, knowing some of them will disagree. You're choosing a smaller audience on purpose because you believe serving them deeply is better than serving everyone superficially. You're leaving money on the table today because you trust that conviction creates more value long term.

Most products fail not because the team lacked talent or resources. They fail because the product tried to be everything and became nothing. It solved every use case poorly instead of one use case brilliantly. It added every feature and lost every identity.

The fix isn't more features. The fix is more courage.

Decide what your product believes. Say it out loud. Build only the things that express those beliefs. Cut everything that doesn't.

Some people will leave. Let them. The ones who stay will love you for it.

That's not a product strategy. That's the only product strategy that actually works.