When I worked in the ‘big conglomerate of corporates world’, a common conversation took place that went something like this…
Project Manager/Department/Customer – “Install X” or “Negotiate a new contract with X so we can sign” or “Swap Y for X”
Us – “What do you require X for? Can you explain the problem you’re trying to solve?”
Them – “We need X”
Frustration would eventually reach peak point. And X would happen. Not because some people wouldn’t think deeper or really attempt to pushback to find the most appropriate solution (sometimes at the cost of their future job prospects), but because the lack of boundaries between external clients, internal customers and managers with short-term (often bonus driven) vision, mostly made it a place good strategy and big picture, objective based thinking wasn’t executed (or rewarded).
In the world of our businesses a common example goes…
Client – “Please make X bold”
Us – “Our understanding is that you’d like to emphasize X, or bring more attention to X and that’s not currently being reflected in what you’re seeing. We can achieve this in a number of different ways for the best outcome for you and your end users. We’ve created some solutions for that here. Do you feel this meets the objective?”
We’re lucky that in our own businesses we have a bit more control. Some freedom to educate, to expand ideas, to make the time to understand the core problem and devise solutions to that.
No matter what services field you’re in, you’ve likely come across a time where you’re provided with a solution rather than a problem.
But if you’re being hired as an expert (or if you’re hiring them) then you should hopefully be there for your knowledge and expertise. Which is to say we should understand the problems and present the solutions. Whether that’s your new architecture plan, technology process, interface design, new system, sales copy, marketing collateral etc – we should be creating in aim of solving/meeting an objective.
To foster this type of environment we’ve done the following ::
1. Added a why, objectives and problem statement area to our project proposals.
When we put together a project document that’s essentially our first document after we’ve had conversation to engage further that outlines the reason we’re working together (along with other items). This includes listing the objectives/goals of our work (generally 1 or 2 short/intermediate term and 1 long term) and the problem statements (i.e what problems currently exist that we’re looking to address through our work together).
This looks a little like this…
2. Complete a business canvas for all clients we work with.
We used to only use this for clients who were creating new products/services or in earlier stages to test a hypothesis first or work on customer development and now we do this for all clients. It helps us with the point above and it has a number of other purposes that make their business plan and our project really clear with something we can keep coming back to (or pivoting areas where needed). We start the canvas after chatting and send it back for review. Clients then add their additional thoughts or questions they have and we go through it. This is also a great way to make sure we’re on the same page for everything.
Using the lean canvas, we created a little one page PDF we use for this which looks something a la…
3. Added a point in our ‘providing feedback’ section of our Welcome Package to foster these types of questions.
In our section for this for design work we have a point that says…For your designs, please provide specific feedback. For example you may say ‘I/we would like to see more emphasis on X as this is important to convey due to Z’ as opposed to ‘make X bold’. There are many ways to place emphasis on an element through design – state the problem and let’s create a solution.
4. Ask more questions.
When we’re going through processes and workflows we ask a lot of questions. We need a very clear picture of what clients are doing during these phases (or their days). We also ask them to track certain things for a period of time. This often highlights problems which we can then discuss together and strategize solutions to.
During review processes (i.e for design) when we’re talking through certain elements we always try and come back to the why – why we’re doing this, what objective are we trying to meet, what do we want the user to understand or do? It doesn’t mean they’re wrong at all – they’re often totally legitimate concerns and they push the project to be better – but in reshaping the question we can understand and then solve the real problem which is the best outcome for everyone.
This is of course by no means perfect and there are many different ways to approach this, but it’s a start. After being in process for a few years it has had a significant positive impact on our clients, on their clients/customers/readers/users and on our internal team, job satisfaction & happiness levels.
This is one of the rare times where we can all happily say, let’s talk about our problems deeper. And once we understand and agree on the requirements, let’s create solutions.