a Solution to a Client
How to present a solution effectively
Often, successful collaboration in software development depends on how you present a solution to a client. If you manage to effectively communicate your concept, you kill two birds with one stone.
First of all, if you translate your solution to a client and he or she gets a good understanding of your offer, you demonstrate your insight and the transparency of communication from the very beginning. Secondly, it allows validating whether your solution matches with the client’s expectations and goals. Therefore, you confirm you are moving in the right direction.
At Digiteum, we have a long history of collaboration with the companies of various sizes across different domains. It enabled us to get an extensive experience in building varied digital systems, from complex IoT platforms and intelligent ML-powered tools to Uber-like apps and enterprise websites. Hence, it allowed me to learn how to present different solutions to ensure successful collaboration and project launch.
Here’re some techniques I believe are worth sharing.
Techniques to present solutions to different clients
At the very first steps of communication, we are trying to get to know about clients and their business as much as possible. This is important for the future communication. We can choose the right way to communicate our solution concept and project details to our clients if we know what’s important for them and who exactly we are dealing with.
Project proposal is the key document for this purpose. Now, how we organize our proposals depends greatly on who the stakeholders and mainly decision makers are. In my experience, adjusting the proposal to the needs of a particular target audience is the key to effective solution communication.
In general, we provide a range of basic components when we communicate our solution to a client or present a project proposal.
- Analytics and numbers. Taking into consideration the client’s ideas and project brief, we perform analysis and collect relevant metrics and numbers that make the ground for our solution.
- Technical solution. We describe the system we offer to build. This description is always based on prior business analysis and gathered requirement and focuses on the client’s goals and needs.
- Addressing business goals. This is a self-explanatory point. We show how our solution addresses the client’s business goals in the proposal.
- Project development roadmap. In order to show the development of the project in time, we create the roadmap that demonstrates the whole process from the discovery stage to launch with associated deliverables at each phase.
- Relevant case studies and references. Real-life examples and successfully accomplished projects validate our expertise and help a client better understand our capabilities.
These basic components help us provide clients with a good detailed understanding of the solution we offer and the value it is supposed to bring. Here’s how you can personalize these and other arguments so that they better resonate with different clients’ needs and expectations.
For tech-savvy decision makers
When we are dealing with a chief technology or chief digital officer, or even a CEO with deep technical knowledge and expertise, we focus the way we present our solution and development plan on the specific needs and requirements of this target audience. In particular, we:
1) build project development roadmap with technical details
Project development roadmap shows how the solution will be shaping along the course of its development from design to the first version launch and further improvement. For tech-savvy decision makers, we create a roadmap with the detailed technical description of a project.
2) keep the focus on the technical excellence and efficiency of the proposed technology stack
Giving a detailed technology stack for a project, we allow stakeholders to assess our approach to design and development from their technology expertise point of view and consider the feasibility of our ideas.
3) provide analytics and technical numbers
In my practice, technology people are good at thinking and talking numbers. Therefore, we often collect or generate the relevant technical metrics that should be improved or can be reached upon the implementation of the project.
4) list our previous projects built on the same or similar technologies
We present real-life examples of our expertise in relevant technologies, domains and development methodology to demonstrate that we fully understand the technology and specifics of the project and can build a new custom solution using our previous experience.
For business-first decision makers
Often, the clients that address to our services don’t have relevant technical expertise, skills and capabilities within their companies. In these cases, we believe our client is fully focused on the business outcomes of the project. In other words, such client is less interested in how the solution is supposed to be built and rather curious when the first version can be tested, what features can be rolled out first and what comes later.
To address the needs of this client category, we use a different approach to how we present a solution. In particular, we:
1) build featured-based project development roadmap
For business-first decision makers, we present a solution with attention to its development plan and time-to-market parameters. We describe what features are more important to roll out first and when a client can test different versions of a new solution.
2) keep the focus on the business efficiency of the selected technology stack
Even though we are dealing with business-first decision makers, we provide a detailed technology stack for the project as a standard part of a project proposal. However, in this case, we omit less important information and too complex technical descriptions to retain the focus on the business part of the offer.
3) explain how business goals are addressed
We find it very important to explain how a client will benefit from a future solution from the business point of view. Therefore, we clearly describe how every project version addresses different business needs and goals that provided the basis for the project in the first place.
For example, we can suggest how this or that feature is essential to increase conversion and why it’s important to have a mobile-friendly website for better user engagement at the launch.
4) provide analytics and business performance-related numbers
We provide the analytics and metrics related to the client’s business goals when we can. Often, numbers help clients better interpret project ideas and match them with their own business goals.
These two approaches to communicating a solution to a client often use the same components. Nevertheless, they satisfy different needs of different stakeholders. In practice, we usually apply a combo of both to better personalize project proposals.
In my experience, a carefully balanced proposal is the best way to present a solution to a client. Moreover, this personalization approach is equally beneficial at every stage of project realization - UX design process, testing, delivery.
How to present a solution effectively
A couple of words about the presentation itself won’t hurt. First of all, I believe in compact, effective documents. We try to avoid long PDFs and vary text with imagery to better communicate our solutions and omit the details that are best understood when discussed at a personal meeting than left in a written form.
Secondly, I prefer a personal presentation. Therefore, we don’t usually rely on a simple one-way e-mail. Instead, it’s better to make a person-to-person presentation either offline or online using screen sharing technology.
This approach allows you to take a lead in the presentation, build a dialogue, address questions and expectations in real-time, provide more detailed explanations and plans. As a result, a personal presentation enables you to take an active part in and influence on the shaping of client’s opinion about your solution.