Ask HN: How do you decide what to ship each week as a solo founder?

Issues/tickets are split between features and bug-fixes. Positive/Negative. Issue templates that force revealing the job to be done and avoid the XY problem. Get down to root causes, not just the symptom of an issue. The analogy is not to look at the last line of a traceback. If it is a feature, why should it be implemented? Who will it serve? How many complained about it? What do analytics say? What's its impact, and what graph of possibilities does it open?

Prioritize:

- Bugs: monitor exceptions with tools such as Sentry to help prioritize bugs because you get just how many times an exception was raised. The exception traces get buried in logs; you will not notice them if you're relying on logs.

- Features: analytics tools such as PostHog to track usage and non-usage (non-consumption) and find out why customers are not using certain features.

- On-going customer support: How's your customer support? How often do you interact with users? Do you have a Slack/Discord/IRC channel people can get on right away and start ranting about some issue with some screenshots and talk with a human? This both exposes issues you were oblivious to and assigns a weight to issues you were aware of but hadn't ranked: One user who complains about an issue is one thing. Many people complaining about the same issue that prevents them from working is another thing. Use frequency and severity/impact

- On-going customer success: having to hold users' hands to accomplish something could indicate poor UX, which should nudge you to make it more intuitive. The less users need you, the less complex sales become, the more "low touch" the product becomes, the higher the odds people at an organization will adopt your product ("shadow IT", "bottom up"), the higher your chance to really sell into that organization.

- Marketing: when talking with users and when you read what they write and listen to what they say, do they use different words, names, and expressions than what you use? When you watch them use the product without helping them and scream in your head that they can't seem to click on the proper icon even though they just hovered over it and it even had a tool-tip and a label, do you adjust for that in your language?

- Resist the temptation to implement features just because other products have them or just because a few users asked for them. Wanting to please everyone only pleases shrinks. The Sirens always sing for you to jump into a sea of code and you better have wax and rope nearby.

- User feedback does unearth problems, not draw the roadmap. Listening to users' "solutions" (features) is like a physician asking you which prescription to write. I'm not saying to ignore it, but it pays to be very, very careful.

- Features that are interesting are often found looking at the whole journey of a user trying to solve a problem. What is the user trying to do? Why is he using the product to do that? Which steps come before using the product and which steps come after?

Problem solving for features:

The XY problem can be sneaky. For instance, we had built an MLOps platform a few years ago. I was doing "customer discovery" and people worried about data privacy/security and infrastructure capabilities, especially GPUs. In other words, these represented friction and increased the "sale complexity". Some users asked us to offer compute and storage, others rejected the product because it's not open-source and they don't trust it (digging deeper, they were afraid we'd die). I could've taken that and decide to "increase security/privacy", and chase the infra route to reduce that friction, which was what most companies were doing. Instead, I decided to completely bypass it and use the user's infrastructure by integrating with it: the compute jobs would now happen on the user's own clusters and on the user's own data sources without transiting by our platform. Also, we were able to die without losing users' work. That's an example of circumventing a sales obstacle/objection with technical means. Even more so, the rationale was that by going that route (using their own compute and storage), we wouldn't need to find a budget with their CFO, because their compute and storage was already budgeted for. In other words: staying true to orchestration and integrating with the user's infra.

The correct™ way is probably betting on what has the highest theoretical ROI, based on user cohort research and...

I'm not doing it the correct way, I don't want to do it the right way.. it doesn't give me any joy. I'd rather make a bunch of stuff no-one wants, and delete it later than spending time on figuring out what is the correct thing. The process is whatever I feel like doing that day. This is my main motivation for not going back to organized employment.

Of course, that's not the whole picture. The more paying users you get, the more you have to do the things that are burning.. those are usually pretty obvious from feedback from your systems and users. In this context I like to attempt to rank by opportunity costs or costs of delay to figure out what is important.

For my own goal setting I now rarely bother setting anything longer than "What can I incrementally improve in the next 2 hours". My backlogs are full, sort of sorted by some perceived importance (totally adhoc), and varied enough that I usually have something to do that works with my current mood. This definitely doesn't lend itself to moving in one coherent direction, but who cares.. the needle moves, just a bit slower than it would have with more focus.

In the end I think it very much depends what your goal is with going solo.. are you chasing unicorns, or just giving middle fingers to the industry living your best life.

tl;dr Whatever I feel like at any given hour

I actually rotate through phases commented here. Sometimes I work on whatever (or whoever) screamed the loudest. Other times, I lean into what I enjoy building. And I always try to stay aligned with what ml- mentioned about prioritizing based on ROI.

Generally, I try focus on updates that directly impact the user experience and, in turn, loyalty. I still carve out time to experiment with new features (it keeps things fun), but I try to prioritize recurring feedback and issues that cause real friction for users.

In short: if I can keep users satisfied and productive, everything else tends to follow.