How to say No to a Client

Client ideas for change or improvement are almost always an indicator of their investment. It can be an investment in the product itself. It can also be an investment in some meaningful aspect of organizational culture or operations to which the product is somehow connected.

No matter which of these motivations leads a client to share an idea or make a feature request, the right response for the product lead is to evaluate the input seriously and reasonably. Whether or not my team and I ultimately support a client idea, the method for addressing it is built on respect for the client. I seek first to understand deeply, consider both the client’s context and the wider business or service context, and then communicate my recommendations to the client.

One example that illustrates how I've done this successfully involved an important stage in the user journey: getting to the first experience.

My organization delivered digital services and products to universities. Their students accessed these offerings via our website, alongside other users who were not connected to a client institution.

As an external vendor, we could not reliably distinguish users from different client universities, or distinguish users who had no connection to a client university from those who did. For this reason, each of our clients had to set up a portal on its domain to authenticate their users before passing them to our site.

While the process worked, it added some complexity for users. They sometimes pointed that out, as did our clients. I studied options for improving the process, including interviewing users about their experiences. Ultimately, I decided that the most efficient and effective course of action was to help my clients write simple and informative instructions that would describe in advance the steps users needed to take. In this way, we would at least not surprise users on their journey.

In most cases, my client partners were happy with this solution. Improving communication with users was a goal we shared. However, one important stakeholder asked why we could not just take a user's signup email address as validation.

I listened, and agreed to study the feasibility of the idea. It was a reasonable request from a person with whom we had a strong relationship. They were very invested in our problem space. They were our ally at their university, which was one of our organization’s oldest clients. They championed our organization in their wider professional circles.

Once I started talking through the idea with our engineers, we saw that friction on the user's access experience was not the only relevant consideration. An email-only approach to this would create meaningful deficits.

Most significant was the effect it would have on our ability to document the use and value of our products and services. Our analytics were extremely reliable because a user's status was validated by their institution's powerful authentication resources. Although users might fail to be validated because they came to our site without using an access portal, any user who did use a portal could be attributed to that university with near certainty.

In addition, we quickly saw that email addresses were not a stable proxy for a user’s identity. While our systems did not allow the same address on more than one user account, it was mutable information. A user could register with one address and then change to another. One could conceivably exploit this to create a series of accounts, each using the same client university email address to register and then changing to another.

Looking more widely to explore how other universities might respond if we made this change, we recalled that some instructed their students to never use their university email address to register for external services. Even without that guidance, users might reasonably hesitate before sharing an email address that could be associated with them relatively easily.

And of course there were numerous edge cases, such as state university systems that that allocated domains and subdomains across campuses and personnel in non-obvious ways.

Taken together, I felt that these findings meant that the request was impractical.

I scheduled a call with the stakeholder to give my response. When we spoke, I began by stating that I appreciated their suggestion, and that I shared the underlying goal of making it easier for students to access our site and services. I also referenced past occasions when this same stakeholder had made suggestions that we had carried forward.

Having affirmed my investment in this person’s ideas and our shared values, I told them that in this case, we had decided that the consequences of their suggested change would outweigh the benefits. I worked through the points listed above.

I placed the greatest emphasis on the effects the change could have on our analytics - and therefore on our reporting. This stakeholder was part of a unit that prided itself on being data-driven. Once I had placed the current user validation system in that context, and we both considered possible effects beyond the end user’s experience, they agreed that the potential gains did not outweigh the likely losses.

Although we did not make this change, the utility of an email address in identifying client university users was clear. I later included that factor as one element in a scoring algorithm I created to detect users whose legitimate connection with a client university had not been validated at registration.