Voting for features?

MyRoute-app community

User @Callewaert-Francky mentioned voting for features in another thread so I thought this would be a nice source of discussion here on the forum. As I wrote my reaction I decided that if this turns out into a productive discussion we should probably move it to a different topic

It's an interesting idea that we've talked about on a lot. There are some concerns for such workings but we'll definitly consider it if the community is able to help us avoid problems. I'm going to dedicate some time to explaining it in this post, please forgive me if I over-explain or come across as patronizing: I'm simply trying to involve as big a part of the community in this as possible.

Let's start.

The problem of decision making
Imagine an obvious "we all want this really much" feature such as elevation. Now, any user on MyRoute-app will certainly enjoy being able to see elevation while tracking, planning a route or while for example showing a route to friends. But how do we know this?

Right now we know things like this because first of all Michel (the CEO) is an avid motorcyclist and has a lot of experience with route planning software and navigation devices on the end-user spectrum. Michel knows that by having elevation you're able to not only make a route more twisty, but also increase it's elevation pattern (very relevant for cyclists for example). Daniël, me and the other guys at the office know that this would be useful because we heard users about it and are able to deduct the relevance of such a feature from our direct surroundings (and having a good dash of creativity).

So we're completely on the same page there. Well, go ahead you must think! Forward into development, let's get that elevation profile done! We'll get started right away. But then something hit us: we also want to get Android Auto and Apple Carplay online and to be honest that would be a lot less technical work. With the same train of thought that we had before, we're able to deduct and verify that indeed Android Auto and Apple Carplay would at the very least be just as good as a new feature as elevation and there's another bonus: development doesn't need to get involved immediatly because management and finance will first need to pry open the closed doors of those tech giants to allow us access. Alas, management and finance are also caught up and in the end everything will still cost a lot of resources. Thus we might as well go ahead and just get everyone rallied around investing heavily into adding a suite of small new features that won't satisfy any existing user but would probably draw a lot more hikers and runners (a demographically small group right now) to MyRoute-app and the community around it.

Now let's look back on all that, what happened here? Why are we unable to develop things that would either be good for a certain group of our existing community (elevation), develop an innovative feature that would help in guaranteeing durability (Carplay) or invest heavily into an oppurtinity rich part of the community (more hiker features)? It's because those are all equally important and competing factors.

The community must be satisfied; and therefore we develop features that the community wants (elevation)
The community must continue to exist; and therefore we develop with the future in mind (Carplay)
The community must grow; and therefore we try new things (hiker features)

This balancing isn't done in weekly, monthly or even quarterly meetings. It's a continuous process that isn't entirely clear at all times but that translates fairly well into gut feeling because we're all experienced and work with a relatively small team. Of course we're expanding at the same time, so we've started to work with a strategic, tactical and operational goals, but that is an entirely different story. To get back on it, we know what can be done immediatly and what can't. We know when a feature is in harmony with all three goals and when it isn't.

The self regulating community and voting
Does that mean that the community should not have a voice? Absolutely not. In fact, the reason why we started this forum is because in part because we want to make the community self regulating and an even greater source for inspiration. The community will not be a blindly following trailer attached to a vehicle that they don't control, the community will be like a sail pulling MyRoute-app in the right direction.

Now in all honesty voting would be a very crude way to let that sail up. It would certainly work for some features, so in that sense I agree with you that we'll sometimes use it, but it certainly shouldn't be the way our community continually steers the future of MyRoute-app (in my opinion). Why? Because voting as a general way of doing things has it's own problems. In politics today we see what happens when governments get elected because people don't want to vote anymore and only a fraction of the population goes out to choose who'll rule them for the next few years. On our scale that might cause a loud minority of the community to push through features that are not in the best interest of the majority or all of the three outlined factors. Ignoring a vote, even if it's better for everyone, would certainly look bad.

So how could we fix this? Well, first of all discussions on this forum might come up and we support that. A critical mind considering and lobbying for a feature and it's relevance on an intellectual level is far more effective and responsible than a poll could ever be. Of course such discussion should be substantive, but that speaks for itself. Secondly, the first-among-equals of the community should be involved as decision makers. It's why we're recruiting RouteXperts, Instructors and Community Leaders. MyRoute-app will then factor in what's seen here on the forum and what the aforementioned groups tell us, compare it with the earlier outlined factors and come up with an order of implementation for features.

In conclusion
So to anser your question: the community is already involved and is actually getting more involved in helping us prioritize, having votes on everything would hamper that. What we don't do properly right now is clarity and transperancy into development. The forum and community blogs will be the first steps towards that. Perhaps we'll even grow a kind of "community decision board" over time, but we'll first see how this works out.

I hope I have explained everything as clear as possible. Feel free to share your thoughts and ideas!

Nick Carthew

I agree with your sentiments and without getting too political; look at the UK and the way the Brexit vote is going!!!
3/4 of the MPs do not want Brexit and are intent on stopping it from happening despite the 17.4 million people that voted for it. 160 MPs voted to leave and 486 MPs voted to remain. Voting isn't necessarily very democratic.
I like your analogy, referring to being gently pulled along by a sail As someone who lives by the sea and occasionally sails, this made me smile

Drabslab

@Timo-Martosatiman-MRA

First, don't worry about sounding patronizing, when staying polite, one can say anything (almost )
Second, I have some experience with software development as business owner, business analyst ... of a few major developments and what you are escribing above sounds quite familiar

Voting (or "liking" to use more recent terminology) on feature requests indeed is not the golden bullet but it can be part of a priorisation strategy. It could allow to determine if a feature request is the wet dream of a single person, or whether it is broadly shared by the larger user base.

At some moment in time I used this together with complaint frequency, and "known bug" lists to identify priority clusters for development or evolutive maintenance. You may say that you already know where the issues are. I originally thought the same but structuring that knowledge gave very useful insights, resulting in increased efficiency, nevertheless.

I am however negative towards a "community decision board". It is the developer/owner of the software that should decide. On the other hand, involving users in analysing a functional area before programming starts may be a must have. In my experience, people who know their business (in this case travel and routing) even when having absolutely no IT knowledge, can add huge value in describing what they need. Then it is up to the technicians to decide the how.

Anyway, it is not up to me to tell you how to manage MRA, and that is most probably a very good thing too

Nick Carthew

Good feedback @Callewaert-Francky

MyRoute-app community

@Callewaert-Francky

Thank you for replying and sharing your insights . It's always great to learn new ways of looking at things and I'll certainly remember the part of combining bug lists and feature requests as an internal mechanism. I'm not sure if it was your intention but I can imagine an internal staff-wide, nicely visualized, tracker for things like this.

A decision for such a feature is interesting to think about. Obviously making it easy for users to prioritize bugs and problems would be a great help in identifying things that ruin satisfaction, halt growth and endanger continued existence. At the same time you don't want to go around welcoming new users with "Hello, please use our services that has this list of problems". On the other hand, perhaps that only sounds bad but would actually be a welcoming change , I'm not sure. I'll definitly think about it.

Drabslab

@Timo-Martosatiman-MRA

I agree that a bug list is best kept internal on condition that bugs are fixed within a reasonable amount of time, otherwise user frustration will fill the forums, and not only the MRA forum

In first instance you don't need a fancy tool. Making/maintaining it will cost resources that are lost for the core business, and that fancy tool (for internal use only) will impose itself preventing the company from moving on to better working methods.

Also, I would be careful bringing too much concrete info on the (future) functioning of MRA to a completely open forum. You should probably not be helping the competition to write their functional analysis.

MyRoute-app community

@Callewaert-Francky I wasn't really planning on building anything, more like a nicely styled smart spreadsheet on Google Docs somewhere .

As for sharing information about the future of MRA on this board: we're really not concerned about competitors. As someone else on the New Users' corner pointed out, MRA is now a platform that is more than the routeplanner sitting at it's core (although we'll never forget what we are when you'd strip us down entirely). In fact, we decided that this level of openness and transperancy would actually be rather refreshing and over time create a bond with our community and audience that no other company can hope to match.

Perhaps we're wide-eyed idiots for believing that, but as time comes we'll see. For now, I'm just intensely happy with the level of engagement we're already seeing here with the community and the amount of energy everyone is getting from that.