In Part one I discussed the value of breaking out the discovery or road-mapping phase of a project into its own mini-project. But how do we get there from the initial call? How do we convince our client to work with us at all?
Do you create or do you execute?
If you are in the website-making business and you are presenting yourself to potential clients strictly as designer and/or developer, you may be shortchanging yourself… and more importantly, your clients and their projects.
That’s a somewhat bold statement, so let me unpack it for a minute.
The most important asset you bring to the table is the plan/strategy/solution that will help your clients reach their goals. If you are presenting yourself as a service provider, offering strict technical design/coding skills, you are positioning yourself as someone who can merely execute a plan rather than create a plan. This is the difference between an expert and a technician.
Stand back, I’m renovating!
About 6 years ago we took the plunge and bought a house. To be clear, I 100% suck at reno anything. Well, except for painting — when I paint they call me the “Trim King”.
Anyhoo, as we took on home improvement projects, we made sure to hire professionals. And here’s the thing with professionals: they don’t just bust out their tools and start breaking and rebuilding as per our instructions. We have no idea what we’re talking about!
Their role is to advise and guide us first. They prescribe creative solutions based on experience, rather than blindly executing directions.
When we say something like “hey builder, we’d like to open up the space, so why don’t you just tear down this wall and send us your bill?”, they respond with “Whoa there friend! If I tear down this wall, your kitchen’s going to end up in your basement, and that’s probably more ‘open’ than you want. What I can do is create a pass-through window, giving you the open space feel you’re after”.
See what they did there?
Using their authority and my language, they identified my problem and desired outcome and offered the best possible solution. They set limits all while communicating that they heard me; they had my back.
See what they didn’t do?
They did not blindly execute on my shoddy directions because “that’s what the client wanted”.
They didn’t overwhelm me with notions of gravity (bleh) or detailed specs on the shiny 500 horse-powered “thingamajig” that would get the job done. Why not? Because I don’t care. And I don’t want to care. I can’t relate that information to my end goal.
That’s great for Holmes on Homes, but I make websites!
If we transpose this example into a simple design/development context we might get an exchange that goes something like this:
Client: “We want you to give us a big slider on the homepage just like this website” (loads up a URL).
You: “Ok. Can you tell me more specifically what you feel this slider will add to your site?”
Client: “Hmmm, well this just makes everything feel alive like we’re a dynamic organization. We see so many sites that are boring and static.”
You: “Ah so it’s the movement! You don’t want it to feel like you are stagnant, and the movement gives you that modern, dynamic feel.”
Client: “Yes, exactly!”
You: “Well my concern is that you stated earlier this site needs to be extremely low-maintenance because you are a small and busy team. I suspect it will be tough for you to generate new content on a regular basis for a slider like this, and the content will quickly look stale. This may actually be more damaging and have the opposite effect you are after.
What if we used a video, or a very subtle, fading image slideshow of [xyz] as the background for the homepage instead? You will get that same sense of action without the headache of frequent updates to text and actionable content.”
This is admittedly a highly simplified example, but the principle applies to the most complex situations. When it comes to client-facing communication, there is rarely any need to discuss plugins, tooling, frameworks, or any other technical details. Those elements are important building blocks for the solution, but they are not the solution.
It’s not about you, it’s about them.
There is no debating that quality ingredients are key to any good recipe. But when was the last time you went to a restaurant and saw a list of ingredients on the menu? Never. What you get is a mouth-watering description of an experience.
This is the very approach we should be using when onboarding clients. Get away from “lists of stuff”, and keep the conversation focused on them. Pay attention to their language, their problems, their needs. Ask clarifying questions to make sure you really get it. The more we discuss their pain-points and ideal outcomes in ways that make sense to them, the sooner they will trust that their success is our topmost priority.
And it should be. Always.
With a little bit of experience, establishing that level of trust can be achieved fairly quickly. In a 30–45 minute introductory conversation (maybe less for more experienced consultants) you can get a high-level idea of their goals, and ask smart, relevant, jargon-free questions which differentiate you from a technician. You can, even without having all the information, offer a few off-the-cuff ideas, giving them a fuzzy but exciting glimpse of what success might look like for their project.
By the end of that chat they should feel confident that, given additional time and resources, you will deliver a cracking road-map. Who wouldn’t happily sign on for a low-risk, high-value discovery phase?