Release your software to real users as early as possible.
Building software for years without ever releasing any of it is like working in a kitchen and letting the food go cold and mouldy before serving it up.
Building software is a collaborative process – not just amongst you and your colleagues – or between you and your partners – but between you and your users. Feedback from real users helps you guide the future of your product and your immediate investments. It helps you prioritise and optimise. Making product decisions without real user feedback is quite often, I think, guesswork. Yes, it’s (hopefully) educated guesswork – but it’s guesswork all the same.
You can learn a lot from user testing and user research prior to release – and there’s no way you would want to skip these steps – but nothing can replace the feedback you get when real people use your product, with real use cases, under real load.
If you see that you’ve been sitting on the latest version of your product for months without any of it hitting a user, or if you find yourself wanting to squeeze “just one more feature” in before you drop the release, then stop and think: can I give my users meaningful, measurable value with this release? If so, then release it. Now!
Hi Will. These are great points about releasing to users early. There is another I was thinking about as I read “Building software for years without ever releasing any of it…”
I frequently encounter friends and colleagues who have spent significant time of their lives writing great software that never got deployed. I know of one team that built a $4M platform for an automotive company that was used as leverage to negotiate with dealers… the investment was expensed for contract negotiations!
There are times when software projects should be canned, if not mothballed. There are times when waterfall delivery just can’t keep pace with a rapidly changing market and the project is obsolete before it could even be deployed. But for an agile effort, you have to ship (in addition to the reasons you have cited) to get any sense of accomplishment as a professional.
Then everybody wins.
–k
Hi Ken,
totally agree. I too have seen teams and engineers who work for months or years on software that gets canned before it ever gets released. I spoke to an engineer the other day who told me that in the last 2.5 years of his professional life not a single line of code he has written ever made it to a real user, and not surprisingly, his motivation levels were through the floor…
I think teams need that feeling of “we delivered” to stay motivated too.