Build a minimum viable product (MVP) and get it out into the market. That’s what everyone says.

It’s good advice.

But in a mature market like help desk applications, we realised the “viable” line is quite high.

High Bar

In this market, there’s a lot of existing options at lots of different price points. But it’s also huge, with tens of thousands of businesses who would benefit from such a system, but who don’t currently use anything. New companies are started every day that could also benefit, so there’s always an opportunity.

Entering a mature market with a basic system would be incredibly difficult. We’d look immediately poor in almost any comparison. Not only would we be the newcomer, we’d also be the newcomer with no features. It seems unlikely that anyone without a system, or an existing system, would therefore be willing to give it a try.

A help desk is also very different from SaaS products you only use occasionally. For a support agent, using the chosen help desk product is their job, and they will live within it every day. An MVP which irritates due to being poorly thought out isn’t going to last long.

Understanding where your bar is will dictate the rest of your build.

Research

The other reason to get your product out into the market is to determine market fit. But in a mature market, there’s plenty of systems out there to compare against to see what they’re doing to satisfy it. Despite having previously built an in-house help desk product, and having previously run a help desk team who got 100 new tickets every day, a big part of the process was researching as much as we could. That meant not only looking at competitors, but also trying to understand what it was about those systems the users didn’t like. Reddit and other forums were invaluable here, reading the communities of those competitors and finding trends. Find out where your potential users are, and see what they have to say, without having to ask them directly.

Pick Features Carefully

The next challenge is picking which features are important enough to go in at launch, and how deep those features should be. Finding the magic combination of what to include, and what to keep on the backlog, has been one of the hardest parts of the build. Some features are obvious, like being able to accept a ticket and reply to it, but something like Service Level Agreements may only be used by a small percentage of potential users. Go deeper, and let you define target percentages that SLAs must meet, and that’s going to be an even smaller subset. But in a feature comparison between you and the competition, that may be the combination that makes the difference.

Just know when to stop, or you’ll never manage to release anything.

Specification vs. Reality

We wrote a detailed spec early on in the process, so the team knew exactly what they were building. It had two purposes, model out the data and how customers would interact with it, and more importantly, explain why the feature was necessary. As the project leader making the decisions, bringing the team along on the journey was a key goal. It also meant that once things were working and we started doing our internal testing, we were able to measure our success against our original reasoning.

Like any project, there’s a wide gulf between what you think will work on paper, and what actually works once you’ve built it. This is where our make it real process becomes so important. Getting everything up and running as early as possible means you can quickly find problems and fix them before you’ve gone too deep.

Time

Finally, everything takes way longer than you think. We started this project almost two years ago with just two developers, so it’s been a long road to get to here. Iteration of features, changes of design, realising things were missing - it all adds up. Hopefully you make the right choices in your project, and hopefully we made the right choices in ours.

If you’re interested in trying Issuebear for yourself, with a free trial, learn more.