Following is how I usually prioritize in order.

1. Fix unexpected security issues that may be found

2. Implement features that will result in more new users signing up and paying

3. Implement features that will result in existing users paying more than they already are

4. Implement features that will lower churn

5. Implement features that will save the company money such as more automation to reduce manual work

2 to 4 requires you to engage with your customers and get good at filtering out a lot of noise on what some customers may want but the majority may not. Usually if it's going to make the majority of your customers money or save the majority of them money, it's something they will pay more for.

Exactly. I have alpha/beta testers clamoring for new features, and I have them write every single one of them down in a list. I have them reporting bugs, and I have them write every single one of them down in a list. And then I separate that list into "showstoppers" as number one priority, "user-experience" as number two, administrator niceties as number three, and legitimate, completely new features as number four.

Showstoppers means users stop using the product. Either the site is down, core functionality isn't working, it's too slow, etc. If these aren't addressed, there's no point in offering the product. Users are unforgiving, and in most cases you only have one shot.

User experience is making things nicer. Text is too big. Fonts aren't consistent. Page redirects don't go where you expect. Colors are wrong. Minor things that decrease the value the customers are getting translates into major impacts to your pocketbook. The design and finish should be as close to perfect as you can get it.

Admin nice-to-haves are things that end users won't ever see. My admin panel is atrociously designed. But only me and a handful of other people ever see it, so who cares?

Legitimately new features I actually prioritize last. Not because I don't want to offer more, but if the above three things aren't making people happy, more features won't help. And for every feature that gets added, you have to address 1-3 all over again.

What a lot of testers and developers get wrong, I think, is assuming priority #4 comes first. Numbers 3 and 4 may be able to be reversed in some situations or during a sprint, but end-user experience is always priority numbers 1 and 2. Developer/admin experience is lower down the list than a lot of developers/admins might want to believe.

This is a huge problem that will derail your product if you are not careful. My general advice is: "Think about a specific person" for which you are building you are product. And build features that make that single person as happy as possible.

1. What is the engineering effort involved in doing X?

2. How many users does it impact / benefit?

3. What is it's estimated impact on core metrics (Activation/Engagement/Monetization)?

The answer is easy - rank the activities by money made or saved. The really hard problem is the ranking as you don't normally have the perfect information that allows you to calculate the exact dollar value of any change.

More usefully I use two rules.

1. Fix all bugs now. The software should do what it claims to do. If I can't fix a bug (rare) then stop claiming the software does whatever the bug prevents working as a feature.

2. Once 1 is taken care of then work on those things that will bring in the greatest long term value first. I have to say that I mostly do this by feel as I have no good way to get accurate information out of my customers - they often don't know what they want until they see it.

I just launched a new version of my side project last week. So I have this exact same situation. I have to make decisions of what to prioritize.

Here is how I have done it. First I have been asking as many people as I can to try the site and provide their opinion. Indiehackers.com has been super helpful in this regard. Then I try to fix all of the issues that affect the basic functioning of the system. Can people create an account without issue. Can they sign in without issue. Can they create a new food dish without issue.

So tackle all the basics, what is core to the system. After this, try to work on any features that will provide more value to the users, things that will get them to use the system more.

After I finish these, then I move on to the new features.

The technique I personally use, as a full-stack developer, is if I can get features planned out into weekly chunks, segment days to backend vs frontend work, and move forward.

Monday is backend, Tuesday is frontend integration, Wednesday is front-end adjustments, Thursday and Friday are refactoring and further integration days.

Also I batch my issues, so if I'm planning to work on something that day, I'll look for other issues that may be in the same code area. Then I'll work on all of them throughout the day, as I can with primary focus on the issue I started with.

Refactoring happens any time you look at the code if you can see a need.

TLDR:

If you're dishonest, things that will attract buyer's attention the most for the least amount of effort.

If you're honest, things that will both attract buyer's attention the most and provide the most value for the least amount of effort.

As described here: https://taprun.com/articles/product-managers-visual-guide-to...

I don't my PM does.