What’s a bootstrapped entrepreneur’s favorite three alphabets?
The answer is DIY and there are no prizes for guessing!
One of the things every bootstrapped entrepreneur should do is to take ownership for testing their product and not leave it to the engineering team. Wondering why this is important? Here are four great reasons why you should get your hands dirty!
- Keep the working product aligned with your product vision
You are the custodian of the vision for your product and only you (along with your co-founder(s), if you are lucky) know what you wanted to build in the first place. Everybody else is subject to what I call the “idea transmission and distribution” (ID&T) loss.
- Wear the customer hat
Hands on testing is the best way to understand how your customers will perceive your product and interact with it. This is especially true if you are not a technical co-founder.
- Do you have a great product feature or a giant face palm?
Testing your product is a great way to find out if the key features you defined in the product specifications is actually worth all the hype you created.
- You don’t have the money, so…
You probably cannot afford to hire an independent QA team when you are a bootstrapped entrepreneur.
I learnt these lessons when testing my product
Let me share with you some of the practical lessons I learnt the hard way when I launched the beta version of Jodi Logik Just to make it clear, I am no QA expert and I am also not a hardware guy. My experiences are all about software product testing.
Lesson #1 Are there errors in error messages?
Seemingly simple products have astonishingly a large number of scenarios where the user has to be shown an error message. It is your job to review all these error messages as well as all messages thrown up by the application when it encounters exceptions. I bet my last Rupee that if you have not looked into it yourself, you are screwing up customer experience and missing out on an opportunity to impress your customers.
Look for spelling mistakes, inconsistent language style, grammar mistakes and make sure your customer can understand what the problem is. Use these error messages to set a tone and give your product a personality.
Check out the message in the screen above. The error message not only has a “personality” but also nudges the user to complete the required task before performing an action.
Use error messages and notifications to create a personality for your product and make sure they are reviewed thoroughly.
Lesson #2 Use simple English that everybody understands
Avoid writing the error notifications like Agent Smith from The Matrix (aka machine). Example: Phrases like “Connection timed out”, “Server error” may be easy to understand if you are already exposed to the IT industry. However, it may not make any sense to the average customer who is already doing you a favor by trying your product. Make your customer’s life easier by using simple phrases that the average Joe or Kumar can understand.
In the case of Jodi Logik, when the Internet goes down, the error message is something along the lines of “It appears your Internet connection is down. Please check your Internet connectivity and try again.” As you can see the application handles this issue elegantly and communicates clearly what the issue is in a simple language.
Use simple and easy to understand language when communicating with your users. Avoid jargons and industry terminologies.
Lesson #3 Test for use cases that’s applicable to your target market
If you are launching a consumer product in India, one of the use cases you should watch out for is what happens to your software product when the Internet goes down. Reliable Internet, along with reliable power continues to be a challenge in most parts of India. Other use cases that’s applicable for markets like India include, low bandwidth performance of your application and support for mobile browsers. Just make sure your application is tested for real world scenarios using devices that your customers use.
Here is a tip – Google Analytics will tell you how your customers use your product (browser / location / operating system) Make sure your test cases takes this data into consideration.
Lesson #4 Banish “Cannot reproduce the error” excuse
Early in the days of testing Jodi Logik, I encountered a strange phenomenon with my engineers. They will outright deny the existence of an issue! Later on, I realized that they are probably overworked and believe in the philosophy – “If you can’t see it, it doesn’t exist”. This is very much like driving in India.
To counter this behavior, I started documenting the issues in a Word document and made it a point to include a screenshot. If a screenshot was not included, I made a note of the date and time when the issue was recorded. This allowed my team to check the server logs and unearth issues that seem to have a habit of disappearing when you actually want them to show up! If you are adventurous, use GitHub or any other open source bug tracking tool.
Document everything you do when you are testing the application.
Lesson #5 Don’t use an issue to introduce scope creep
Every issue or bug you identify during testing can give you ideas for improving the product. This is good and bad. It is good because you know how to improve your product (duh!) and it is really bad because you may go overboard to solve it and end up delaying the launch of the product!
Here is an example. One of the features we have in Jodi Logik is the option to upload the horoscope of the user when creating a marriage biodata. One of the issues I Identified was the inability of the application to handle a scenario where the user uploads a blank horoscope document. It was an easy fix as far as Word documents are concerned but the JavaScript we used did not provide for making sure PDF files and image files aren’t blank. We chose to tackle this issue later and did not attempt to fix it as we felt fixing this issue can is probably time consuming with no commensurate returns. We asked ourselves, “How many times a user will actually upload a blank document?” and then concluded that this will be a rare occurance.
Moral of the story – Don’t fix an issue for the sake for fixing it. Always consider time, costs and returns.
Lesson #6 Catch me if you can…
It doesn’t matter if you are testing your product on your own or if you have an accomplished QA team (highly unlikely), your product will have bugs and you will never catch them. All the bugs that slipped through your fine-toothed reviews will show up when a customer uses your product and that’s how the world works. The reason is simple – What is obvious to you is not obvious to a customer.
One of my customers wrote to me saying that a text field where she writes about herself is not working properly as the text appears spaced out. After some serious head-scratching and suppressing the urge to say, “I cannot reproduce the error”, I figured out that she copied the content into the application directly from a Word document. This introduced the formatting associated with the Word document into our application and completely messed up the interface! This is a scenario we never tested!
Find every opportunity you can to help a customer. You will be surprised with what you will discover.
Lesson #7: Are you looking in the right place?
A man lost a ring when walking in a dark alley. He was found searching for the ring under a lamp far away from where he lost the ring. His excuse was that it was dark! Sounds elementary, but I did just that for the first few product releases.
Here is my sorry tale. Jodi Logik runs on a Linux environment and I did all the testing on a Windows box before moving the code to the Linux server. I quickly realized that not having a staging platform that’s a mirror of the production servers only adds to our misery every time we wanted to ship code. I also realized that the development instances should also have been on Linux to begin with.
Get your staging platform up and running along with your production servers. This is one expense that you should always find a way to pay for.
Conclusion
Testing your product before going live is similar to a chef tasting the dishes he cooked before serving it. It demonstrates your ownership and a commitment to delivering only the best experience for your customers. The lessons I have shared are by no means comprehensive but I will be mighty pleased if you even get a single takeaway from this article. Please share your experiences and any other lesson you may have learned testing your product.
Guest Post by Srinivas K, JodiLogik