A feature needs a strong reason to exist

We're working on a product with an amazing UI for managing projects. Think Trello but different 🙃

It offers drag and drop, in-place editing, keyboard navigation, etc, all with optimistic UI. The code is well-written and fairly organized, but it is inherently complex.

Recently, we wanted to add a "select multiple tasks and drag them all together" functionality. Before jumping into the code, we did some shaping to devise a solution that would not conflict with all the other user interactions we have.

Then it was time to do a spike to understand how hard it would be to build it. Before I even started coding the prototype, I knew it would make our codebase much more complex. We already have a lot of state management for the drag and drop, in-place editing, and optimistic UI. Adding another layer of state on the same UI would make it exponentially harder to grasp.

There is nothing inherently wrong with adding complexity. If the benefits outweigh the costs by a good margin, we're all for it. The problem in this case is that there is not yet a strong reason for this feature to exist.

The idea came up when we realized we had some time on our hands and wanted to use it to build something. And we feel this feature will be very useful in some cases. But if we're being honest, we still don't know how much so.

There is no user feedback indicating they're losing time dragging multiple tasks one by one. We only have our own experience with the app and a hunch. Nothing wrong with that either. Many of the best features out there were based on hunches and zero user feedback.

Still, something felt off while spiking. It doesn't feel like this hunch is worth the added complexity at this point. Maybe as we frame the problem better, it will.

That's the beauty of a method like Shape Up. It provides great checkpoints where we can decide whether to go ahead with a project or not.

If the stages of development (framing, shaping, building) were not that clear, we might have moved forward with this feature and ended up with a much more complex codebase without a strong reason for it.