Business
5 min read
It makes no sense to expect that a client who has never built an application before will just start using technical jargon immediately. Clients who have an excellent idea for a product but don't have any knowledge about the software development can still succeed – but only if they team up with a technology partner who is aware of their needs, requirements, and knowledge gaps.
Here's a typical scenario:
A non-technical founder approaches a development team, tell them about the project, and then leaves the team to do its work and return with the ready product. Some software development companies don't encourage entrepreneurs to become part of the development process.
We believe this is a huge mistake that leads to building products with a poor market fit and not satisfying the client requirements.
In fact, want the client to understand the technical side of his business better. There’s a strict correlation between technical and business part of the product; for example, different technical solutions may bring about different outcomes regarding scalability, area of application, target audiences.
We always step into the shoes of technical consultants in the early phases of development where we try to explain all of the nuances in terms of the business application of the product.
Every client – technical or non-technical – is a project stakeholder and the development team needs to acknowledge that by allowing them to participate actively in the project. In fact, it's the job the project manager to facilitate the needs of a client who doesn't have a lot of technical knowledge to grasp the background work that is being carried out.
For example, we always assign an internal domain expert for projects who is not only the project manager, but also a single-point of contact for the team when it comes to clarifying tasks. That way, we don’t need to contact project owners from the client's end so often. Note that such project owners are usually non-technical.
Over the years, we have developed a set of best practices for managing projects with non-technical clients.
Here are some of the things we do to ensure that such projects are successful, regardless of whether our client has the technical knowledge or is a business-oriented entrepreneur.
It's essential for the development team to understand the perspective of their client, their background, and the industry they come from. Make sure that you know enough about their professional status and level of technical knowledge. That type of domain expertise will be essential in your communication.
Once you look at the project from their perspective, you'll see how they perceive the technical terms you might want to communicate to them. That's how you can adjust your presentation levels and technical language.
Building a digital product that delivers a tangible business value is not about technology. It's about people and their actions – the end-users, organizations, customers, and other stakeholders.
That's why we always focus on the people – be it our team or the customers, and the tasks they're performing for the project. We inform our client about their progress regularly and show them how each team member has contributed to achieving a given milestone in the project.
There's no point in talking about code issues or bug fixes. It won't bring any benefits to you and might make your client uncomfortable. When explaining an application functionality, assume the perspective of the end-user.
Here's an example:
Instead of saying that the system will display the transaction screen, say that the users will land on a page where they can complete the transaction.
The message is the same, but believe us - semantics matter.
Analogy is your best friend when it comes to explaining technical issues to a non-technical person. You need to meet the client halfway and adjust your information to their level of expertise.
We always do our best to present the project's progress from a layman's perspective who has no idea about its technical side. To do that, we use examples like similar products or functionalities in other apps to simplify our communications. Great communication is critical to boosting your chances at delivering a project that really caters to the needs of end-users.
Requirement gathering is one of the most critical phases in the software development process. It's based on a detailed discussion between the client and the development team where some key decisions about the product are made.
If the client doesn't have technical knowledge, it's essential to prepare for that meeting differently then when talking to a CTO. For example, ask your client a set of questions that are easy to digest and understand for the client, but at the same time give you plenty of valuable knowledge.
Limiting the technical jargon in client communications is in everyone's interest. We avoid using technical terms as much as we can when working with non-technical clients. It just doesn't make sense.
Of course, sometimes it's nice to use the names of a few frameworks we’re going to use and explain in a simple words why. The client expects us to be professional, so we need to give them that confidence.
But we do that always in reference to business benefits.
Why lose your energy on explaining to the client which version of a framework has been used to create their application? Who cares that the library has been updated or that you started using a new library?
Technical clients will be interested in these details and demand them from development teams. But a non-technical client couldn't care less about that.
This client wants one thing: A product that works and doesn't include any bugs.
That's why you need to focus on the value of changes that you've introduced during the development process. For example, if you carried out code refactoring or other technical improvements that didn't really bring any value to the product, don't mention them. Also, avoid using internal product codenames.
A demo session will be less attractive to a non-technical client if the development team insists on showing all the code internals and developer tools. Don't open your code editor to add new variables and demonstrate something. Keep the developer tools closed.
Instead, focus on the interface. Click through every screen and show the client the reasoning behind specific UI decisions. That's the best way to present functionalities to the client.
If your team works in short sprints, you may not be able to show that to the client. In fact, sometimes you might have nothing more than code to show. So show it - and mention some facts and figures about the work carried out during the sprint. You can even say how many lines of code were written.
When doing that, developers need to be confident about their work, focus on what they’ve achieved, and say very little about the blockers they met as this can undermine their knowledge.
Expert tip: Do your best to speak the language of your non-technical stakeholders. That will give you a great boost to communication and show that you care about their domain. Don't forget that the purpose of the demo is feedback and discussion. And it's impossible to get feedback from someone who doesn't really understand what's being presented. By using the business language of your client, you will build trust and avoid enforcing a harmful divide between IT and business people.
After developing an MVP for the client, we may have to restructure the team - but the development never stops. Creating software is a continuous process. Without moving forward with your software, you risk that the client loses with their competitors.
With enough experience and the right approach, a software development company can help non-technical clients build amazing digital products without the need for internal technology department or CTO.
Ultimately, we create software to solve problems and make our lives easier. And that's the type of shared understanding that technical teams need to have to succeed. Dealing with a non-technical client might be different than managing a project with a technical person, but it doesn't need to become more challenging.
Development teams that follow the rules we sketched above will surely be able to accommodate the needs of their business clients into their software development projects. We certainly do.
Are you looking for a technology partner to help you build a digital product? Get in touch with us; we help non-technical founders develop applications that deliver real business value.
