Lessons learned from developing library self-service software: The launch date shouldn’t be the real launch date
Although we’d like to develop products and services iteratively, the truth is organisations think in terms of strict deadlines, mainly because projects have finite budgets that have to be spent within set financial periods. We product owners need to think about how this affects our ability to make changes based on user feedback.
Browsers update regularly, making frequent, (mostly) small changes. This causes little disruption for users. It’s rare you’ll download a big update and find everything is completely different. This is is how we’d like to develop software over several years, such as our self-service system.
But let’s say you, unlike Google, have a finite budget to be spent by a specific date; consequently, you’ll have a set-in-stone launch date – like the ship in the above picture. The expectation is that the product will be ready, and won’t sink if it bumps into any icebergs.
If your best feedback will come from real usage, you might plan a beta phase, as we did when developing self-service software. This is useful, but there’s a big difference between a controlled roll out to four small libraries that are showing an interest in the new system, and installing kiosks in 44 libraries, including Ipswich, Lowestoft and Bury St Edmunds. Generally, staff aren’t particularly interested in the product itself. They just want it to not cause them hassle.
We unearthed user experience problems after I’d installed kiosks in the four beta libraries, problems I would have liked to have fixed more quickly. But we ran up against the big launch date curse of no more project money.
The lesson learned is therefore quite simple:
If you have an official launch date, reserve some money for further changes after this date. Say, at least 10% of the overall budget.
Note: It’s important this money is kept aside for the project. There’s little value in coming in under budget (besides some temporary good PR that’ll come back to bite you later in your career) if your product isn’t perfect – and it’ll never be perfect.
This also means gathering as much live feedback as quickly as you can, and preparing your developers to make changes fast. Wait too long, and the money’s gone.