Tips for building software for professionals
Professionals are people who are engaged in an activity as a full time occupation. We are all hopefully a professional at something and so we can all benefit from professional grade tools. I buy and appreciate professional grade tools at work and I love the challenge of building tools for other professionals.
Pros don’t use multi-tools, build less features, execute better
One of the traps when building tools for professionals is building in too many low value features at the expense of execution. Whether you are building a CAD tool for engineers or a control system for machine operators, it is tempting to think that you can build one tool that does all the things that a professional requires, the reality is that is usually impossible.
Instead of quickly building as many features as you hear your users would ‘use’, research your target early adopters thoroughly and then use the Kano model to categorise possible features as attractive, one dimensional, must have, unimportant and undesired. I believe your first release should contain the must-have features and at least one highly attractive feature. The must-have features should be executed to a level where they perform adequately and reliably under repeated use, including them shows you understand what is truly important. The highly attractive feature should be implemented to a higher standard because it will attract attention and will provide your users with a reason to be excited about your product.
Your first release may alarm users who notice the absence of some one-dimensional features, so you may benefit from first promoting a beta access program to highlight the immature nature of the product. After your first release, steadily work through implementing the one-dimensional features to a very high standard, releasing these will show that your product’s capability is growing and that you are focused on quality and performance. Rushing at this stage and poorly executing any feature can be fatal to your reputation.
As pointed out in the Kano article, after the initial excitement about your product has waned, you should be using ongoing research to find the next attractive features and to improve one-dimensional features. At the same time, your competitors will be copying your previously attractive features, requiring you to improve them to the point that they remain best in class, otherwise it will appear that each time you have a good idea, your competitors will deliver a better version of it.
Research, observe, find pain to alleviate
As you are studying your users and looking for attractive features prior to building a new product, it can be tempting to see their work in a completely different way and decide to introduce a ‘new way of working’. This often leads to product failure because it is unlikely that you understand the professional’s work and constraints as well as they do. Too often, that ‘new way of working’ is impossible for your users to implement.
Instead, identifying and solving pain is easier than entirely changing your user’s process in your early releases. The must-have features allow your users to complete the tasks they have to do, the highly attractive feature could be solving a particular problem that users suffer with existing products. I have noticed that pain points often come from suppliers not engaging their users properly, either for research or feedback. Pain points I have observed have ranged from difficult integrations with other tools an engineer uses ranging to physical pain from a control system requiring too many awkward interactions.
As your product matures and you grow a large installed user base, you will probably have sufficient understanding and trust to start changing the way your users work if it will help them be more effective. Approach this slowly with lots of testing by real users, you want to be certain that the new way is innovative and valuable, rather than just a misunderstanding of your user’s process or constraints.
Performance matters, push your product hard with tests
Testing your product with two users in the office does not replicate the use of your product all day, every day in a professional setting. Have you ever been surprised when your application’s performance degrades as millions of records are added or your machine control system doesn’t work in the jungle when it is 35 degrees and raining? You need to anticipate the worst conditions under which your product will be used, then spend time and money to simulate that with testing.
When you are building professional products, it is mandatory to make this sizeable investment in performance and reliability testing early. The reason is that reliability and performance matter a lot to professionals. Your users have to trust you and your product, because when their tools fail it costs them money and makes them look bad. This is a different dynamic to consumer software, in which failures usually do not impact the user financially. This can easily catch out teams who rush to market to test ideas, its great to do an MVP, but make sure its limited feature set is reliable and performs adequately in the environment in which it will be used.
Have professionals test your product
Despite the best efforts of your team, you are not going to be able to test the ‘feel’ of your product in the way a professional user can. You will not notice the small niggling things that become infuriating with repeated use. You also need to test if the flow and logic is obvious to people that have different training and experience to you.
One of the traps here is testing with someone who was previously a professional user, but is now on your team. The problem with this approach is that the type of professional that leaves their profession and joins a software team may not be representative of your target users. There really is no substitute for testing with real users prior to broader release.
