Your Worldview

Think about how a great magazine works.

It doesn't succeed by covering more topics than its competitors. The New Yorker and Wired could both assign a story on AI. They wouldn't produce remotely the same article. Same subject, completely different worldview. You read a magazine because of what it covers, but you subscribe because of how it sees the world.

That's the thing most people miss about editorial products. It's not just the content. It's the voice. The specific words chosen. The things treated as obvious that another publication would spend three paragraphs explaining. The opinion, quietly embedded in every sentence, about what matters and what doesn't.

The best software works exactly the same way.

Jira vs. Linear

Take project management tools: one of my favorite examples in this journal.

Jira makes every workflow possible. You can configure it to match almost any process, any team structure, any methodology. It's genuinely impressive engineering in service of radical flexibility.

Linear took the opposite position. One workflow. Their opinion of what good looks like, imposed on everyone. No configuration menus, no custom statuses proliferating into chaos, no "make it work for your specific situation." Just: this is how software teams should operate, and we built the tool around that belief.

Linear didn't win because it has better features. It won because it has a point of view. Developers didn't buy project management software. They bought an opinion about how good product development feels.

This is the shift. People don't buy your software anymore. They buy your point of view.

What it looks like in practice

I've been in the room when it goes wrong. A product team, six months into building, sitting around a table trying to answer a support ticket. A user has asked for a feature that sounds completely reasonable. Half the team thinks it belongs. Half thinks it doesn't. Nobody can settle it, because nobody ever wrote down what the product believes. So it goes to a vote, or to whoever has the most political capital that week, and the product gets a little more incoherent.

That meeting happens at most companies. Eventually the product is technically capable, generally fine, and completely forgettable. Nobody can tell you what it's for. Nobody advocates for it. It works, and it means nothing.

I spent the first four hours of my latest project making sure that meeting could never happen.

No code. No designs. No roadmap. Just a set of markdown files: what this product is, who it's for, what it refuses to do, and why. The project is a wealth management app for first-generation wealth (entrepreneurs who just had a liquidity event and are managing serious money for the first time). The space is crowded. Every major bank has an app. There are robo-advisors, portfolio trackers, financial dashboards of every shape.

The first document I wrote wasn't about what to build. It was a never-build list.

No push notifications triggered by market movements. No net worth as the primary home screen metric. No "you're on track" progress framing. No benchmarking against the S&P 500. No gamification of any kind. No feature that generates revenue when the user makes a move.

Each of those is a decision that most competing products made differently. And each one reflects a belief: that the financial industry is structurally incentivized to keep users anxious and active, and that a product built on the opposite premise (one designed to be checked less, not more) is a fundamentally different thing.

That list isn't a constraint. It's the product's worldview made operational. Any engineer, designer, or collaborator working on this can open that document and answer the question "does this belong?" without asking me.

The editorial problem

SaaS isn't dead. Undifferentiated SaaS is dead. Products that compete on feature breadth, that try to be configurable enough to serve everyone, that have no real opinion about what good looks like for their user: those are struggling. That's not a business model problem. It's an editorial problem.

The solution isn't a new pricing model. It's the harder thing: deciding what you believe about the problem space, how you talk about it, what words you use, what you refuse to do, and being disciplined enough to hold that line when a reasonable user asks for something that doesn't belong.

That has always been the job. Most teams just kept avoiding it because the feature race gave them somewhere else to look.

The interesting question isn't what you're building. It's whether someone could read your product (the copy, the empty states, the error messages, the things it refuses to do) and understand what you believe.

If they can't, you're not running a product. You're running a backlog.