Early versions of products have a rapidly growing backlog as soon as you get through the previous one. Once the product starts nearing the minimum set of features to satisfy one narrow use-case, a new minimum set forms around a different but overlapping set of use-cases.
As such, every decision you make moving forward is a strategic one. It would be easy to go down a backlog based on voting preferences from users. But, now each decision has to considered in terms of what the product ultimately wants to solve amongst a lot of options.
Do you want to be fast? Do you want to solve the problem vertically? Do you need all the bells & whistles? What corners can you cut for now to sharply attack the problem? Do seek new users or bunker down & focus on fewer, retained users? Does the UI need to be excellent?
At least, for me, I tend to focus on making a few users really happy, growing slowly at first, & sharply focus on solving one key problem, keeping burn to a minimum, and ensuring shipping product is extremely fast. The years I got lost the most were when I dropped that focus.
So, my process is: write down the direction & problem you want to solve. Get everyone on the same page. Make a list. Re-rank the list every week. Build & ship frequently. Keep the team small until you reach product-market-fit. If we did our job right, our next hire is in support.
I think early on, I find it valuable to not just satisfy users by achieving the metric I had in mind but often exceeding it. Truly going a bit further than I originally intended to ensure that I really solved the problem. It is easy to trick yourself & work on something new.
