How to send complex technical proposal to a prospect within 5 hours under extreme uncertainty

UB -

How to empathize and pitch with incomplete data

I have seen a lot of IT services companies losing important business because they can not handle the ambiguity in technical engagement. Technical people expect very detailed information about the solution.

“In any moment of decision, the best thing you can do is the right thing. The worst thing you can do is nothing.” — Theodore Roosevelt

Many clients especially from non-technical backgrounds do not have the time, the energy, or the mindset to prepare the detailed scope of work, and it's overwhelming for them if you bombard them with too many questions. It will end up on pre-sales consultants to define the scope of work with just enough details that the proposed solution is directionally right and allows the limited update of scope as a part of the discovery exercise after the engagement.

I will give you a framework on how to engage clients with minimal effort even when you do not have enough information. As a technical trusted partner, it's quite normal that you have to send the 1st proposal to a client with very limited information.

The proposal needs to be directionally right and open-ended enough to incorporate new details at a later stage.  

Day-one hypothesis

At the beginning of any new client engagement, You are expected to develop a “Day One Hypothesis.” Based on the high-level facts that are learned within the first 24 hours of client discussion, You will be forced to develop an early hypothesis of what the solution to the client’s problem could be.

The reason why this approach is helpful is that after Day One, you always have a decision that you can stand behind at any point in time. You may try to gather additional data later, but based on the data that you have already reviewed, your current hypothesis is your current decision.

This approach works best when you don’t know how much time you have to make a decision, but you could be called on at any time to make it. How you develop your hypothesis is a combination of good problem-solving skills, pattern matching, intuition, and of course a good google search.

Step 1A: Research on the contact and his department [estimated time: 1h ]

  • Look at your contact business priorities, what are the KPIs that are most important for him
  • Check his digital profiles like LinkedIn, youtube videos, and blog posts for insights
  • Select the top 3 most important questions he can answer in 30 mins during the call easily. Write down potential answers to these questions. Ask questions and give him options to choose from. The idea is to make him a hero and make things very easy for him.

Step 1B: Research on the enterprise [estimated time: 1h]

  • In what industry they are operating? who are their customers and what are they offering to these customers?
  • What are their future plans? It's easy to get this information about publically listed companies.
  • What are the industry leaders doing with cloud, big data, and AI?
  • What type of technology ecosystem do they have? are they using the cloud? do they have Big data platform in place? what is their current reporting stack?
  • What type of technical talent do they have? do they have CDO? do they have senior leaders overseeing data engineering and data science and data architecture decisions?  How many data science and data engineering resources do they have? what are their skill sets?
  • What are the top AI use cases that might be suitable for this enterprise? What kind of data platforms the given industry is adopting, like customer 360, patient 360, etc.

Step 2: Initial discovery call [estimated time: 1h]

Focus on what your customer is looking to solve, understanding their pain, and what makes their situation unique. Only then should you offer a prescription of the type of solution they need, and help them evaluate the trade-offs between what you’re offering, and that of your competitor.

  • Discovery calls need to be conversations, and not 1-way sales pitches. The customer needs to know they have control, and their concerns will be addressed.
  • Situation: Start off with situational questions that show you have done some research, but also help you qualify the customer on basic minimum requirements.
  • Pain: When you begin asking pain questions — don’t just ask the generic and over-used “what keeps you up at night?” Instead ask more thoughtful “When speaking to other Directors of Sales, they mention challenges 1, 2 and 3 are on their top priorities to solve. To what extent is [customer challenge #1] important to you?”
  • Case study Reference: Share a relevant use-case or customer story that pertains to the situation and pain you just summarized. The key is making sure your use case is relevant and matches a pain they are currently facing that you just identified. Know customer stories that you can share through a story.
  • Value: Begin to transition from emotional to rational decision-making and quantify the value of your solution. Ask them questions that describe the impact a solution like yours could have on the company.

Step 3: Select and update suitable Boilerplate Scope and proposal [estimated time: 1.5-3h]

Now your proposal needs to be directionally right, and in the same order of magnitude, as the “right answer”. Without having complete data, you will never be able to get to a precise answer. Instead, you should strive to make sure your answer is directionally right. By approaching the proposal this way, it takes the pressure off getting to the precise right answer and avoids “analysis paralysis.” You need to be right enough with your decision, but you don’t need to be perfect.

Every technology service company offers a limited set of services. A boilerplate solution for each kind of service should be prepared beforehand. Once you have enough information and the day 1 hypothesis is relatively mature. Now you can select the type of service client needs and customization of the boilerplate template for these specific clients. In my experience each boilerplate should have at least the following sections:

  • Business challenge, proposed solution, and the expected business results
  • Deliverables with high-level scope variables like a number of data sources to be migrated etc. It will take some time to converge on the right scoping assumptions. also clearly list down what type of activities will be out of scope  
  • Technical Approach like cloud architecture etc.
  • requirements from the client and any other assumptions
  • Timeline with two discovery of weeks discovery and analysis phase etc.

A detailed discussion of boilerplate also called productized solutions are out of scope for this article.

Step 4: Verify and Send [estimated time: 0.5h]

In the end, whatever proposal that you are sending to the client, make sure is assessed in the following 3 dimensions:

  • Are we giving them What they want?
  • Are we avoiding What they don't want?
  • Are we using their language and vocabulary?
  • Are we adressing the objections they might have?

Next Steps

This process will rarely end here. Most of the time this will provoke the client to share more specific requirements. All you have to do then is just listen to what they want and update the proposal accordingly.