Managing expectations - the smallprint on product roadmap comments

Whilst I agree that some of the comments in the iOS were frankly just impolite, as the opener of that thread, I still think that it has relevance.

I understand that what we’re talking about is basically IT development, and as a person who works in the industry, don’t believe it’s unreasonable to ask for at least rough timescales.
However, and this is a major point, if Danny et al are willing to share, then they need to be realistic targets, preferably with some contingency built it (e.g. better to say you have a target of delivering X on say early Dec, and actually delivery in Nov, rather than the other way around).
By realistic, I mean what is actually going to be delivered and visible to the customer. Clearly, we don’t need to know that software has finished it’s UAT stage, or has been sent to Apple. All we’re genuinely looking for is when we’ll see it.

One of the key points about this is that it would be possible to create a high level wish list of say the Top 10 requests, such that people know what’s being worked on, e.g.

1st Oct. (presently on time):: Release 1.1: to delivery iOS capability, fixes to blah blah
1st Dec (presently on time): Release 1.2: to deliver ability to integrete room correction files from DIRAC

(note, the content above is NOT my expectation of what will be delivered, ,just an example)

For all that, I’m unaware of how the software is being developed. If it’s not possible to give us genuinely realistic dates, only dates that are going to keep shifting, then I believe that they should take the Meridian approach, which is that the software gets delivered, THEN announced, with often no warning.

As much as I’d love to see a definitive roadmap with must-haves and like-to-haves, any such effort typically ends up being divisive message board fodder that poisons a community. The folks at Roon just need to keep doing what they’re good at and hopefully the community will continue providing constructive feedback on what upcoming release information Roon is ready to share.


Just thought I’d re-visit this issue and put forward a balanced argument.

The original question here (and raised on a number of other threads also) is: should Roon publish their development Roadmap so that users (and potential users) can view it and contribute?

A “Roadmap” is a blueprint for what is planned for the software in the future. It would include lists of bugs to be fixed, new features to implement, changes to be made, etc. It would also include some form of priority for these items and potentially a planned timescale.

What has been happening so far, and what is great, is that the Roon team have shown a high level of interaction with users on these forums, and have usually been fairly clear in answering questions in relation to bugs or feature suggestions. Indeed, there are “support” and “feature request” sub-forums for these purposes.

What has not happened so far is the publication of a more formal Roadmap made available to the users (though the Roon team themselves will be using some form of Roadmap to manage the software development).

I imagine that there are various options and online solutions to creating such a public roadmap. As an example, this is what Next Audio Labs have done with their Rekord Buddy software:

They are using Trello, an online service which is a “free, flexible and visual way to organise anything with anyone”. They have a colour-coding system for bugs and features which denotes whether an item is proposed, under consideration, planned, complete and ready to be implemented, or rejected. There are most likely other similar and superior solutions online.

So, should Roon make their Roadmap more explicit in this kind of way? Let’s look at the pro’s and cons (many taken from this and other similar threads):


  1. A central place where users and potential users can view the development plans for Roon, including bugs, planned features and other developments.
  2. No need to scour the forums for a particular issue or request, or to duplicate requests of comments (there is a lot of this duplication on the Roon forums).
  3. Greater transparency and potentially greater user input.
  4. Less ambivalence and repeated questioning about issues on the forums. Promotes patience on the part of the users, as they will be aware when a particular feature request has been accepted for inclusion.
  5. Potentially a rough timescale for feature inclusions or subsequent software updates.
  6. Users (thought not all) (who have paid a relatively large sum for the software) want it.


  1. It may not be possible to stick to any published timecales due to IT or other issues. Note - this appears to be the main potential con that users have mentioned on these threads.
  2. It may not be possible to include a feature or make a change that has theoretically been accepted (and as danny points out, purchasing decisions should therefore not be made based on the Roadmap).
  3. The potential for a more explicit Roadmap to promote argument within the Roon community.
  4. It may require more work to create and maintain such a public Roadmap.
  5. Things have been going pretty well so far!

I have tried to be fairly comprehensive with these lists but feel free to add other comments.

As mentioned above, the main and most consistent con mentioned on these threads is the issue of timescale. There have been concerns that if a Roadmap is published with potential timescales, it would promote impatience regarding features and disappointment when timescales are not met.

Overall - if these cons can be adequately addressed, then given the potential benefits it would seem the right thing to do to publish a more explicit Roadmap. In almost any business, improved communication and improved transparency are valued. I don’t think that Roon is an exception here.

So to address the cons; the Roadmap would have to make clear that in the world of software development, plans and timescales are liable to change due to unforseen factors. The focus of the Roadmap should be on the actual plans (bugs, features, changes, etc) and not on the timescales. Allow the Roon team to work on these features and prioritise based on their capacity and judgement of importance. Like the Rekord Buddy example, a simple coding sytem for features such as: proposed, under consideration, accepted, rejected, under development and completed may suffice, with perhaps a rough indication of timescale only.

I don’t know in what way the Roon team currently manage their project - if they use a particular software that has a similar functionality, or if they work on paper. Ideally they would use software that has the capacity to be viewed online, for maximum tranparency. Otherwise a degree of extra work may be required in making up and maintaining this Roadmap. Anyway, just some thoughts and I think that the Roon team have been doing an excellent job so far.


A very elegant write up if I may make so bold.

The biggest con to all this is (and I have seen it happen in other places) is that no matter how many provisos you give about the roadmap not being set to any timescale and that things can and will get delayed, new users will come along and ignore all of the agreements made and it will turn into a complete bitching festival about things being late.

It got so bad on another forum that people were counting down the minutes and seconds to the end of the month that something was mentioned to be possibly ready. Unfortunately it was the end of the month in their time zone not the developers and they moaned and moaned even though it was actually on time.

Unfortunately this can (and probably will) cause all sorts of back biting and trouble. I personally see the Roonies doing a fantastic job at the moment and producing everything they promise in a timely fashion so have no problem with the current system.

Just to give a contrary view you understand.


This is my concern too… we were big on giving schedules in our first few months post-launch, and while many understood this as an estimate and/or goal, others got angry.

I don’t need a roadmap for the product. Even if I was a lifetime sub I would not expect that. But I would like more updates re the features that were outlined at launch. The main one now being RoonSpeakers (and better TIdal updates). The others, headless Linux and NAS server/core, iPhone app, hq player integration, etc. all appear to me to be added after the launch that described the product we were buying. I look forward to those but don’t consider that as part of the core product. Until Tidal updates are improved and RoonSpeakers is available on a variety of platforms giving us a choice in end points ibthinknwe are waiting on the original product to be complete.

That I would like more of a timeline on.

My concern about publishing a roadmap is that the time spent designing it, implementing it, discussing priorities and updating it detracts from actually implementing the things in it.

I subscribe to Roon in order to listen to music, not to be kept up to date on the minutiae of product development.


Well, you don’t have to concern yourself with the Roadmap then andybob! Valid point regarding the time spent on the Roadmap, but like I said, the team probably do something like this already, they just don’t publicise it, so hopefully it wouldn’t be much extra work.

Regarding people counting the minutes - that’s the kind of behaviour that happens with Apple products. And look how the fanbase has helped propel Apple to the top! And if people get unreasonably angry - you can’t please all the people all the time!

And fritzg - you want updates regarding RoonSpeakers, others want updates about other features. Supports my argument.

Perhaps that’s the case, but I doubt it.

Bug trackers and such for internal consumption tend to be targeted to that audience, which is very different than the general user base.

I’m guessing, in short, that there’s a zero sum issue here: delivering what you want will take a lot of work/time, which takes away from development.

1 Like

Just to clear the point - it wasn’t Apple I was referring too, it was a piece of AV equipment.

I still stand by my original comment. I don’t think they should tell us anything. Too many people whine and complain when something is ON the “roadmap”, but the devs can’t give an accurate timeline. People also get upset if a timeline is given and it’s not reached. I understand maybe sharing BIG features when it’s well into development or beta testing but sharing other plans just causes turmoil.

1 Like

Just wanted to thank @mike for the release notes . That the right spirit!!


Agreed, Thank you @mike for the release notes for build 94. Roon is closer to becoming the product announced at launch as Roonspeakers is on the horizon.

After that occurs, I would slow down on the “roadmap” announcements. We don’t need that.

1 Like


I personally LOVE roadmaps. But you guys set the highest standard I’ve ever seen for communicating with your user community. So we ARE informed. You tell us what’s up. Or a LOT of it anyway. :wink:

I’m afraid that publishing a roadmap would be handing people rope that some of them will try to hang you with. Plus, it tells your competition exactly what you are up to. So honestly, as long as you’re going to keep communicating with us, I see no advantage to a formal, published roadmap. Only problems.

We were already hung talking about RoonSpeakers and continue to be. We should have never given that original date or even mentioned it. It causes us grief every day. :frowning:

If it’s any consolation @danny, it was just the notion that you were working on such things that got me even more excited about Roon as an application, and was one of the features that solidified my Roon purchase decision - even though the feature didn’t yet exist.

So I guess it’s a fine line, but personally I think having a hint of things to come is a good thing. People are always impatient, myself included, but you guys do cool stuff so sharing snippets where you can is great. :smile:

I wouldn’t worry about RoonXXXXXXX (speakers), from the reactions to the RoonReady devices ‘just working’ it sounds like you made sure you got the tech right rather than rush, which for something critical like that was undoubtedly the best move.


I agree. Considering the number of endpoints that just work, and how many options and system combinations that provides customers, I’m consistently surprised how many users are still focused on this issue. To each their own, but it doesn’t add up for me.

I’m not quite sure, but I think my old post might have been mis-quoted here?

I was merely adding kind words at a time when Roon Bridge and RAAT (then called RoonSpeakers) had been delayed - I was just grateful to know it was coming.

I might have missed it, but I’m not quite sure what doesn’t add up?

Sorry to confuse the issue. I meant that as Roon development and the ecosystem of available Roon endpoints currently stands, there are lots of available deployment options. So I’m surprised at the number of users who frequently push for certain updates or changes to the state of Roon Bridge and RAAT, because of how many options there are currently to hold users over until their perfect preferred option is available.

I hope that clarifies my quote.

1 Like

It is quite stunning how well Roon works with very different hardware, setups and environments.

1 Like