The case for published roadmaps?

The Lounge
1

I come from the software world, where public roadmaps for upcoming features are common. These are much less common in hardware - even though the hardware runs on - yeap - software. That software is updated via firmware releases, but the firmware is rarely the subject of a published roadmap.

I often wonder why this is.

It could be cultural. The software world long ago embraced so-called “agile” development, which supports (and often results in) shorter release intervals, e.g. a new sub-version every month or whatever. At my company, we tell clients and would-be clients (via marketing) about upcoming features. Hardware vendors seem much less willing to go this route, perhaps championing stability over quickfire releases.

But this falls down when you consider that music tech devices are, these days, often released in what many consider an unready state. For better or worse, this is a thing; the internet basically makes this acceptable by providing the means to patch firmware later. Manufacturers are thus incentivised to release now, patch/expand later.

This sucks. But it would suck less if companies published a feature roadmap. This would have two main advantages:

  • Reassure early adopters that your pet bug is on their radar, and roughly when it’s going to be addressed
  • Convert unconvinced would-be purchasers who ultimately go on to buy a competing product because your product lacks what they need and they have no way of knowing that it won’t lack it forever (e.g. DT1 and time stretch)

I’m not saying road maps should (or even could) be exhaustive. Not all bugs are known about and may arise later in obscure circumstances, and not all planned features are known from the start; they may depend on community voting e.g. the Polyend model.

But surely the general direction of a device - like, years down the line - is known. Elektron know whether the TV will get a granular machine, and time stretch, and independent effects sends for sub-tracks. (At least, I assume they know). So why not declare this?

Commercial confidentiality is one explanation. But to what end? I’m not sure Roland or Akai benefit in any way from knowing that Elektron plans to add a fifth synth engine to its Digitone 2 next January.

Anyway, it’s also possible I’m missing some very good reasons this wouldn’t work. But I’m interested in your thoughts - particularly if anyone has worked for hardware (whether musical or otherwise) manufactuers for whom this would have been a great/terrible idea.

13 Likes
2

Take the names of the ‘wares:

  • hardware: making changes is basically impossible after release (Ok, I got a hardware patch for a Big Six design fault from SSL. We were lucky the correction was pluggable into a ribbon connector)
  • Firmware: easier to change after release than hardeare, but typically not as easy as software. in today’s internet connected world, updating firmware post-release is easier than it was. Developing firmware is probably still just as hard as it ever was - the debugging tools are more esoteric - they have to fit in where there might not be firmware yet (sorry, that was badly worded)
  • Software: easiest to change, both in development and post release

When you design digital hardware, you design the firmware and software to complement the hardware. There’s a subtle but important difference from designing software to run on general purpose computers. Software for hardware is (hopefully), tightly integrated with the hardware, and thus eith “the product”. The product likely has a clearer, more focused “personality”. Because the hardware can’t change. The notion of product vision is more rigid when working with hardware, because the hardware can’t change post release. A good product will be well integrated between the hard and soft parts, to the point where users shouldn’t see the boundary. Personally, I think this leads to slower development cycles, more focused planning and feature selection, stronger decisions being made.

Minor nitpick: software runs on hardware, not the other way ‘round.

Disclaimer: ok… so Elektrons kinda look similar to one another: I heard the DT and DN share a lot of the same chips and circuits. So I can see why people keep asking/hoping for cross pollenation of features. But I think Elektron hold firmly to the “focused product”. Some people call this feature segmentstion; I usually think of it as “instrument design”.

Disclaimer 2: I think I wentnoff track a bit. I’m tired.

6 Likes
3

Agreed, but I think mitya33 is using “runs on” here in a more idiomatic sense—as in, without the software, the hardware is just a box with a lot of knobs that do nothing. The same way a car runs on a road, but also runs on gas (terrible metaphor holy crap!).

Re. the original post—I like the idea of a “future feature set,” but I’m also not so sure that all or even all that many of these features were known at launch.

It seems like much more of a feedback loop between developers and musicians now, where social media and word of mouth leads to quality of life improvements and new feature ideas, at least when the system works well. As opposed to the old linear system where a team has a concept and builds it out till it’s done.

So I think the rolling model we have now has its pros and cons, but allows for a lot more improvement and even pleasant surprises.

The DT1 timestretch seems like one of these to me—I don’t pretend to know what Elektron was thinking, but it always seemed to me like they saw people doing the LFO star-point timestretch trick and then realized “hey, we can just implement that as a feature.” It doesn’t seem like something that would’ve made it into the product if we were still in the old model where you just get 1 release and that’s the instrument.

Keeping with Elektron examples . . . . I wonder if being too open with your roadmap opens you up to an Overbridge dilemma. That is, you promise a future feature, it ends up taking longer than you expected, and next thing you know people are dragging you to filth for it all over the wide internet. So a roadmap can expose you to some ridicule, and I think most companies want to avoid that kind of risk.

5 Likes
4

What if the product is a flop and they don’t want to keep developing it for a decade but they’ve already promised all of these upcoming features?

What if you announce features A, B, & C are coming in the next firmware update in 6 months, and then the person working on C leaves and it takes a while to find a qualified replacement and there’s no way to get feature C finished in time for your target date? These are small companies.

Any number of things can go wrong and cause delays and then people on the internet will complain endlessly and badmouth your company. (Oh I just noticed KingDuppy said the same thing better in his last paragraph).

What if the development team has a bunch of different creative ideas that haven’t been done before but there’s not yet any consensus on which to do first or how long they’ll take or what’s the best way to implement them.

Seems like a minefield. I think the most common place you see roadmaps like that is with kickstarter projects and you can see how poorly that often turns out.

8 Likes
5

This should absolutely be a thing (because I too, am not really a fan of hardware having to depend on firmware updates to improve or be usable, games industry with game releases anyone?), but people will complain if and when they don’t stick to it, and shareholders and executives are very unpredictable.

1 Like
6

wild guess-- it sounds like a b2b saas company?

designing and building instruments is super different. Ableton has talked about this pretty extensively with regards to the Move (which they do not share a feature roadmap for), and I haven’t heard anything they’ve said in defense of that decision that I disagree with.

None of us are clients of Elektron or Roland or Akai or Ableton; we’re customers (at least if we’re spending money to acquire their wares) or users. I think that’s a rather important distinction to draw.

I personally don’t think any company in this space owes their customers any sort of road map whatsoever, and I think users who expect one or complain about the lack of one are rather entitled and don’t understand how this musical instrument / embedded system design world works.

I can see the benefit in acknowledging a bug or making general statements about where a product might be going. If a product is released earlier than the designer would prefer, I can see good reason for the manufacturer to say “hey, we intend to include this functionality but we couldn’t at this point in time, and want to sell it to you anyway.” I wouldn’t go much further than that. Those kinds of statements are a lot to live up to and indicate the manufacturer is trying to sell something beyond the product that they actually have to demonstrate.

I actually don’t think this is a minor nitpick to correct. “Hardware runs on software” feels to me like a philosophical inversion of the way the technological world actually works, but I’m just gonna leave that there.

5 Likes
7

Musicians are a part of the cohort that thinks it knows what it wants but really has very little idea. I’ve seen it countless times. Small builders taking suggestions during beta and muddying their original vision only to be left with a ton of overstock. A big part of the reason Roland is Roland and AKAI is AKAI is because they are better at knowing what we want than we are (okay, not everyone).

Also, and probably more to the point, hardware is where the rubber meets the road. Any product manager at one of these companies is going to prioritize shipping working hardware over shipping hardware that is harmonious with the eventual software ideal.

After all, ‘we can always do a firmware update’. Or better yet — tell our customers that we’re planning on doing a firmware update. And then never do it!

That’s just good business :wink:

2 Likes
8

I’m kind of against published roadmaps. In development, sometimes you find that your ideas are not viable, or they come at the cost of quality/reliability of features that have already been implemented. I don’t think it’s smart to promise things that haven’t been fully proven to work well yet.

I decide to use an instrument for what it is, and not for something I think it might become in a future release.

4 Likes
9

software development and hardware/firmware development are different, so what works well for one would not necessarily work for other.

also, «modern hardware is just the same as VST running on a computer» argument is valid only for small part of hardware that runs a generic OS inside – like MPCs, Machine+ and Push, where some selection of all that desktop goodness is just rebuilt for Linux.

however, vast majority of firmwares are based on special realtime OSes that are much more spartan by their design, manage resource allocation in totally different manner, and have very little in common with generic OSes suitable for running on consumer desktop/laptop computers – so no, code running on those OSes is not «the same VST».

4 Likes
10

I think the biggest problem with this is something others have mentioned upthread: it’s really hard to know in advance just how difficult a feature will be to implement.

In my own job, I’ve seen this – there was an unofficial leak of a work-in-progress feature which kind of worked. It hadn’t been promised by the company, but it led to a lot of expectation. As it turned out, despite a lot of effort, it just wasn’t possible to get it to a truly shippable state with the processor we used.
This situation caused a certain amount of heartburn and customer unhappiness. It would have been much worse if we’d actually promised to deliver it – either going back on our word, in which case customers would have felt entitled to ask for refunds, or else delivering something just not good enough.

5 Likes
11

As a developer I can tell you why I do not publish a roadmap… Any features I want to add need to be thoroughly tested for performance during implementation - to the point of potentially reworking other processes in order to afford it. I do not know this in advance, so I just have my own private wishlist to not crush peoples hope.

10 Likes
12

If you want a roadmap and a formal commitment from hardware manufacturers like Elektron, i guess you would have to accept some form of subscription model ?

1 Like
14

Wouldn’t surprise me at all if that was Elektrons reason for no roadmaps.

5 Likes
16

I guess another benefit they likely see in the way things are currently done is that the product gets a fresh new wave of online hype and algorithm boosts from every surprise new feature ‘drop’.

3 Likes
17

To protect the IP you have a online license activation. MPC is small linux and has exactly that. They obviously listened to user feedback, and to get the clip launch for your old device, you have to invest 100 €. i think that is very fair approach, better than just saying the old units are for the bin now. Their vst can also run in a DAW, i think you can even transfer presets between them.

They dont have a feature road map, but quiete a broad beta program, and some stuff gets leaked so obviously that many know what is comming up.

I personally wish they would implement something like the Abelton feature request system, with votes from the user. That does not mean every wish gets granted for sure, but it consolidates the information.

I also wish that Abelton has 7/8 grid, like Bitwig has it, but that does not mean i would switch because of such a thing. (Note Transform works also, as workaround)

I wouldnt mind payed (significant enhancements) but not bug fixing. If they made a call to bring a wavetable engine to Syntakt and Polyphony, and it costs like 6 Month of Dev work and they need to raise 100k for it, that could be a kickstarter like fund me campaign.

We can vote with our wallets.

2 Likes
18

Loopy Pro has a fairly open roadmap, which I think is cool: https://roadmap.loopypro.com/

But that’s a solo software project running on generic hardware. And even at that, I saw a few people getting upset because Loopy Pro v2 was announced as “coming soon,” but it took longer than they thought it should.

As others have said, development teams are expensive and feature ideas don’t always pan out. And even though you never should buy something based on future expectations, people still do it.

There’s also the issue of WHEN updates come out. If Ableton announced they were working on the X-Y controller layout when they released Push 3, but it took them two-and-a-half years to get it into beta, I’d have been a little disappointed with every update it wasn’t a part of.

1 Like
19

I buy stuff based on what it does, not on what it might do. It saves me the disappointment when the company folds, changes direction, or abandons the thing I bought.

I think the cons outweigh the pros on this. So many folks get disappointed when their promised feature isn’t developed.

5 Likes
20

I think these roadmaps are too much commitment - if they publish them they need to reach them. Otherwise people get mad, no matter the reasons why.

If a device doesn’t sell very well it is almost certainly the case that development for it will be back burnered and whatever milestones were on the roadmap will be missed. People will complain, so it’s almost all downside really.

I think a lot of software (particularly, entertainment software) should avoid over committing, too, for similar reasons.

5 Likes
21

Thanks for all the interesting replies - some excellent points.

Software running on hardware vs. hardware running on software - two sides of the same coin. In this case I meant the hardware does nothing without the software, and so the software is open-ended in potential, within the constraints of the hardware architecture.

Some have mentioned a subscription or Kickstarter model. I’ve been involved in both of these in other areas and both can work really well. Board games, in particular, often gage interest in, and then fund, expansions, via Kickstarter or similar platforms.

I think the opinions against a roadmap make sense BUT for the fact that we’re being given unready devices. I distinguish between unready and unfinished; with the model of firmware updates over the internet, a device is never finished so long as more updates are planned. But unready = egregious bugs that are (presumably) known about at the time of launch, or missing features that most would agree should be there from the start. I’m reminded of the 1010 Bento, which many accused of precisely this.

If this is how a manufacturer is going to release products then I see a roadmap (perhaps just a short-term or partial one) as being the carrot to the stick. “Yes our device needs a lot more work, but here’s what we’re doing and roughly when you can expect it. Stay posted…”

As for the maxim “always buy tech for what it does, not what it might one day do”, I don’t know, it’s inarguably correct, yet I wonder how realistic it is, precisely because of the current models of patching tech once it’s launched. I think it depends on the company, too. Roland? I expect no updates. (Case in point: SH4D). I’ll buy it or not buy it based on its current status. Tonverk? Elektron have a rich history of incrementally adding to featuresets, and so I might buy it because of that, whereas if you told me they were never going to add to it (barring bug fixes) I probably wouldn’t.

2 Likes
22

I love this model. I would totally be for this.

Yeap, I suspect this is the chief reason against a road map if you asked Elektron and the others. Other reasons, sure, but for me this seems like the biggest loss to them: hype, eyeballs, clicks. Look at the raft of media that appeared when the DT1 got new machines.

3 Likes