Solution Design - The Art Of Crafting The Right Solutions To Client Problems

Do you know what you're really selling as a consultant? It's not your time, nor your deliverables. It's something far more valuable.

Hi, I’m Rich, welcome to my consultancy newsletter. Please subscribe and check out my best articles.

I needed someone to take care of my business accounts.

One person said they could be the bookkeeper, but I’d have to file and do payroll myself.

Another said they would do the payroll, send invoices, and record payments only.

Another said they would do the bookkeeping and filing - but couldn’t do payroll.

None of these (metaphorical) people are selling the service I want to buy - which is someone to make the accounts problem go away.

Each can speak about the unique complexities and intricacies of their work, but none have properly understood what I want to buy.

I don’t want to deal with two to three different people when handling my accounts.

I want someone who can take care of accounts and let me focus on running my business.

I want someone who can say:

There are some essential rules you need to follow which I’ll summarise for you. But I’ll set up the accounting system, tell you what you need to do, and bring in a partner so we can handle everything. All you need to do is check the accounts, sign a few documents, and tell us who/when to invoice.

It’s easy to fall in love with the process instead of the problem.

You’re Not Selling Deliverables

You’re selling the solution to the full problem

Unless you’re working at the lower end of the pricing scale, you really shouldn’t be selling deliverables. You should be selling the solution to the problem. You want to make the problem go away.

It feels almost a cliche to note that people don’t want quarter-inch drills, they want quarter-inch holes. But it’s worth noting how easy it is to understand the deliverables you want to create and try to persuade the client that’s what they need. A better approach is always to understand the problem you’re trying to solve and sell the solution to that problem.

I recently spoke with the CEO of a newly funded SaaS company about building their community. He complained:

I keep speaking to consultants who talk to me about platform comparisons, member personas and onboarding journeys. I don’t have the mental bandwidth for any of it. […] I want someone who can just figure it out.

He’s speaking to people who have fallen in love with their processes and want to explain how good their deliverables are. But they haven’t understood what they need to sell. Instead of talking about the typical deliverables above, he wants someone to say:

We’ll put together a plan for everything that needs to be done to bring this community to life. It’ll include what platforms to use, who to hire, how to get members engaged and participating, and the resources required. Once you approve it, we can make this happen within [x] months.

Now he can get on with the business of scaling the company. He only has to think about the problem when he needs to make or approve an important decision. He’s not disinterested, he’s just busy.

He just wants the problem resolved. This knowledge that he wants the problem resolved without having to think about it should be embedded within the deliverables you create.

Many clients can certainly figure out how to solve a problem themselves if they have the time and bandwidth to do it. But if they don’t, they need a consultant who can take that on for them. That’s a common reason why people hire consultants - to get something done without slowing down. Sometimes that’s what you need to sell.

Unless anything you’re doing will have significant financial repercussions or impact other aspects of the business, he doesn’t need to know.

Six Things To Evaluate Before Deciding The Deliverables

You have to diagnose the problem properly and then develop the deliverables to match. If you don’t fully diagnose the problem, the deliverables won’t match.

Newcomer consultants are prone to identifying the problem and then rushing to talk about and suggest the right deliverables. But if you don’t identify the full extent and limitations of the problem, you’re going to struggle.

Let’s imagine for example a prospect is struggling with a high rate of churn in the customer’s trial period and wants your help to resolve it.

A newcomer consultant might say:

“Yes, we’ve done this before. We’ll evaluate why people are dropping out, review best practices to resolve that, and put together a plan for you”

That’s not bad, but it doesn’t dig deep enough into the full scope of the situation. Let’s use our method instead:

To diagnose the problem you need to know:

• The issue. What is the problem they’re aware of and looking to solve? The problem in this context includes the opportunity to improve. For example “Low satisfaction rates” or “high rate of churn”. You should investigate the causes of the problem and the full impact of the problem

  • (e.g. high rate of churn in the trial period of the product leading to slowed growth).

• What is their current level of knowledge about the problem? Do they know what they need or do they need to be guided to discover what they need? There is a big difference between working with a client who already knows the solution they want (i.e. ‘we need to know how best to implement this platform’) vs. a client who doesn’t have any idea of what to do

  • (e.g. No research and limited knowledge on what’s causing churn or common solutions)

• The resources available. Does the organisation have a lot of resources to commit to finding the best solution or are they looking for a solution which simply works? Again, there’s a huge difference between the two.

  • (e.g. Needs a rapid solution to show improvement on a limited budget)

• Time available. Same as the above, does the organisation need a solution as soon as possible, or are they open to investing time to find the best solution?

  • (e.g. Lots of internal pressure to show results now)

• Personal situations. Do the people involved have the time and energy to collaborate alongside you to find the solution or do they just want someone to take care of it and loop them in when essential? Are they looking to be guided or looking to be told?

  • (e.g. staff involved are juggling multiple projects and can’t commit huge amounts of time to this)

• The organisation’s environment. Is the organisation rapidly scaling and needs to show growth regardless of costs? Are they struggling and need to save costs? Is there a major strategic push which will impact all projects? Knowing the environment is critical.

  • (e.g. big push to incorporate AI into major projects)

Can you now see how this additional knowledge might impact the deliverables we will create?

Based on this, we might now create a set of deliverables which include:

1. A prioritised list of causes of churn - ranked by immediacy and budget. This will be built on surveys, UX research, and data analysis review to identify where customers are churning in the trial period and why they are churning.

2. Practical steps to incorporate AI into the solutions. Includes best practice examples of AI in reducing churn from other organisations, where AI can be implemented into the solutions identified above, and the outcome will look like and potential risks to mitigate. 

3. An implementation plan to reduce churn. Includes partners, scope of work, budget and ongoing project management to lead the implementation of the solution. Offers a go/no go for launch. 

In practice, the deliverables will be more complex and better explained than this - but it gives you an idea. If we’re being compared to the newbie consultant’s offering, we’re going to win because we’re solving the right problem.

Design The Right Set Of Deliverables

Quick summary:

1. Don’t fall in love with your processes or deliverables. Above the $25k level, you need to customise your deliverables to the unique needs of each client.

2. Many clients simply want someone who can take care of the problem. They don’t need you to tell them about your processes or the complexities of it - they just want to solve the problem with minimal effort on their part.

3. Gather the full circumstances before designing the deliverables. Look at this through the context of the issue, the client’s knowledge of the issue/solutions, time/resources, personal situation, and the organisation’s environment.

4. Develop the deliverables to solve the full problem. Once you’ve gathered this information, develop the deliverables to solve the full problem.

Good luck!

Thanks for reading

Richard Millington