Lessons learnt planning a big product release

We recently released version 1.6 of Sensei (our learning management plugin), which proved to be the biggest, most feature-rich release since the plugin was launched almost 18 months ago.

While, overall, I consider the release to be successful, I also learnt a lot during this release cycle and there are certain things I would have done differently in hindsight.

I’d like to share some of those insights with you here.

1. Less new features per release

Sensei 1.6 introduced around 10 new features.

On the surface, this seems like a big win for Sensei users, as each feature adds value to the plugin.

The payoff is in the time spent waiting for these features to be implemented.

Looking back, we could have released version 1.6 a month earlier, with half of the features, and then added the rest of the features to a 1.7 release.

The end result would have been the same, but half of the value would have been delivered much earlier.

In future, these feature releases will be limited to 3 or 4 new features, providing the same amount of value in smaller, more regular packages.

2. Hofstadter’s law

Hofstadter’s law states:

Things will always take longer than you expect, even when you take into account Hofstadter’s Law.

During the development cycle, I had been telling people that a certain feature was coming in version 1.6, and giving an estimate of when we planned to release it.

Inevitably, despite our best efforts, the target release date came and went, and I had to apologise for the delay and give revised estimates.

It’s always difficult to estimate the time requirements for development work, at least until you’ve spent some time working on it, to get an idea of the level of complexity.

Keeping the releases smaller, as mentioned in point 1, should help make these estimates easier, so we can endeavour to stick more closely to our target release dates.

3. You can’t do everything at once

Sensei is a popular product, and our ideas board is brimming with great feature requests.

It’s always tempting to try and squeeze as many of these ideas as possible into each release, so we can deliver instant happiness to everyone who uses (or wants to use) Sensei.

The reality, however, is that we can’t please everyone, and we can’t implement every feature at once. We have to prioritise, and as a result, some features have to wait, and others have to be rejected.

For example, we initially wanted to include support for the TinCan API in Sensei 1.6. As we progressed, we found that the implementation would be quite complex, and to avoid delaying the release further, we decided not to include it. Instead we plan to develop the functionality as an extension in the coming months.

Moving forward

I look forward to taking these insights and applying them to future Sensei releases, so we can bring you even more great features in a more timely manner.