Why we don't have a roadmap
A lot of companies share their roadmap enthusiastically with their clients. Although our clients ask for our roadmap now and again, we do it a bit differently here at Easy LMS.
Definition of a roadmap: a high-level visual summary that maps out the vision and direction of your product offering over time. A roadmap communicates what you’re building.
A lot of companies share their roadmap enthusiastically with their clients. Although our clients ask for our roadmap now and again, we do it a bit differently here at Easy LMS. We don’t have a roadmap. But we do have a vision and a process! Don’t worry, we are structured and have big plans.
Our arguments for not having a roadmap
Throughout the years of building software and running Easy LMS, we’ve learned through trial and error the disadvantages of having a roadmap, and what works for us. Not having a roadmap is not the same as not having a plan or a process to decide what to build. As you know, we value our clients' input for our product, and we urge all our clients to share their thoughts with our Support Owls so we can learn from them.
Creating a roadmap is easy, building a great product is not
Adding a line to a roadmap takes no effort
Roadmaps tend to be shallow representations of the actual features. Adding a line to a roadmap takes no effort: October and November 2020 - build a new player interface for exams. You see, that only took me five seconds. But, do you know what you will get? Does the team know what to build? Nope. Defining, designing, and building that feature takes a lot of effort. Preparing that feature for the design and development team takes us around 40 hours. Building a feature can take from a couple of days up to six weeks. So, for each line added to the roadmap you create development debt, that feature has to be built.
Do clients buy our product for what it is now, or for what it might be in the future?
Sell today, not tomorrow
Do clients buy our product for what it is now, or for what it might be in the future? If we sell our product on a future feature, there is a big chance clients will be disappointed. Based on that line on a roadmap, the client thought he bought A, but most often gets B. A line on a roadmap is just that. A line on the roadmap. It’s not the actual feature. That line can and will be interpreted in a thousand different ways. When the feature finally arrives, the client is disappointed, or worse, thinks we tricked them into buying our product. To prevent this we don’t have a roadmap. And if we’re honest we know that clients that choose a competitor over Easy LMS don’t do so just for one missing feature. They go to the competition because that product is a better fit for the client's use case. That can’t be solved with just one feature. We like to sell today, not tomorrow.
It’s bad for motivation
While selling the product on future promises, those features carry development debt, they have to be delivered. This development debt is demoralizing for the development and design teams. They have to build something promised yesterday, or worse, a couple of months ago, instead of building something relevant and valuable today.
It takes away freedom
We like to have the freedom to build what is valuable today
Adding something to a roadmap is like making a promise. Especially if a client buys our product because that specific feature is on the roadmap. And promises have to be kept. This promise takes away our freedom. The world is constantly changing. Feature requests from clients keep coming in. We keep improving our vision of the product. Competitors release new stuff. New tech becomes available. If our roadmap is filled with things to build far into the future we can’t be agile. We like to have the freedom to build what is valuable today. Not what was important last month.
How we do decide what to build
While we don’t have a roadmap, we do have a process in place to decide what to build. We continuously gather information from different sources on what to build. Our main source is our clients in our target audience, small and medium-sized businesses that focus on employee and customer training. Our Support Owls gather feature requests all the time and send them to me, the product owner. I’m constantly working on different feature pitches based on those requests. I’m refining them and take into account the feedback from our designers and developers. Those features are in different stages from early ideas to pretty detailed solutions. Every six weeks I sit down with Job, our CTO, and we decide what to build in the next six weeks. The teams will build new features in two three-week cycles. And then we decide again what to build. This gives us freedom, agility, and focus on delivering value to our clients every three weeks.
We would like to hear your thoughts and your feature requests. You can get in touch with our Support Owls using the chat tool.