This post is meant to be a guide for current and prospective Warp engineers on our product development process. It walks through the steps engineers should take whenever they want to solve a particular user problem, usually by building a new feature, but it also applies to fixing complex bugs, adding APIs, building infrastructure and so on.
One note on this doc: as with everything at Warp, the biggest guideline is to be pragmatic. For some problems we won’t need a PRD or tech doc, for some we will just need one or the other. The first two steps are important for every problem though.
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.”