I’m at WordCamp Seattle today and will be posting notes from sessions throughout the day. These are posted right after the session, and could be a little rough.
This is a talk from Amanda Blum, project manager and pretty darn good friend of mine. Find Amanda at @amandablum on Twitter and at howlingzoe.com on the web. The WordCamp.org session description is here.
We need Client Empathy
We’ve become good at development as the community has matured, but still need to get better at client relationships, and client happiness. Amanda’s started to hear the term “client empathy” get thrown around lately, and she likes the trend. Here are her ideas for what we need to do to deliver better experiences for our clients.
Allegory: Getting Amanda’s Garage Ready for the Kiln
Amanda’s been working on getting a ceramic studio into her garage, which needed work first. “tl;dr — it sucked”. A man who only spoke Russian offered to do the garage drywall project for free, which she knew she needed, but she couldn’t say Yes! because she was overwhelmed by everything he was trying to communicate that she couldn’t understand. She ended up doing it herself with friends, which was tough (understatement).
Clients don’t walk away from you even though you could make their business 900 times better because they are morons. They walk away because they are overwhelmed.
Clients are not all idiots
We bitch a lot about clients being idiots, but clients recognizing they need help is to be applauded, not chided.
It’s hard for clients:
- “We are an industry of snake oil salesmen.” There are no licenses, no accreditation boards, no certifications, etc.
- Costs range from $7 and $70,000, and cost is not an indication of quality. Expensive projects can fail and cheap ones can succeed. How can we expect clients to have good price expectations?
- Clients come to us with ideas about what they need, we move them in another direction (and then we talk behind the scenes about how stupid they are and how low their price expectations were).
- We sneer, but $5K is a lot of money for most people, and it’s a reasonable amount of money to buy a lot, in a lot of contexts.
We need to find a better way to communicate the value better, and to do it in a passive way that doesn’t make them feel stupid.
Set Good Expectations
Good expectations are matching expectations.
Engineers speak a different language than clients. “I want an event calendar” in client speak may turn into “I’m going to install a plugin” in engineer speak, but the engineer knows the plugin will need maintenance. That doesn’t mean anything to client; client assumes “I want it to work” didn’t need to be said.
Expectations about outcomes should be written into contracts — without adjectives. Instead of implementation details like “install this plugin”, write about outcomes, like “Event calendar, which we will support for X years”.
Everyone here has a font, a plugin, a theme you’re just dying to use and work in on some project. We think we know what would be great for our clients before we start talking to them. But we can’t go into projects like that.
We have dev environments at home, and our own blogs. Play with those to have fun with your toys. Leave those desires and assumptions at home.
Use a PM
Engineers cannot QA their own code, because they’ve written it. Engineers should also not do support. In terms of client relationships, few things are as important as QA.
Using “pixel perfection” as an example, it is something you can verify as done, and write tickets against, etc. You can test every single aspect to make sure they work.
But PMs should do this. Why? Because the PM insulates between the client and the engineers. A PMs’ main job is making the engineers more effective. Call it an air-gap.
Engineers generally over-explain. They can’t translate.
Tremendous respect for engineers: They are like dogs with a bone when they have a problem to solve. But they need this: A good PM will tell them which problems to solve.
The donut example
“I need one donut tomorrow.”
“Great, we can make you a donut machine that will make you all the donuts you ever need, by one week from tomorrow”.
“Great, if it’ll be ready tomorrow and can make me one donut, awesome. If not, just make me a fucking donut.”
You cannot engineer without a Plan
There was project where Amanda suggested taking text articles out of a client’s newsletter and putting it into the blog. She could see numerous benefits, but the client stubbornly said it couldn’t be done. Amanda finally realized after a couple of weeks that they were never going to enter the blog posts because of their process, which just made it too hard.
It would’ve been easy for Amanda to just build this for them, but it wouldn’t have worked for them.
You need to create a plan based on the clients’ needs, process, etc., before you build, to avoid building something that won’t work.
Build for the way people use
Don’t assume people will become WordPress experts and bend their process to WordPress’s way of doing things. If WP is different than the way they are already working and the way they want to work, they’ll have trouble with it.
Example of how we can make this better for clients: Customizing the dashboard menus to match clients’ lingo and what they want and need to do with it.
Workflow is a Cascade
Clients want to get to everything immediately, or want to jump around a lot. Refuse to move forward in the process until you have what you need to move forward, to be successful.
There is a natural waterfall/cascade: Scope > Define goals > Info architecture (sitemap) > Design > Build > Test > Deploy > Ongoing refinement
You can move backwards in this process if you need to, but don’t jump ahead to move forward too quickly, or things will go off the rails.
Friendly is not the same as friends
Politely decline FaceBook connections to clients.
Don’t hire anyone you can’t fire. This goes beyond nepotism: Don’t hire anyone — not just family — that you can’t fire.
It’s important to avoid crossing lines and to keep things above board and professional for the success of your working relationships.
There’s a spectrum of how to reply communicate: On the one end is an Immediate Response, an over explaining answer, and being chatty. On the other hand is no response, and silence.
What clients actually need is acknowledgement of receipt, and request for time to respond. Then, be as to the point, direct, and brief as possible. (Edit adjectives out.)
Test, then Test Again
“Test what you’re doing within an inch of its life.” Testing is often under-estimated in the life of building a website.
After the Job
As a summer camper, this isn’t clear, but as a camp counselor you learn to recognize that the summer camp emotional experience is formulaic: They have a marketing ploy by making everyone emotional at the end, with a slideshow showing pictures of you befriending your friends throughout the week, with nice music… they sign up 60% of their returning kids within a week of the end of camp.
The end of the project is where you ensure its success.
Remember that Clients Forget
“He looks like a 28 year old entrepreneur, but he’s actually a 78 year old woman with alzheimers, and just doesn’t realize it yet.”
Thus, put everything in your PM system.
The very few times you’re communicating outside of the PM system, automate getting the data in with ITTT or something. Immediately after a phone call, enter your notes into the PM system.
This isn’t a CYA thing, it’s a people have no memory thing.
Stop Teaching WordPress
We do a lot of teaching WP, but it’s gotten harder as it’s gotten more complicated. It’s really hard now, and a barrier.
But, we’re building really customized sites that do very specific things for our clients, so now we need to just teach them those things they need, not all of WordPress.
Amanda recommends a plugin that allows you to create a help menu you can customize and add right on the Dashboard. [I missed the plugin and will add that later.]
When you have a feeling of success, you tend to move forward. Make sure you can give them that feeling of success.
For example: No one is ever going to follow through on their corporate blog. For clients who are really insistent, Amanda likes to get them on CoSchedule and start to build an editorial calendar so they can see what it’s actually going to take from them, before they commit and before you build the blog they won’t be able to maintain.
Testing shows progress
Build testing into contracts to show progress during the project. Continue to refine in tiny ways as you move forward throughout the project.
Amanda means tiny details, literally — for example, a button’s copy. “Does this button title work better, or this?” Clients love that; it feels productive.
The moment after you are done, a million things have to happen. Talk with clients about:
- Here are the things you need to think about on a daily/weekly/monthly basis
- What’s your plan for backup, for security, for maintenance if not through me?
If they fail to use the site after the project is over, then you failed.
For more information
To receive Amanda’s notes, email [email protected]. Her slides are available on Slideshare.
This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.