Team Testomato is a small team that’s mostly made up of engineers, similar to a lot of the project teams at Wikidi.
For the most part, this is a good thing. We have a lot of energy to build and as a result, we’re able to accomplish a lot of progress.
But with a caveat.
We love to build, but this also means it’s easy to forget there are other important components that go into creating a product that should matter to us as developers.
We wanted to share three lessons our team has learned about building a product that we feel are important for developers to know in the hopes they’ll help you with your own development process.
Positioning Should Matter to Everyone
It’s incredibly hard to satisfy customers if you don’t know what they need. And in order to understand what they need, you have to know who they are.
For example, we originally planned for Testomato to be more of an alert system for less technical website owners or agencies. So, we were surprised to learn that Testomato was more useful for developers building projects than for the people managing them.
This discovery transformed our roadmap, and we had to gather a lot feedback to learn more about our new target users.
But consider the alternative – we could still be building for people that were never going to use Testomato.
In a team as small as ours, we all have a responsibility to contribute our thoughts about where we want Testomato to go in the future. There’s no lack of ideas or inspiration, but one thing we all have to agree upon is whether or not it’s the right decision for our users.
Developers shouldn’t just implement. They should know who their service is for and why they are building.
In order to create a great application, everyone has to be part of the feedback loop.
Everyone Should Test as Much as Possible
We learned this one the hard way. You may think because Testomato is an automated testing product, we’ve got all our ducks in a row when it comes to testing.
But that’s not always the case.
About a month ago, we lost a new user because there was a glitch in our introductory tutorial that was causing an overlay to completely freeze. The user was unable to get past our tutorial and when we didn’t respond fast enough to their complaint – they left and never came back.
Sure, you might say, it was one customer. But because we had failed to catch this error in our own service, we had no idea how long it had been there and how many new users we lost as a result.
For some of you, testing may not seem like it’s a part of your job description, especially if you have a tester working on your team. You write and deliver quality code, while testers find errors or unexpected variations in that code.
But here’s the bottom line: Products should be tested and used on a daily basis by everyone on the team – and that includes developers.
Customer Support Is Part of Your Job Description
As developers, we’re sometimes tempted to view customer support as outside of what we do.
But it’s not.
Some of the best web and mobile apps today are built with customer support in mind, and it’s probably costing you more business than you realize if your product doesn’t have a strong support system.
Here’s how we see it: Developers need to build a product that allows users to easily process a problem, and they are also instrumental in helping provide support.
At Testomato, we have help docs, a way to easily submit feedback, and an email address to get in touch with the team directly. While our support efforts are not managed directly by our developers, they are still an integral part of the entire process.
All issues and feedback are submitted to them directly. This ensures users get the best information and also keeps everyone on the same page about requests.