1. Gamechangers vs. Showstoppers vs. Distractions

   • A Gamechanger is a feature that is novel and has a big impact
   • A Showstopper is a bug or feature that brings us to parity with some existing workflow without which a user can't use Warp
   • Everything else is a Distraction, and we shouldn't be working on it right now

2. We should split our focus between Gamechangers and Showstoppers.

   Right now, we have two hurdles to clear with potential users:

   1. I can't use Warp because of X bug or missing feature
   2. I won't use Warp because there's nothing compelling about it beyond my current terminal

   If we just focus on (1) we won't have a good answer for (2). If we just focus on (2), we will have too many people who can't use the product at all. We need a balance of gamechangers and showstoppers.

3. We should always prioritize performance. Helping engineers work faster is a key part of our value prop.

4. We should prioritize features and fixes that are relatively high-impact compared to their effort.

5. We should weigh the product and technical risk of features. Other things equal, less-risky features are better than more risky ones.

   • Product-risk: risk that the feature won't be broadly or deeply useful
   • Technical-risk: risk that we won't be able to build the feature well, or at all.
   • We should actively seek to assess the risk before dismissing it for being too big or too small.
   • For product risk, we should talk to our users (face-to-face if possible). For technical risk, we should prototype.

6. We should always ask who is this feature for? In general we want to build features that solve acute pain points for smaller groups of users rather than lesser pain points for larger groups of users. But solving a large pain point for a lot of users is best of all if we can do it.

7. Above all, be pragmatic. These are principles, not rules.

Ways to think of new features

Let's look for ways to increase the level of abstraction in the CLI - e.g. for our completion engine, it's better if we can make our suggestions in terms of what a user is trying to accomplish, rather than in terms of specific commands and flags.

Telling a story is more memorable than presenting a list of unrelated one-off features. It's much easier for users to understand Warp's unique value proposition via a story. It's also much easier for them to share Warp with their friends. It helps to focus on a theme that is novel to users, such as increased level of abstraction.

Let's try to help users avoid repeating work. So if you set something up once, you have it forever. E.g. if you set up a session or path or completion spec, you do it just once.

Let's think in terms of users being able to share anything they do or create in Warp. Whether it's a theme or a command on an output or a session, we eventually want to make everything shareable.

Let's try to make Warp work as well as possible out of the box, but completely customizable and tweakable for the advanced user. Make the simple things easy and the hard things possible.