Schoolyear is actively being developed, and we truly value the input of our customers in that process. Based on feedback our product managers can get a better picture of the obstacles our users face while using our product. In our development strategy, we are actively searching for these obstacles and innovative ways to solve them. In that strategy, our customers are never more important or more influential than others. On the contrary, we never agree with customers about "a percentage of influence in our roadmap". Simply because it has shown that this leads to unsustainable products.
Problem focused development
But what is our game plan then? To put it in 3 words: "Problem focussed development". We distinguish 3 types of feedback:
- Security findings: We actively search for holes in our security, but sometimes a customer or a pentester gets to them first. We put effort into fixing these findings as soon as possible, which is part of our never-ending cat-and-mouse game.
- Obstacles: We are constantly having conversations with our customers and often an obstacle is identified. These obstacles will always be passed on to our product managers. It is their goal to make categorise this stream of input and develop coherent user stories. These user stories are then placed on our roadmap.
- Feature requests: Instead of feature requests we collect user stories from a specific customer. User stories are often presented a bit more formal than an obstacle that is discussed during normal conversation. When a feature request is received we start investigating the underlying obstacle the customer is trying to solve. Our experience learns that there is always one. Once we find it, we insert it into the normal stream of input, just like any other obstacle we investigate. Feature requests are rarely copied as-is onto our roadmap. Instead, we try to find common solutions that will eliminate obstacles for many customers in one go. The advantage of this, for you as a customer, as opposed to the 'percentage methodology', is that you benefit from all our developments instead of just your percentage.
Roadmap
Periodically we publish a roadmap to communicate to all our customers what they may expect. Large organizations have to plan far into the future; it helps if we sometimes give you a glimpse into the future. Bear in mind that these are glimpses into the future for us as well and that plans are just that: plans.
Items on our roadmap begin their journey as user stories, not as detailed descriptions of their implementation. As items near their target date, they are supplemented with implementation details and technical descriptions, until they are ready to enter our development cycles. We explicitly divide our development time not among customers, but among user stories.
Influencing the roadmap
Often we get the question of how customers can influence our roadmap. The best way is to submit a concrete obstacle you are dealing with and would like to see solved. For example 'currently we spend one day every week on X, that is a lot of time' or 'we have to enter everything in system A and B, that makes the entire process prone for errors'. We then group these submissions and start brainstorming sustainable solutions. In this way, we solve many obstacles at once, allowing us to efficiently serve products that are useful to all our customers. Additionally, by grouping obstacles together we might eliminate one for you even before you run into it yourself.