by Jugurtha | 2025-06-28 23:47:56+00:00
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.