Lessons learned from building for startups

Although we’d like to develop products and services iteratively, the truth is organisations think in terms of strict deadlines – and budgets. We product owners need to think about how we manage this.

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, especially with embedded systems.

But let’s say you have a finite budget and, consequently, 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 library self-service software. This is useful,but there’s a big difference between a controlled roll out to 4 small libraries, and installing kiosks in over 20 libraries within various institutions in a region, where staff are less invested in the new product and require understanding to be able to utilize the benefits of the product.

We unearthed user problems during the launch 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, make sure there is some project budget remaining for further changes after this date.

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.