DEV Community

Cover image for Presale in IT outsourcing: how to end the first meeting with a sincere smile
Yevgeniy Kosmak for Daiquiri Team

Posted on

Presale in IT outsourcing: how to end the first meeting with a sincere smile

What should I do to ensure the client gets what they exactly want? And how to ensure that a development team would obtain proper working conditions? This is one of the main issues that arise before the start of any cooperation. The second question — how should I do it? We will present some ideas about the presale process for resolving these issues.

A short list of details that you need to have done before the first meeting with them:

  • The client is interested in your services and is really engaged in continuing the dialogue with you.
  • You have identified the client's basic needs and have roughly imagined their vision of the solution to these problems.
  • You know the approximate limitations of your proposal: budget, deadlines, and peculiarities of the future solution.

What should be figured out?

The following are questions, as well as contexts, angles, and meanings. Without considering them, the conversation will not be so fruitful. The exact wording of these questions depends on the situation and the client's individualities. But still, you have to know the answers to those questions after the meeting.

  • What do you expect as a successful project's outcome?
    • [If it is a new product] By what criteria will you evaluate the success of the future product? Who is responsible for this product on your side? What are the key competencies of this person? Maybe you have some metrics that will need to be achieved? How can we increase our chances of success?
    • [If you need to develop a product not from scratch] What exactly is ready? Maybe you have a description of the problem, a draft solution vision, product characteristics, and market analysis? Who is responsible for the vision, and what is your approach to its construction? What artifacts of works do you have at the moment? Could we get them, and how?
    • [If the old product needs to be improved or replaced] Why is the old product no longer performing its task effectively? If there were errors, have you worked on them, and what are your results? In what form do you have requirements for the old product, and to what extent can they be used now?
    • [If you need to prove or disprove the hypothesis] Why do you think involving another company in the research is effective? If so, how clear are the evaluation criteria? What threats do you see in conducting research on your own?
  • How will the product affect your company's business model? Should it increase profits, reduce costs, or balance the risks?
    • Is it possible for us to learn about the general business model of your company? What market or niche do you consider your own?
    • What is the target audience? Maybe you have developed proto-personas? What problems does your company solve in general?
    • How will the product change the processes inside your company? Or will it create new ones, automate them, or make them unnecessary at all?
  • In what form do you currently have input for the future product?
    • [If there is no input in text form] What do you see as necessary about formulating product constraints? What will be enough for you to be able to control the product's compliance with the requirements? What level of our involvement do you want in the choice of priority functionalities? Do you want me to describe our approach to this issue?
    • [If there is some input but the customer has doubts about its quality] To what extent do you think you have exposed the main parts of the product? Do you already have some priorities? How precisely do you envision the first month of cooperation?
    • [If the customer thinks the input is close to ideal] How much could this input change in the process? Which parts of the product are the least predictable in this sense?
  • How do you expect the tactical decision-making process in the workflow?
    • Who is responsible for the quality of the outcomes in the project we discuss? Who will act as product owner on your side?
    • How fast do you think the tasks on the project will change? What is the standard planning horizon? Do you have any thoughts on this?
    • Do you want to control some technical decisions on the project? If so, how and for what purpose?
    • What time zone are you and your employees in? What are your typical working hours?
  • What boundaries do you have in this cooperation?
    • Do you have a deadline for the whole project or some milestones? Why do you decide them so? If there is no deadline, what expectations do you have about the development pace?
    • Who pays for the project: your company, the customer, the client, the partner, the investors of your company? In which cases can the project funding be stopped before it is completed?
    • What are the budget expectations, and how were they formed? Are you planning a budget for the entire product, or is it better for you to plan it monthly?
    • Are there any special conditions for cooperation? Maybe security, technology, or do you need any particular competencies?

Knowing the answers to the above questions, you can offer conditions of cooperation quite accurately. By the way, you can check out how we do it at Daiquiri Team.

How to figure this out?

Our approach here is simple and constructive — we need to be sincere and specific. When asking a question, you have to evaluate how it will be perceived. If the questions' reasons are unclear, they should be explained. It would be best if you spoke as simply as possible to make your thoughts easier to understand. And you also need to constantly keep an eye on the interlocutor's attention, being on the same wavelength. Let's look at a few examples of how you can do this.

Some topics and questions are delicate, such as about the money. The straightforward approach may not work here because the client may not be ready to respond. It may also take time for them to understand the importance of the question and come up with a quality answer. Therefore, the question should also be delicate and reasonable.

Look, there is a delicate question, but without an answer, it will be difficult for us to work. Tell us, how do you agree inside your company to make important product decisions? We need to understand this to give you the most relevant data on which to base such decisions.

The probability of encountering negativity and aggression is many times lower than in the case of a straightforward question. You may not get a complete answer right away, but this is already a significant advancement on the problem and valuable information to lead the product.

Sometimes a client may worry about such questions and think, "Why do they need to know this? It doesn't concern them at all." Seeing such a reaction, you should immediately explain to the client the reasons for this question. For example, you want to get a description of target audience or proto-personas. And the client does not understand why it is because you develop only the back-end. In this case, you can answer as follows:

I understand that our product does not apply directly to TA, but without understanding the product's end-user, we may rely on false assumptions. For example, we will spend too much time on less important API methods or work on minor entities in too much detail. So we should see the picture as a whole, then the probability of such mistakes is less.

At any convenient opportunity, refer to the previous words of the interlocutor. People like to pay attention to themselves, and often they can even say something new that they would keep quiet about in another situation. But it's important for your work, so record the answers and reactions to it.

By the way, you mentioned that the idea of the product belongs to you. Do you think you could take part in our team's brainstorming for the UX product? To what extent did you plan to engage your employees to improve the product's user experience?

And a few more small techniques:

  • Support communication on common topics, even look for them. This improves personal connections and reduces stress.
  • Make appropriate compliments. It is better to start with compliments on professional topics - so it will be easier to build an idea of each other in a working sense. When you already know the interlocutor better, you can be just a person for a while, not just a pro. Praising a colleague for something not about work is an entirely conscious story.
  • Keep track of time. If more than two-thirds of the time scheduled for the meeting has passed, and you have not learned the answers to even half of the questions - speed up and pay less attention to details. The overall picture is more important for the result than empathy here and now.
  • Always sum up. You met on the case, so it is worth summarizing what work questions were resolved during the meeting and how productive it was. In this way, you give feedback on communication to the interlocutor: what was helpful, what was not, and what will happen next.

Also, you can check how we hold kick-off meetings on our website.

How to achieve better results?

However, this is not all a good sales manager can do during a single presale communication. The little things are important, and the results often depend on them.

  • Supermarkets often make special offers — buy a toothbrush and toothpaste, and you get a discount. This technique is called cross-sale, and the same can be done when selling IT services. Knowing the current problem makes it easy to notice the client's other challenges. As in supermarket sales, the main thing is not to impose anything but only to solve a real problem. No pressure and "good prices" — just looking for good points to expand cooperation.
  • Don't be afraid to break the context. For example, you feel that the interlocutor is not interested, and you are sure you are not mistaken. Ask if everything is okay? Because if the client, for example, is worried about the health of a loved one and they can no longer think about anything, what kind of business can we talk about? Offer to postpone the meeting to another convenient time, and your client will remember that. And this will help you in the next meeting to be in a better position in the negotiations.
  • Don't be afraid to ask questions, even if the answer may be obvious. Technologies are multifaceted, and terms can mean different things in different cultures. Some may call the word "site" a landing page and the word "landing" a home page. There is nothing wrong with taking some time to clarify. And if you lose the essence, and on this basis, your company will make an inaccurate offer of cooperation, then all your work will be in vain.
  • Don't try to be who you are not. If you are asked questions you cannot answer, it will be your integrity if you immediately admit it and say that you have to convince that your answer is correct. It is a sign of a professional.

Why so?

  • Understanding the client's business is vital for a quality solution to their problems. So you need to know as much as possible.
  • Understanding how the customer sees the future product is vital for building effective communication with them. When you make an offer or make any decisions, you must consider all the client's opinions on this topic.
  • Personal relationships are no less meaningful than a professional approach. It is always important to remember that collaborations live less than people. You definitely want to be treated well, despite all the work moments.

Bottom line

For many professionals, presale causes the most difficulties, which is quite understandable. Here you meet new people for the first time, informal relations rules have not been built yet, and both sides do not know what to expect from each other.

To overcome such difficulties easier, remember that you are communicating with the same person as you. They have their goals, expectations, powers, and desires. Be honest, empathetic, and professional. And everything will be fine.

We gladly assist you if such an approach fits you and you need something to be developed.

Top comments (0)