by Volodymyr Kis
PM at Inoxoft
I wrote this article based on my personal knowledge as well as a couple of quite insightful presentations from Lviv IT Arena I was lucky enough to attend. I am happy to share this knowledge with you.
Customer: This is not what I expected!
One of the key business analysis techniques that almost everyone is prone to ignore, is quite obvious – asking ”five whys” while defining the customer’s problem. Instead of having a “feature-feature” conversation, you should better have a “need-need” conversation with your customer every time he/she requests a new feature. Just simply ask ”Why do you need that?” or ”What type of problem are you trying to solve here?”. Don’t be afraid to ask this type of questions, since it’s crucial to define it at the early stages of the project lifecycle. In fact, I would recommend you to differentiate between the types of requirements. Let’s dwell upon the business requirements and software requirements. People often confuse those.
But the easiest way to understand the difference is to think about the following: What should be built (Business requirements) vs How it should be built (Software requirements/Design).
Always remember to answer the following key questions first:
- What’s the problem?;
- Who has it?;
- Why does it matter?.
Only when the problem is defined, think of the following:
- What’s the best solution?;
- What works what doesn’t?;
- What causes what?.
Make sure that the first two stages are completed and clarified – and only then start building.
Customer: Users are not designers!
Perform user testing regularly. Why? Who will want a product that nobody wants to use or that nobody needs at the end of the day? Observe how users are actually using your product. Gather feedback and see what can be improved. If your customer is against user testing – take initiative and make it on your own. Why not? Here in Ukraine, we have a lot of outsourcing companies, meaning that the target market is somewhere abroad, so try to find a similar target audience at your place – in your country. Conduct user testing. In case you gathered valuable feedback, present it to the customer. If the feedback is negative towards something, assure your customer, that if he/she gets the same or similar feedback once the product is final from his target audience – the cost of rework will be amazing. He would definitely not ignore it.
Stay focused not only on ‘one thing’ that will really delight your customer, but also think about the value it will bring to the users and prioritize your scope of work accordingly.
We know what our users want!
As an outsourcing team, we should not identify ourselves with our end users. We have to dig deeper in order to find out our user’s thoughts, motifs, and needs. Of course, we know where things are in our product, what UI elements mean and why UI elements are there. We all know how to use the product because we have built it. But sometimes we cannot even understand why our users ask questions or don’t know something. We should think more about how our users feel by putting ourselves in their shoes. Of course, ”knowing too much” of the product is inevitable for us, but we should make it conscious.
We should realize that while we know the product, the users may not and we need to educate them and make it as simple as possible for them to love it.
The key tips here are:
- talk to your network often;
- treat your customers well;
- build an extensive network;
- understand your customers’ lives;
- think how you can be a better listener.
Learning about your users will change your perspective. You must be able to change your product easily as you learn. Learning reduces the risk of building the wrong product. In fact, every team member, no matter of what position, should spend at least 2 hours every 6 weeks with end users.
