Client Or End User: Whose Opinion Is More Important?

When you hire a software company for your project, their main task is delivering a product that will satisfy your demands. The requirements that you set, the features that must be done, and in the end the product that works - everything simply like you want, according to your own vision of the product. But will the product that satisfies you, satisfy the end users? Does this product solve their own problems? Well, it's for them to judge.

If your software company has created a product that is just what you wanted, fulfilled this hard task, they get a number of benefits. First of all, it's the pleased client and the money received for the work. Second, it's the opportunity to carry on with the project. If we talk about software projects, it's support and further development of new features etc. Third, it may be good further recommendations and testimonials, good relationships with the client. Fourth, it's the inner feeling of satisfaction and pride for the creation. A great and useful product has been created and deployed, and the client is happy.

What does the contractor do to make the client happy with the product?
- meets all of the client's requirements towards functionality;
- delivers a product of high quality;
- performs timely, productive communication;
- demonstrates proactiveness, generates new ideas (actually as a part of communication).
If all (or at least the majority) of these points are fulfilled, the contractor gets the benefits mentioned above. But is the end user happy? That's a good question. Let's look for the answer below.

What might come next? The software product is deployed, and there may be the first bad signs - the application simply isn't downloaded, and there's no feedback, or there is, but it's largely negative. Users suggest changes in features and user interface. Without some of these changes, the software won't have value - and there's always something else for users to switch to. The spent budget doubles in order to make the product viable. Here comes the client's dissatisfaction - why weren't these suggestions foreseen by the contractor? After all, they are professionals.

If the contractor aims at a short-term benefit, it's enough to strictly adhere to the client's requirements and deliver the product. That's it - the contractor works for the client, not the end user. If the contractor aims at possible long-term relationships with the client, if the contractor wants to bring a truly useful product to the world - it's essential to think about the users' needs and to figure out their problems that the product will solve.

As a rule, the client is an expert in the subject area. But as well it's designers and developers who know how to create a usable, intuitive software product, make it work, interact with the user seamlessly. Here it doesn't matter whether the product is created for the mass market or for in-house purposes. Anyway it's created for the people who will use it - not the client.

The contractor must fulfill the client's demands, while the client must think over demands of end users.
That's not an easy thing to tackle. The client should not only be the expert in the subject area, but as well in business modeling, marketing, design and programming. Is it always so? More no than yes. That's why the client and the contractor must collaborate on the product. The client must have the following information about the future product, which makes up a well-known pyramid of values:

Mission - the main goal, the very sense for the product's existence;
Goals - what you want to achieve with this product;
Opportunities - what the product gives to users;
Capabilities - what the product can actually do;
Users - for whom the product is created.

All of these allow step-by-step to know who the users of the product are, and what they need. Now it's more likely that the client and the contractor will create a better software product together. It's also vital to know if there's budget for marketing, to build convenience first, only then build beauty upon it. And of course, it's important to return to feedback - statistics, beta testing, feedback forms etc. All of this must be planned and developed beforehand, and after the release the software owner is able to track the success of the product and watch the reaction of users.

The contractor will obviously ask plenty of questions to know more about what you want and what the product must be like. If the contractor puts forth suggestions (which are often rejected by the client, and that's a normal thing), they must be supported with facts, links, they must be thoroughly checked before they even get through to you. These suggestions must be useful for both the client and the end users. The client may ask for these consultations in case of need.

So whose opinion is more important to increase the chance of getting positive reactions? The answer is: your product - your opinion, but never ever forget that you create a product for users. You are an expert in the subject area, but developers have experience in creating usable good software. This is the combination that works. Check everything from user's point of view. Always care for quality - users won't like a low-quality product. Study the market and statistics, make your product the best for users from the very beginning. Working for users, you work for yourself and your own success.Follow Engee's Business Guide on Facebook and Twitter