Observation: unpublished development roadmaps

In My Humble Opinion (IMHO)
#1

I’ve always worked in software in the B2B realm and usually with a close-knit customer base. Think user groups and conferences where we get together with customers to demo new things and discuss issues. So that’s my frame of reference.

When I’ve worked with other software packages, I’ve noticed that when they have user forums people will sometimes ask for new features or report a bug that obviously should be a high priority fix that impacts many people (as evidenced by many “me too” replies in the thread). I’m thinking for example, QuickBooks, Shopify, Facebook and others. Occasionally a representative from the company will post in those threads that they’ve handed the issue over to development. Then you never hear anything else about it. It seems like it would be nice customer service to have a published roadmap of bugfixes and enhancements that are planned for development and approximately when they’ll be delivered.

I think people might biotch less if they could easily see “oh, this is a known problem, they’re working on it and it should be fixed in the 4th quarter”. It’s discouraging to read lots of posts in the user forum that are never resolved. For example, in the Shopify forums (a platform that I really love, FWIW) there are threads spanning 3 or so years of people saying “me too” and “when will this be fixed”.

Has anyone here worked for a company like that and have a good reason why they don’t publish a development roadmap?

#2

Having been on the inside of this kind of discussion, I can hazard a few guesses.
First, most bugs affect only a few people, so the average user sees that the software has a few at most bugs. Publish the list and all of a sudden the user will see dozens of bugs. Most may affect only a few people in rare circumstances, but the impression is of software of holes.
Second, resource limitations might mean that some small and rare bugs will never be fixed. That won’t look good if there is a list of bugs outstanding that users can see.
No ones wants their bug to be a low priority one.

You can run into trouble doing this. The famous Intel FDIV bug had been found, and was on the errata list. All microprocessors have lists of known bugs. It was considered minor because it would show up but rarely. Right up until it showed up in the monologues of late night comics and in David Letterman’s Top Ten List that is.

#3

Well, I wasn’t thinking of publishing a list of outstanding bugs. (I totally agree with you on the impact of that.) More a development roadmap. What enhancements are we working on in Q1, Q2, Q3, next year, etc.

Worst I can think is that people will whinge about something they want being in Q4 instead of Q1. But they’re already whinging a TON about things never being fixed or new features that people have been clamoring for never seeing the light of day.

#4

(crappy edit window)

Let me give you an example: In Shopify (a shopping platform) you can click a button to mark an order as fulfilled. (Meaning payment was accepted and you’ve shipped it to the customer.) I noticed in the forums someone commented in 2013 that there was no way to un-fulfil an order. Clearly that was a design decision to not allow un-fulfilling an order. I’m not sure why they made that decision; you can easily refund the order at any time. You just can’t undo the fulfil action if you clicked that button by mistake.

But since that 2013 complaint, there have been many other people chiming in to say that it seems an obvious and reasonable feature. Here it is 2016 it’s still an outstanding issue and no comment from any support people or dev team.

#5

Our development roadmap shifts and changes. Sometimes things get bumped out a release, sometimes things move off the roadmap completely. We do talk about our roadmap honestly with clients, but publishing it could be seen as a promise by some clients (even with disclaimers to the contrary) and just seems like it could easily cause more trouble than it’s worth.

A personal anecdote: I spent many hours talking with our project owner and going over our roadmap (a large, not-easy-to-consume spreadsheet) and put it together in a nice document that sales could share with potential clients. Almost immediately a) some things on it became wrong/out-of-date and b) there was disagreement about which bugs were important and meaningful to show, and which were wastes of real-estate, and which were probably better not put on an outward-facing document.

But, I will say that JcWoman, your Shopify example is exactly how not to do things. It sounds like not only is there no roadmap, but there’s just no engagement between Shopify dev/support and customers. Not commenting on requests on your own hosted forum is poor form.

#6

If you don’t publish the roadmap then you’re never late. In December 2014 I started working on a patch that was just going to be a collection of low priority bug fixes and minor enhancements. It was originally expected to be released in Q1 2015. Since then a couple major new features have been added and it’s more like a service pack than a simple patch. We might get it out Q1 2016.

#7

In addition to all the good points above …

Any enhancements you put in your public roadmap are simply telling your competition where you’ll be 3 releases from now. Makes it easy for them to beat you there.

It also enables them to learn a lot from how your user base reacts to what you publish. If everybody loves proposed feature #17 & hates #23, well that’s darn good intel to have. You look stupid in front of your user base and they look smarter in front of their user base and your user base by avoiding all your wrong turns.

Big software houses have programs where they involve subsets of real users & significant ecosystem members in vNext planning from initial brainstorming clear through to alpha testing. But it’s all done under NDA.

Only at beta release, where the feature list is fixed and the bug list is 99% down to obscure corner cases, do they admit the public. The NDA signatories are still bound to secrecy about how we got here, and about the bright ideas and features that were evaluated (or even built and runable) only to be rejected before beta.

Some of which will see the light of day in vNext+1. Others are dead and buried; their proponents garroted and the bodies dumped at sea.

#8

More good points.
Also, when you demo software at a tradeshow or at a customer site, there are always suggestions for new features, some of which are great and some of which are outright stupid. The answer always is either “that’s an interesting idea, we’ll look at it,” or “it will be in a later release.” You don’t want people bugging you about this - 90% of the time they’ll forget the request in five minutes.

New features need to be given priorities and fit into the development schedule, no matter how obvious they are. I wouldn’t want people on a message board committing to anything. I used to run a group developing software for internal use, and we responded to our internal customers in a different way from external ones. There were few enough requests, and internal customers were reasonable about what we could do - since they’d have to pay for more people.
When I left that job and became a customer for similar tools, another big company which was selling internal tools on the outside was a bidder. They told me that if we wanted features we could just call up their developers for them. That was a deal killer, and showed me that they didn’t understand about working in an external market, no matter how good their stuff was.