If we showed you the version of Easy LMS from 2014, you might not even recognize it! We have evolved a lot since then, and continue to do so. Our company vision, in combination with your feedback, are the two forces that have guided us along the way.
In our ‘What’s new?’ article, you will see that we’ve added many new features in the past year. No matter how many features we build, we receive a lot of feedback and feature requests from you (but we like this, so keep them coming ?).
We wish that we could meet everyone’s expectations, but the reality is that we must pick and choose which features get built. This, of course, is a bit tricky. We want to make you happy while staying true to our vision and plan for Easy LMS. Regardless of whether a feature gets built, it’s a good moment to learn more about your needs and share with you our own goals and limitations. This is easier said than done. Luckily, we have a few mantras that help us navigate feature requests.
Mantra 1: Express gratitude
We love to hear from you, and appreciate it when you take the time to share your ideas with us! Regardless of whether or not we can implement the feature, it informs us about certain trends and gives us a clear picture of what you’d like to see in Easy LMS. Naturally, we’re thankful for the time you’ve taken to share your ideas with us. And, if your feature gets built, we will contact you directly when it is released!
Mantra 2: Make no promises
We can find it pretty hard to say no
We want to be an open and friendly company. So, we can find it pretty hard to say no! When someone requests a feature that isn’t in our broader vision for our product, what we want to say is this: “You would like this built? No problem! We will build it and have it available in two weeks.” Despite our awareness of the product team’s plans for Easy LMS, we still have an overwhelming urge to dismiss this to meet your wishes.
This might make you happier at the moment, but it would be dishonest. At this stage in the process, we cannot know when or if a feature will get developed. Even when we get requests that are already in motion, we cannot promise a date because we would rather take as much time as we need to make it perfect than rush to meet a deadline!
Failing to fulfill our promises would certainly create more disappointment and dissatisfaction further down the road. While no one likes being told no, we would rather be transparent and honest upfront than make promises that we cannot deliver on. And, we typically find that you agree too!
We’d rather focus on building features that will add value for as many people as possible, than be led by specific requests of individuals
Mantra 3: Communicate the bigger picture
In the same line of thought, we are open about the reasoning behind our decisions. One of our main philosophies is that we’d rather focus on building features that will add value for as many people as possible than be led by specific requests of individuals. This view is integral to our decision-making process. For instance, we often get requests where someone offers to pay a fee to have tailor-made work done to their account. Even if we had unlimited development capacity to implement the feature, we don’t build it. This type of custom work would interfere with our vision to bring value to all of our clients with each improvement.
The decision to build one feature over another comes from a conscious and strategic decision by our product owner
To determine which features bring the most value, we have developed a structured system for processing and prioritizing all feature requests that come to us. The decision to build one feature over another comes from a conscious and strategic decision by Jeroen, our product owner. If your feature request isn't built, you can be assured that it was not because we forgot or ignored it. We aim to communicate this to you by sharing a bit about where our main priorities lie at that moment.
Mantra 4: Determine what a client actually wants
Arguably, our favorite part of receiving a feature request is when we get to learn more details about why a particular functionality is useful. It is a great opportunity to discuss the details about your individual use case at length! We enjoy this process, and it helps us see the real source of the feature request.
The combination of understanding the use case, and the source of the problem, gives Jeroen clues as to the best way to solve the issue. Sometimes a different feature entirely will work best! We are even happier when these discussions end in the conclusion that an existing feature within our tool can achieve the same aim ?.
