Design for a developer tool 2. Priorities

This framework is bottom-up. It's relevant when you implement product thinking in an existing SaaS. When you start from scratch, consider using something like Value Proposition Canvas. To understand why I created the framework in the first place: at Uploadcare we have more than 100 lines in our internal document, so it required sorting if we wanted a clear picture. I will use the File Uploader and Upload API as examples for simplicity.

Features list

1. List your features. Use your docs, pricing, and anything you find appropriate, and combine them into a single list.
2. Pain or task. Why did you build this feature, and what problem do you want to solve? Reality check: if you can give a clear answer, the problem exists. Of course, the best answer is the one you've got during your CusDev sessions.
3. Status quo. What would users do if your service didn't exist? Use the name of the competitor here if it's the only realistic answer. Otherwise, it won't tell you anything about the problem.
4. Type. It's an adaptation of "Candies, Vitamins, Painkillers." Choose based on your answers in the previous steps:
   • Solver — solves the problem: there is an existing process that this feature eliminates or drastically simplifies. Your most valuable features will fall into this category.
   • Unblocker — allows developers to use your service. Integrating without an unblocker would be impossible or pointless for a portion of your audience. Example: language/framework integrations.
   • Enhancer — bigger, better, faster. It's not a novel solution; it incrementally improves existing processes. Example: accelerated uploading.
   • Enabler — It doesn't solve a specific problem but opens a spectrum of possibilities. Example: object recognition.
5. Impact. How many users are affected? Scale: High, Mid, Low. Use actual data when available; otherwise, set it intuitively.

Here's how it's going to look:

Priorities

• High-impact solvers are the easiest to sell. So, when you write about any product part, the first step is to find relevant high-impact solvers and create a single message with them.
• Next — mention all unblockers and place accents by impact.
• The rest depends on the artifact you're working on. You probably don't need to mention the rest of the features if it's a product page. However, the documentation must provide complete data.

I won't mention enablers — they are very rare and require an individual approach. Generally, priorities are:

You can use this method to structure your product pages, navigation, documentation, dashboard — practically anything — with high certainty. Yet, it's true for any such framework: don't follow it mindlessly. When in doubt, trust common sense.