Menu Close

Thinking Like a Client

Confessions and Observations from Both Sides of the Table

For over a decade, I have had the opportunity to sit at both sides of the table in the Client/Developer relationship. In all of that time, I have developed a deep sympathy for the difficulties each side faces in working together and forming a healthy relationship. Sometimes I think we forget that our clients come to the table from a very different reality and mental space than we do, so I’ve tried to document a few common realities our clients may face.

It’s Not My Full-Time Gig

In most cases, the project at hand is not the client’s or product owner’s primary or regular job. They are often conducting this project in addition to other responsibilities. This means they may not have as much focus and attention on all of the details as much as you would want, or even as much as they would like. They are often too busy to pay attention to every detail even though it seems to us that such attention is vitally important. They will only be aware of the things we bring to their attention explicitly, and they will only understand them as well as we explain the details. They can’t focus on everything, so we need to be intentional and direct with what truly needs their focus.

I Don’t Do This for a Living

Clients don’t often work on projects the way we do. The pace of our project work cycle may be significantly faster or slower than how they are accustomed to working. The subject matter of building a website or a web-based application, its jargon and common knowledge, may not be as familiar (or may even be completely foreign) to them. The very nature of working on a large, complex project could be wholly new to them.

When Is My Client Training?

We take a lot of our own understanding and familiarity with these aspects of our jobs for granted, too often forgetting that our clients are coming from a very different reality than ours. If a client has never worked in an agile environment before, why would we have any expectation that they know how to be a Product Owner, let alone how to perform that role well?! If they’ve never written a user story or acceptance criteria, why would we expect them to know how to do that, let alone how to do it well or even know what user stories are productive to write? If a client isn’t accustomed to thinking through all of the conditions, ramifications, and dependencies of a requirement, how can we expect them to write good acceptance criteria, or even reliably evaluate the acceptance criteria we write for them?

I Hired You for a Reason!

Clients hire us to for the brains they don’t have, which is not to say they don’t have brains – they just don’t know all the things we know. They hire us to add the intelligence, experience, and expertise they lack. They pay us a premium for the advice and guidance we can offer. If they simply needed someone to document all of their requirements and then build a thing to satisfy that list of requirements, they could more efficiently and cost-effectively export that work to Asia and Eastern Europe. They hire us for our brains, and if we aren’t actively using them and sharing our insight every day in the project, then we aren’t delivering what we were hired to do. More than the high quality of our work product, it is our insight and advice that our clients need from us in order to make good choices about what that product should be.

Explain It to Me Like I’m 4 Years Old

Again, this is not to say that clients are stupid or need to be addressed in over-simplified, dumbed-down language — just the opposite in fact — most of our clients are highly intelligent and will quickly recognize and resent any attempts to speak to them as if they are ignorant. By the very nature of being intelligent, clients require sound, reasonable explanations of our advice. They need and want to understand.

Good advice means taking the time to talk. Good advice cannot be shared by simply taking the actions for the client without explanation. Good advice is not expecting the client to understand its value simply on the merits of the idea or by its mere suggestion (or even by our recommendation). It is not enough to say, “We recommend it.” We should understand that our clients need our guidance, but not be so vain as to expect them to swallow it whole without question. Would you take advice in such a manner? Good advice does not happen by documenting a list of caveats or conditions or risks and simply sending them to the client, or directing them to such documentation in a wiki or a Google doc. These tactics are rooted more in “covering one’s ass” for when it becomes clear the client DID NOT understand the advice they were taking, so we can point to them and say, “But we documented it all here and provided you with access!”

For good advice to work, two conditions are required: 1. an honest conversation needs to happen; 2. the client needs to understand the advice, its reasoning, impacts, benefits, risks, et al. Without those two things, the advice is not actionable, and is therefore useless. For all of our collective brilliance and our expertise within our specific disciplines, we all need to be more effective communicators – otherwise the real value of our brilliance can be lost.

I’m Being Vague Because I Can’t Be Specific

It is easy to make generalizations about the client-developer relationship, such as, “Developers like specific, but clients prefer vague.” While developers do ultimately need specific direction (because you can’t code to vague requirements), clients don’t actually prefer to be vague. They just can’t help but be vague because they don’t have all the information they need to be specific. If clients knew how to better explain their circumstances, they would say things like:

“I haven’t thought through this feature enough to give you the detail you need, and honestly I could use your help thinking through it.”

“I don’t understand what is possible well enough to give you the specificity you need. If you explain to me what is possible, I can begin to give you some more detailed instruction.”

“I don’t have all the information I need to give you the specificity you require, but let’s just accept that at this point our understanding is rough and, with your help, I will work to provide more detail.”

Unfortunately it is not always the case that a client knows how to express their situation in terms so convenient for you to understand and accommodate. That being the case, it is important that we recognize when our clients are in this positions, and offer to help them work through issues they can’t yet fully grasp.

My Calculator Lacks an ROI Button

I know from the personal experience of hiring development firms and contractors that despite every intention of making good decisions in a project, clients often are unable to make the best decisions possible. The most common reason for this, in my experience, is that clients can’t make informed decisions because they lack the necessary information (and, even more so, the analysis of that information) in order to make a good choice.

Here is a good example: very few clients have the tools and experience to measure the value of what they think they want. In other words, clients don’t have the data and analysis to evaluate whether the cost of developing a particular feature is worth the value their site will gain from its cost relative to other features that may have a lower cost and offer greater value.

Clients have to make educated guesses about features to prioritize based only on their understanding of their importance, as opposed to understanding their importance compared to their cost, and the importance relative to cost of other features they are considering.

It’s like shopping at a store where you don’t know the cost of anything until you get to the checkout – or worse, until you get your credit card bill! Yes, you really want to buy the fancy chocolates, but if you didn’t have any clue that for the cost of the chocolates (which wouldn’t feed you for a day) you could have bought a loaf of bread and gallon of milk for the same price (which could sustain you for several days), you’d make terrible shopping decisions.

We often make the unfortunate assumption that our clients have sight of this gap, but usually they do not. It is also a difficult issue to articulate to the client, and frequently comes across as “you don’t want to do that – it doesn’t make sense.”

We assume this problem is corrected by focusing on an minimum viable product, but it is not necessarily so. An MVP presumes a fundamental understanding of value that the client probably doesn’t have if they lack a firm grasp of the cost of development versus the tactical value of the end product.

I Need to Show Results

The completion of a project may be the end of our work, and the point at which we congratulate ourselves for our accomplishments, but it is rarely the finish line for the client. The client’s success is often determined in the weeks and months following launch, where all of the work is put to the real test of producing the anticipated results.

The Product Owners and Executive Sponsors with whom we interact are responsible for the whole lifecycle of the product we build, including its efficacy once the build is complete. They are responsible both for the successful completion of the project, and the on-going business success their organization intended for this project when starting it. The people with whom we interact are accountable to their organizations and must show results that move the needle in some demonstrable way.

As a partner contracted for some portion of the entire project, we don’t often have direct control over the larger success or failure of solving an organization’s business problem – they are usually very complex, and our work is just one piece of it – but that should not stop us from being conscious of the expectations and responsibilities heaped upon the shoulders of our Product Owners and Executive Sponsors. We don’t typically feel the burden of that weight, but if we are aware, empathic, and sensitive towards it, we can build a lot of understanding, trust, and cooperation.