Release it: now

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!

Advertisements

About Will

I'm Will. I'm a product creator, Scrum and Agile advocate, web enthusiast and change instigator. I work for Nokia and I am the Product Owner of Nokia's web social location platform, maps.nokia.com
This entry was posted in Agile, Continuous delivery, Product Management, Software management and tagged , . Bookmark the permalink.

3 Responses to Release it: now

  1. ken says:

    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

    • Will says:

      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.

  2. Pingback: Driving innovation with agile: a short case study | Will's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s