Saying No To Eighty Percent Of Customer Requests

The year we tried to please every operator nearly broke the product

Last spring a regional VP at a Phoenix operator got on a call with me and asked for one thing. She wanted Plotline to add a free text override on every renewal pricing recommendation, with a note field, routed up three levels of approval before anything reached the resident.

She had the whole thing mapped out. Field placement, who signs off, what the email to the resident looks like at the end. She had clearly thought about it more than most customers think about anything.

I told her no.

Not in those words, and not on that call. But the answer was no, and the reason is the thing I want to write about.

The year we said yes to everything

There was a stretch in 2022 where Plotline said yes to almost every request that came through customer success. We were a young Series A company trying to land logos in a market that does not hand them out easily. When a customer running 40,000 units asks for a feature, the gravity is real. You build it.

So we built. We shipped configurable fields, custom approval chains, a half dozen one off integrations, a reporting module nobody outside of two accounts ever opened. By the end of that year the product had more surface area and less spine. Onboarding took longer. Our own support team could not always explain how a given account was configured.

We had optimized for the next signature instead of the next hundred customers. That is an easy mistake to make and a hard one to see while you are making it.

Most requests are symptoms

Here is the claim, and it is the one I will defend.

Most feature requests are not requests for a feature. They are the visible edge of a workflow problem the customer cannot fully see. The feature is their proposed fix. Your job is not to build their fix. Your job is to find the problem underneath it.

The Phoenix override request is a clean example. She did not actually want a free text field and a three level approval chain. What she wanted was for her onsite teams to stop feeling steamrolled by a pricing model they did not trust. The override was her workaround for a trust problem. If we had built it, we would have shipped a feature whose entire purpose was to let people ignore the core of the product.

The right move was not a new field. It was making the pricing recommendation explainable enough that a leasing manager in a Class B garden style asset could look at it and understand why the number was the number. Fix the trust problem and the override request evaporates. We did the second thing. The override never came up again.

A feature request is a customer doing your product thinking for you, badly, because they only see their corner of the building.

That line sounds harsh. It is not meant to be. Customers should not have to understand your product strategy. They are running buildings. The point is that the request is data, not direction.

How we say no now

We changed how customer success runs intake. When a request comes in, the first question is never can we build this. It is what were you trying to do when you reached for this. That one question kills most feature requests before they reach a roadmap, and it does it without making the customer feel unheard.

About eighty percent of the requests we log never get built as asked. A good portion of them get solved a different way, usually smaller, usually inside a workflow the customer already uses. The customer gets the outcome. We do not get the bloat.

The remaining twenty percent are the gold. Those are the requests that point at something real and unbuilt, the ones where three unrelated operators in three different markets describe the same pain in three different vocabularies. When Tampa and Raleigh and a Sunbelt BTR operator all reach for the same workaround, that is not a feature request. That is a roadmap telling you where to go.

The counterpoint I take seriously

The honest objection is that this posture can curdle into arrogance. A product team that decides it knows better than its customers is one bad quarter away from building things nobody asked for and nobody wants. I have seen vertical SaaS companies talk themselves out of obviously correct requests because saying no had become a personality.

So the discipline cuts both ways. Saying no is not the goal. Understanding is the goal. Sometimes the understanding is that the customer is exactly right and you were slow, and the only correct response is to build the thing fast and apologize for the wait.

The skill is not no. The skill is knowing which is which.

What this actually protects

A vertical SaaS product is a promise that you understand an industry well enough to make a hundred operators faster, not one operator happier. Every feature you build for a single account is a small tax on every other account that has to load it, ignore it, or work around it.

Saying no to eighty percent of requests is a way to keep the promise you made to the other ninety nine customers who were not on the call.

Cole Lamphere is the founder and CEO of Plotline, software for multifamily operations teams. He writes from Charlotte, NC.