Hi @dspreadbury and @Ulf ,
I keep on seeing comments and posts about feature requests and/or comments on current Dorico features.
I was wondering if you’d mind explaining - in whatever depth you like - the process and timeline of how features are decided upon, created, and implemented into Dorico? And whatever else you think might be relevant?
I’ve tagged you two as you’re the only people I’ve really had interaction with on the forum!
It’s very hard to describe the process in simple terms, and I don’t really have the bandwidth to write you thousands of words about it at the moment, I’m afraid! So this will be very brief and over-simplified.
We don’t follow a particularly formal process. We have a backlog of tasks and bugs that need to be done. We have a long list of ideas, both of our own and gathered from users. We also have a long list of non-feature-related tasks to do with maintaining the technology (e.g. porting to new platforms, supporting new operating systems, addressing technical debt, implementing a new licensing system, and so on).
We agree a release window in consultation with the rest of the company, and then as a team build a backlog of the things we would like to achieve in that release. We can’t be sure at the beginning of the development period which features will actually make it into the software, because it’s impossible to estimate how long it will take to implement anything but the most trivial change, so we review progress regularly, both in smaller meetings between me and the developers and testers involved in a particular bit of work, and in larger meetings measuring overall progress as a team.
As we go along, we reprioritise the remaining work, and things that were initially planned naturally get descoped (which means that they will not be implemented in this development period, and they go back on the backlog to be considered again in the future), and as we approach the release window, we try to make fewer big changes and instead focus on refining the things that have been built, taking into account feedback from our beta testers.
For smaller releases following a big release – which we often call maintenance releases, since their primary focus is to fix bugs, but which often contain functional improvements as well – we follow a similar, but smaller process, where we don’t typically take on such a big backlog, and indeed the scope of the backlog is determined more by the feedback we are getting from customers than by specifically the things we want to work on.
Sooner or later we then determine that we have made the critical improvements that need to be made for that major cycle, and we gather as a team to start working towards the next one. All the while, as product manager I am thinking about the longer-term product strategy and discussing and sharing it with other people within the company, so that by the time we come to the start of the next cycle, we already have a good idea of what direction we are headed in. Even though Dorico 4 is not yet complete, for example, we already have a very solid idea of the larger things we will be working on in 2022, and indeed beyond.
That will have to do – it’s already more than I was planning to write. If you have other specific questions, feel free to ask, but the more specific the better so that I’m not left with a huge open-ended question to answer.
A stellar example of the responsiveness and communication skills of Daniel and the entire Dorico-team!
Thank you!
Beautiful explanation! Thank you, Daniel!
Thank you, Daniel, excellent clarification 