Startups have lots of ideas for new features for their website or application – and usually want a code change to be implemented immediately. Even in the most efficient agile teams, a code change takes a sprint to deploy, which is usually 2 weeks. By that time, lots of startups have moved on to the next exciting idea. This is good! Having a firehose of ideas on your team is an incredible asset. The problem arises when you try to point that firehose directly to your development team.
A common problem startups face is trying to figure out what is a pattern and what is a one off. Imagine this scenario
A user asks for a new feature, and it sounds great! Send it to the developers, and let’s give the user what they want. A little while later the developers deploy the change, but only the one user touches it. Even worse, that user leaves the platform a little while later, and now there is a feature that no one uses.
This is a problem we see lots of startups run into. Now precious development time has been wasted on the shiny new thing that added no real business value. The user might have been the start of a pattern, maybe all users want what this user wanted.
The instinct most startups have is to make lots of code changes, and add as many features as possible. The cycle of building features no one uses repeats itself with any request from a user, until the team slowly learns to filter new feature ideas and requested code changes.
This learning process is expensive and time consuming. The best start to avoiding this problem is to be aware of it. Once you’re aware of the problem, you’ll be slower to act on new feature requests, which will naturally filter out the good requests from the bad ones.
Something we often say to clients – we can do anything in code, it’s just a question of how long it takes. While code changes can fix most things, the question we should ask is whether a code change is the most efficient solution.
How to know if a code change is the most efficient solution
The best way to find out if a code change is the most efficient solution is to talk to your developers. Having developers that can see the value in no-code solutions is hugely important. Developers who have this skill usually go through this process:
What is the need the user is trying to fill?
Oftentimes the thing the user asked for may not be exactly what solves their actual use case. For example:
Someone downloads your app and lets you know that they would like weekly text notifications reminding them to do something. Adding texting and a weekly running job opens up a whole host of technical problems that will take weeks to solve.
Their real need is to get notifications, which means you have several options to choose from. Talking with your developers will let you know which option is the most efficient use of dev time.
Can we solve the problem without code?
For this example, we can very easily solve this without code. Someone from your company can manually schedule texts to send to that user once a week. If push notifications exist on your mobile app, you can have someone manually trigger a notification to that user once a week. This solves the user’s need, makes them happy, and doesn’t take weeks of developer time to implement.
Another perk to this way of doing things is that you get user feedback before the feature is finalized in code. During this manual process you might have figured out a few things. Maybe users prefer to be texted at night, or they only want messages through whatsapp. These things are much easier to figure out and adapt to during the no-code process.
Is this worth building out in code?
Now that we’ve solved this user’s need, we can keep an eye on it to figure out if it’s something worth solving in code. If more users would like this feature, or the addition of this feature has increased engagement with the subset of users who have used it – it’s probably worth building out in code now.
You should know that something is going to add business value before you write it out in code, especially if there is a no-code middle ground to test out the feature.