The first step is to understand what problem you are trying to solve. Often we will talk in terms of building new features – “input-at-top” or “warn before quitting”, etc – but behind each of these features is a user problem – neck strain and accidentally losing work, for example.
We always want to start with the problem, not the solution. So if you are taking on feature work at Warp, you may be pointed towards something that sounds like a solution, but you should always step back and understand the underlying problem and then evaluate if the proposed solution is the right one.
For instance, let’s imagine you’ve joined Warp and your first project is to create a UI for customizing themes within Warp. Note that “Theme-customizer” is very much a solution, not a problem.
The problem, if there is actually one, is that users want to have a nice looking terminal, and that our current themes are limited to a fixed group of presets which might not give the user exactly the look they want.
The solution actually could be a bunch of different things and isn’t necessarily a theme customizer (although it could be). For instance…
The point is that once you clarify the problem we are trying to solve and step back from the initial solution, you can start to come up with alternatives that may actually solve the problem in a better or faster way. Or you may just return to the initial feature idea. But either way it’s always worth thinking through.
We believe that the best product outcomes come when the people building the solution deeply understand not only the problem we are solving but are bought-in on why it needs to be solved now.
So the second question you should ask is “why are we prioritizing solving this problem?” Every feature we invest time in necessarily takes away time from some other effort, so we should generally be able to tie whatever we are working on to our product and prioritization principles.
If we can’t tie it to one of those principles, it might not be strategic to invest time and resources in solving it now. Note though that sometimes those principles are long term and tied to overall business strategy, so it’s not purely a question of what will provide the most value to users most quickly. Sometimes we need to make long-term investments to position the company for success.
So what things can give us confidence that the problem is worth solving now? For starters, we should have some validation that it’s a problem users care about. This often comes from our feedback channels - e.g. github issues, email, discord OR from specific user research through user interviews, surveys etc. If no user is complaining about the underlying problem, that should raise flags.
Keep in mind though that getting explicit user validation is easier for some things than others. For example, it’s relatively easy for things like supporting transparency or tab dragging, which users know they want because they were missing from Warp but present in other terminals. Users are vocal in asking for these improvements.
Getting user validation for more visionary or game changing features is harder. No one was asking for blocks or IDE-style input, but those are some of our killer features. We should generally approach this by showing users mocks and prototypes of how we imagine the feature to work. We are looking for comments like “wow, that’s cool” or “that could be a game changer.”
Even showing mocks can give an imperfect signal. So for these types of features at the end of the day we sometimes need to trust our intuition and vision to say “hey we are all developers and believe this would be useful or game-changing, so even though other developers may not be asking for this solution, we believe they would benefit.” I view these decisions as calculated product risks.
Above all, be pragmatic. Sometimes we will build things that don’t land, and that’s OK. We don’t want to be stuck in analysis paralysis at our stage – we need to gather as much info as we can, make informed decisions, and build and launch quickly.