How To Decide Which Feature To Build Next

The Temptation of the Shiny Feature

After the render engine finally worked—after I could import a clip, drop it on the timeline, and scrub through without the whole thing crashing—I started making a list of things to add next. The list grew fast. Effects. Transitions. Generators. A glow effect. A cross-dissolve. A text overlay generator. A particle system. Each one felt exciting, like a tangible step toward making TrailStudio feel like a “real” video editor. The render engine was the boring foundation; these were the features that would make people sit up and notice.

But there was a problem. The timeline itself was still awkward to use. Zooming in and out was janky. Navigating a project with more than a few dozen clips felt constrained. Scrolling horizontally through a long sequence was a chore. The workspace—the thing a user would actually spend all their time in—was not good. It was barely adequate. And I was ignoring that in favor of adding glow effects.

I caught myself one afternoon, halfway through implementing a new transition type, and stopped. Adding another transition wouldn’t make the timeline easier to navigate. It wouldn’t make the editor feel better to use. It would just add more polish to a surface that was still fundamentally rough. The transition was a feature. It was useful. But it was the wrong thing to build next.

That moment changed how I think about feature prioritization. Not just for TrailStudio, but for any software. A feature can be valuable in the abstract and still be a mistake to build right now, because the order of features matters as much as the features themselves. The user doesn’t experience a list of features. They experience a workflow. And if the workflow is broken, no number of effects will fix it.

The Order of Features Is Part of the Product

Most feature prioritization advice focuses on the features themselves. Score them by impact, effort, confidence, and you get a ranked list. But the list alone doesn’t tell you what to build first. Two features might both be high-impact, but one enables the other. One might be a prerequisite for users to even notice the other exists. The sequence is part of the product design.

In TrailStudio’s case, the effects and transitions were additive. They made an already-working editor more capable. But the timeline navigation was foundational. It determined whether the editor was even usable for the kinds of projects I wanted people to create. A user who can’t smoothly navigate a 20-minute timeline won’t stick around long enough to appreciate a nice glow effect. They’ll leave before they ever get there.

This is the insight behind user story mapping: you map out the user’s journey from start to finish, and you build the backbone of that journey before you start decorating the walls. The backbone for a video editor is the timeline. Import a clip, drag it, trim it, arrange it, play it back. That’s the core loop. Everything else—effects, transitions, titles, color grading—is an enhancement on top of that loop. If the loop is painful, the enhancements are wasted.

A Simple Framework for What to Build Next

I don’t use a formal scoring system for TrailStudio. RICE (Reach, Impact, Confidence, Effort) is useful for teams that need to make decisions transparently, but as a solo developer, I can hold the trade-offs in my head. What I do use is a set of questions that force me to confront the gap between what’s exciting and what’s necessary.

The first question: Does this feature address a problem that’s currently blocking users? Not a hypothetical problem. Not a problem someone might have someday. A problem that exists right now, for the people who are actually trying to use the product. For TrailStudio, the timeline navigation was a real blocker. Effects were not a blocker—they were an enhancement. The distinction matters because blockers are what cause users to leave. Enhancements are what make users happy once they’re already staying.

The second question: What is the cost of building and maintaining this? Every feature has a tail. It’s not just the initial build time. It’s the testing, the debugging, the refactoring when other things change, the documentation, the support. A feature that’s cheap to build but expensive to maintain might be worse than a feature that’s expensive to build but cheap to maintain. For a solo developer, the maintenance burden is especially important because there’s no one to share it with. I have to ask: can I keep this alive for the next year, or will it become another thing I’m afraid to touch?

The third question: Will this feature make the product more useful for the users I already have, or for users I hope to attract? It’s easy to imagine that a cool effect will bring in new users who are impressed by the feature list. But the users who are already there—the ones who gave the product a chance—are the best source of information about what matters. If they’re struggling with the timeline, that’s the signal. New users will have the same struggle, and they’ll leave just as fast. Building for the users you have is almost always the right call.

The fourth question is the one that’s hardest to answer honestly: Is this feature exciting, or is it essential? Effects are exciting. Timeline navigation is essential. The exciting features are the ones you want to build because they’re fun, they’re visible, they make the product look impressive. The essential features are the ones that make the product actually work. They’re often boring—performance optimizations, navigation improvements, edge cases—but they’re the difference between a tool and a toy. The discipline is to build the essential thing first, even when the exciting thing is calling your name.

Impact Divided by Effort, With a Twist

The standard advice is to prioritize features with high impact and low effort. That’s fine as far as it goes, but it misses the sequencing problem. A high-impact feature that depends on a missing foundation might be lower effective impact than a medium-impact feature that unblocks everything else. The foundation feature might not show up on a simple impact/effort matrix, because its impact is indirect. But it’s the one that makes all the other features possible.

For TrailStudio, fixing the timeline navigation was not a glamorous feature. It didn’t have a wow factor. But it was the feature that made the product usable for real projects. Once the timeline felt smooth, the effects and transitions I’d been planning would have a place to live. They’d be part of a coherent experience rather than decorations on a broken foundation. The indirect impact of the timeline fix was larger than the direct impact of any single effect.

This is why prioritization frameworks need a dimension for “unlocks other work.” Some features are doors. Building them opens up entire rooms of possibilities. Others are just more furniture for the room you’re already in. When you’re resource-constrained, build the doors first.

The Emotional Pull of the Feature List

None of this is easy, because the feature list is seductive. It’s a list of possibilities, and each possibility feels like progress. Adding an effect is tangible. You can see it on screen, show it to someone, get a reaction. Fixing timeline navigation is intangible. It’s just “the editor feels better now.” The user might not even notice why it feels better—they just notice that it does.

There’s also the social pressure. When you show off a product, people ask about features. “Does it have transitions? Does it have color grading? Does it have templates?” No one asks “Does the timeline scroll smoothly?” But that’s the thing they’ll feel when they actually use the product. The feature list is for marketing pages. The workflow is for users. And users don’t care about the feature list. They care about whether the product helps them do their job.

I’ve had to remind myself of this repeatedly. Every time I open my notes and see the list of effects I want to build, I feel the pull. But then I remember the user who’s trying to edit a 30-minute video with a timeline that fights them at every step. That user doesn’t need another transition. They need the timeline to work. And if I build the transition instead of fixing the timeline, I’ve failed that user, even if the transition looks great in a demo.

Putting It Into Practice

The practical result for TrailStudio was a shift in what I worked on. Instead of adding effects, I spent weeks improving the timeline. I fixed the zooming. I optimized the rendering of timeline items so that long projects didn’t lag. I added track resizing and better scrolling. None of this was exciting to build. All of it was necessary.

The effects are still on the list. They’ll get built eventually. But they’ll be built on a foundation that’s solid enough to support them. And when they’re built, they’ll actually matter, because users will be around long enough to use them.

The framework I use now is simple enough to write on a sticky note: Build the thing that removes the biggest obstacle for the user who is already trying to use the product. That’s it. Not the thing that’s most impressive. Not the thing that’s most requested by hypothetical users. Not the thing that’s most fun to build. The thing that removes the biggest obstacle for the user who is already there.

If you don’t know what that obstacle is, talk to your users. Watch them use the product. See where they hesitate, where they get frustrated, where they give up. That’s the signal. Build for that. The features will come later, and they’ll be better because they’re built on a product that already works.

The Next Feature Is Not the Point

The point of a product is not to have a lot of features. It’s to solve a problem well. The next feature you build should be the one that moves you closer to solving that problem for the people who are trying to solve it with your software. That might be an effect. It might be a transition. Or it might be a boring, invisible improvement to the timeline. The boring one is usually the right one. And when you build it, the product gets better in a way that users notice, even if they can’t name what changed. They just know the thing works. That’s what keeps them coming back.