Managing expectations - the smallprint on product roadmap comments

One of things I really love about Roon is the way that @danny and all the other Roon guys are engaging on this forum:

  • quick answers on support questions
  • very actively participating in discussions on new feature requests
  • asking for specific input on their design
  • sharing insights on how to best use the product
  • etc.

But most of all I love the sharing of their intentions with the product! Honest insight in what they find important, what is on the prio list and what is not, and an indication of where it is in the chute.
An openness that is pretty unique, as most companies won’t even acknowledge something is on the roadmap, let alone where. Why? Because there is a flipside to transparancy. Roadmaps are not set in stone. In this agile world priorities shift and in IT unexpected roadblocks sometimes have that pesky tendency to pop up.

I would hate to see Roon go in the same direction as other vendors due to come comments I see coming by.

@danny, could I invite you to ‘formally’ manage our expectations? This will give us the frame of reference to avoid future discussions. We can then easily refer to it and close off debates that might impede this great interaction we’ve got going here.


A formal roadmap is much more dangerous, as people start to make purchasing decisions on not only Roon but additional hardware.

What would you like me to do?

Cannot possibly agree more with every word written above.

Having said that, I would not personally see the need to request a more explicit roadmap.

Just keep doing what you’re doing Roon…

1 Like

:smile: Actually, I wasn’t asking for a formal roadmap, actually quite the opposite.

Let me see if I can word my expectations as a kickstart.

I hope they stop sharing future plans, otherwise it’s just going to turn into a shitfest of whiners like the iOS thread.


I think they’re doing fine.

I tend to agree with pretty much everything that has been said in this thread already, but I’ve had a couple of reds so…

…The whingers in the iOS thread should in the main be ignored. Danny et al from Roon, you have displayed an energy, transparency and completely fresh outlook on how to run a business that is absolutely intoxicating. I’ve signed up for life on the strength of this and I suspect there are plenty more like me who can see that what you have is special, both as a product and a company.

Just carry on doing what you’re doing and don’t be swayed. I suspect you won’t anyway, as that’s what makes you different. One or two people complaining about a few weeks delay on a bloody iFad release is neither here nor there. I’ve worked with major video software companies who’ve been 2 years late with products, and it still wasn’t worth it when it arrived. I’ll eat my arse if that is the case when you release.

I’ve got a fruit based product myself that would be handy for some family members, but it’s hardly life threatening having to wait, and has been known since Day 1

There will always be the moaners, no matter what you do.
Those of us who you deserve as customers will wait for what we deserve.


Rovinggecko - this has already been explored a little in this thread:

Personally I think it would be good from a consumer perspective to have a list of features that the team have agreed to include (at least, as best they can), so that the consumers don’t have to keep asking repeat questions or for features that have already been agreed to be included.

Having said that, I also respect the way that the development is going and if the team felt that the above would be unhelpful, no problem!

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!!