One of my Project Managers (we call them PMs at Matrix Group) was struggling with an account. The client was frustrated, the Project Manager was frustrated, so of course, now I’m frustrated. I called the client, had a long de-brief session, worked through some issues, and with a few tweaks, the project was back on track. The PM wanted to know how I did that. My secret? I put myself in the client’s shoes.
As a business owner, I get to be manager of staff and projects AND client to our many vendors. As the chief salesperson for the company, I interact the most with customers and users. As a liberal arts person turned techie, I know enough to be dangerous, but I can’t write a line of CSS to save my life. All of this means that I can more easily see a situation from a client’s perspective. Here’s what I’ve learned over the years about clients:
- Clients are busy, the Web site is usually just a small fraction of their job, they don’t spend all day thinking about the Web site, and there’s a whole lot of stuff going on that they don’t know and don’t care to know. We can never assume clients know that a new version of Internet Explorer is coming out and it’s going to be more standards-compliant, that title tags should not be more than 64 characters or Google will ignore them, and that a print style sheet is different from a printer-friendly page.
- Most clients are non-techies who need a technical solution. They seek a solution and a result. We need to give them context for our solution, and enough detail so that they can make an informed solution, but not so much that they get overwhelmed. We also need to communicate concepts using terms they understand. For example, when a Web design has been approved and we have to now slice the design, I liken it to going to blueline. Clients who have ever had anything printed are familiar with blueline; it’s close to a final proof and changes cost time and money.
- At any given moment, clients are cold on a project, which means they don’t remember every last detail of the specifications, prototypes or testing notes. So again, we need to provide context, we need to bring clients up to speed quickly, and we need to let them know early what we need from them.
- When a site or application is turned over to the client, there better not be any obvious bugs; otherwise, we are wasting their time. Nothing makes a client go nuts faster than an error message within the first few screens of testing.
- When providing an update, we can’t just report on what we’ve done. We need to provide the big picture: what we’ve done, what’s not done, what’s next, what we need from them, immediate next steps, and ultimate deadline or launch date.
- Should does not belong in our vocabulary. Should makes me crazy. It either does or does not. If you don’t know, don’t say it should.
For all you clients out there, what else do you wish your Project Manager and team members knew about you and your perspective? What behaviors make you nuts? What actions make you love your team?
