[timavr]

Bad customers provide value early on, because they basically do free QA.

Also early there is not enough data to know who are the bad customers or who customers who are having real problems, they all look the same.

The best way to deal with them is just to be honest: "This is not on our roadmap, yes we know issues exists. Here is link to issues forum"

Public issues forum helps a lot, because if issue doesn't have upvotes or comments, they can reason that chances for developers getting to it is nearly zero.

Especially for anything below non pure enterprise 100k+ per customer, there is no way team can address even 2% of issues if there is even hint of PMF.

Even for massive companies like Atlassian and Unity there are public feature requests that have thousands of upvotes and they just don't do them because it is not on the roadmap.

[tonyedgecombe]

Bad customers provide value early on, because they basically do free QA.

Reporting bugs doesn't make someone a bad customer.

[mlyle]

I don't think he's saying that.

But there's a certain kind of nitpicky person you can never make happy.

When your company is young and immature, there's still a decent concentration of actionable feedback in the nitpicks. Eventually it gets harder to mine gems out of it.

[grwthckrmstr]

Aye, you've nailed the point. Early on, a particularly nitpicky and oversharing customer can help identify problem areas or get feedback on the product in greater volume than the quiet, happy users. "Early on" being the keywords here.

[bruce511]

Nit picky can be fine. Even if they are on a free tier. I have some customers that pay me nothing, and are quick to highlight anything and everything. It's frustrating sometimes, but the product is better for it.

A much more serious issue for us is customers who abuse our staff. And these are sometimes high-paying customers. Shouting and swearing on the phone and on site. And worse.

We've learned the hard way to recognise companies with this culture, and actively (but politely) remove ourselves. Even if it costs a significant, potential 7 figure deal.

The bottom line is that our staff are our greatest asset, not the code, and not the customer - and even one staff member leaving over a bad client is a net loss, regardless of the deal.

We haven't fired many, but we've never regretted it.

I should also point out that we differentiate individual bad behavior from company culture. Sometimes we get a different point of contact, but at some companies it's a culture where everyone does the same thing.

[JMTQp8lwXL]

If I was starting a company, I'd prefer to have at least a few nitpicky customers. You might not solve all of their problems, but their over-communication might highlight insightful decisions you could make, that would otherwise be opaque from customers who don't ever talk to you. Emotional, verbose feedback is better than no feedback.

[bobthepanda]

Fun fact: a building in the Seattle campus of Amazon, "lowflyinghawk" is named after a particularly vocal early days customer of AWS: https://blog.aboutamazon.com/amazon-campus/the-surprising-st...

[dannyw]

I think everyone is agreeing with each other. Early on these kind of customers can be a benefit. Later on it may not be.

[Beldin]

The ability to quickly find bugs does not make you a bad customer - the way you treat the company determines that.

I'm not at all convinced that tolerating bad behaviour towards your company is ever a good strategy.

[EGreg]

Actually not just free QA They literally pay you to build what you should be building anyway.

The problem is that you can’t just “fire” bad customers because you don’t want to face a lawsuit. They paid you to launch the results, and you have to be willing to do what it takes to finish development, get it launched and then go and fix the bugs. You can re-use most of that in your SAAS later.

[unishark]

> Actually not just free QA They literally pay you to build what you should be building anyway.

If your customer is a business then their needs and desires are probably unique to a degree. A high-maintenance customer will mak a ton of requests that specialize your product to them only, and be little value elsewhere. If you don't know yet where that line is, that's fine. You can learn as more customers come along. But I certainly wouldn't call it being paid to build what you should be building anyway. More like being paid to operate as an independent contractor while you learn the industry.

[timavr]

I think the discussion here about online recurring payment services, where customers just churn if you ignore them long enough.

One off projects, yep you better do everything what client says and don't forget to chase after them to pay up even if everything is done to spec.

[oriolid]

> Reporting bugs doesn't make someone a bad customer.

Depends on the bug. Complaining about problems with Windows 7 or demanding good performance ancient tablets and netbooks that emulate either 32-bit X86 on ARM or ARM on 32-bit X86 and then complaining loudly in public when these things aren't supported isn't a sign of good customer.

[plasma]

nitpick: If I’ve reached out to support with a problem or idea, don’t tell me to repost it to an idea forum you have, do that for me, I’ve already told you about it.

I’ve often given up at that point when I’m asked to do this.

edit: agree with the rest of your post :)

[anonytrary]

I don't like this either and frankly, it's embarrassing when billion-dollar companies have poor support UX. Like why is the burden on the customer to re-submit their report? This is obviously an internal communications problem that should 100% be solved by the company, and they're just displaying how badly they haven't solved the problem yet.

edit: I like the rest of OP's

[Kiro]

There's no obligation to listen to user feedback. I get over a hundred feature requests from users a month but I don't even respond to most of them.

[anonytrary]

I don't think anyone was saying that, but yes and no.

There is a difference between people telling you there's a fire in your house vs. people telling you what furniture you should get. Bug reports and feature requests should be treated as different beasts in customer support flows.

In any case, it depends on what service you're providing or what product you're selling, whether or not the reports are high-value and would impact the success of your business, what the they're about, etc. The onus is on the company to determine these things for themselves.

The only reason I can think of for redirecting a user is if you're using it as some sort of quality control barrier to weed out the low quality and non-essential reports.

[TallGuyShort]

Sometimes this is done to when they're actually is a contractual obligation. I pay for Microsoft Azure support, for instance. And it's quite common for them to refer me to Github when I have problems using their SDKs, or to just tell me they can't help when the problem lies with a team other than the one that my support case was automatically assigned to. Instead of taking ownership of the issue as a company, I have to resubmit the issue see several different ways hoping to catch the gracious attention of someone who can help.

[timavr]

It is a resources allocation problem.

Support is very linear in nature. More issues you have, more people you need to take in feedback and act on it. For early companies with very MVP products, support can just kill them, because they will spend all day long doing support stuff vs building. By definition their products are going to be bad.

On top of that reporting issue is just 1% of work, because you actually need someone to go and reproduce that issue. If it is a feature request, then it is another massive chunk of work to spec it and even decide to do it or not to do it.

Also when you post it in the forum, it is way easier to get back to and companies will ask to login support tickets with production accout details, so they can actually go back into the logs and match that data.

[nextaccountic]

What's PMF?

[jtokoph]

Product/Market Fit