Hey.com launched with fewer features than Gmail. No labels, no filters, no integrations. It charged $99/year for email — a product category where the dominant player is free. Within two months, 300,000 people signed up for the waitlist. They didn't sign up for features. They signed up for Basecamp's opinion that email is broken and should work differently.

Feature parity is a trap

The default indie developer instinct when competing against a larger product is to match features. "Gmail has filters, so we need filters. Gmail has labels, so we need labels." This path leads to a worse version of the existing product, because a solo developer can't out-build a team of hundreds.

Jason Fried at Basecamp puts it plainly: "What's your product's opinion about how the world should work?" If you can't answer that in one sentence, your product is a collection of features competing against collections with bigger budgets. The product point of view indie developers overlook is that the opinion IS the product. Features serve the opinion, not the other way around.

The alternative: have an opinion about how the product category should work and build only the features that express that opinion. Cut everything else. The opinion is the product. Features are just how you express it.

What a product point of view actually is

A product point of view is a specific belief about how a category should work, stated clearly enough that some people will disagree. "Email should be calm" is Hey.com's POV. "Project management should be fast" is Linear's. "Analytics should be private" is Plausible's. Each statement excludes features and users on purpose. That exclusion is the differentiation.

A POV is not a mission statement. "We help teams collaborate better" is a mission statement — nobody disagrees with it, so it differentiates nothing. "Teams collaborate better when they communicate asynchronously, not in real-time" is a POV — some people strongly disagree, which means the people who agree are your exact audience.

Des Traynor at Intercom said it directly: "Great companies have an opinion about how the world should work, and create products that reflect that opinion." The opinion attracts people who share it. The product is just the opinion made functional.

Products with strong points of view

Basecamp: work should be calm, not chaotic. They removed real-time presence indicators, notification badges, and always-on chat. Every removed feature expressed the opinion. Linear: dev tools should feel fast. They made keyboard navigation the primary interface and refused to add features that slowed page loads by even 50 milliseconds.

Superhuman: email should respect your time. They require onboarding with a human coach, auto-archive emails over 3 days old, and show you how many minutes you've saved this week. Buttondown: newsletters should be simple. One text field, one send button, no drag-and-drop editor, no landing page builder. Each product achieved a product point of view indie developers can learn from: state an opinion, build only what supports it, cut everything else.

How to find your product's opinion

Three exercises work. (1) Reverse thinking: describe the product category at its worst. "The worst analytics tool: 47 dashboards, 200 metrics, takes a PhD to configure, sells your data." Flip each element: "One dashboard, 7 metrics, works instantly, owns no data." That's Plausible's product — built from a reversed worst case. (2) Complete this sentence: "Most [category] tools assume [X]. We believe [opposite of X]." (3) List the five features competitors consider essential. Pick two to deliberately exclude and explain why.

The opinion usually hides in what you're willing to remove. Adding features requires no conviction. Removing features that competitors consider necessary requires a point of view about what actually matters.

The product point of view indie builders need

Solo developers have one advantage over large companies: speed of conviction. A team of 200 people debates every opinion. A solo founder can commit to "this product will never have a dashboard" and ship accordingly. That speed of conviction produces focused products that feel intentional.

Tony Dinh built TypingMind with a clear opinion: "ChatGPT's web interface is slow and loses conversations. A native app with local storage is better." That single opinion determined every feature he built and every feature he excluded. He reached $50K MRR in under a year. The opinion attracted exactly the users who shared it.

The product point of view indie builders often miss is that the opinion has to be polarizing. If everyone agrees with your POV, it doesn't differentiate. "Software should be easy to use" is true and useless. "Software should have no settings at all" is polarizing and buildable. The disagreement is the moat.

Building opinion into a habit

Sparks trains the thinking skills behind strong product opinions: reverse thinking (what's the worst version? flip it), assumption-busting (what does everyone assume that might be wrong?), and SCAMPER Eliminate (what can you remove that competitors refuse to?). Daily 5-minute exercises build the reflex of questioning category conventions instead of copying them.