Seilevel
Back to Blog Home - Requirements Defined
Seilevel Home
When to Release a Product

One of the projects I’ve been working on over the past year has been particularity challenging; it’s one of those everything that can go wrong does go wrong projects. This is a back office product which automates a process updating data records. The updates are transactional. We were almost done and ready to release when we ran into a strange issue; occasionally a transaction failed for no discernible reason. I was concerned that it could take us weeks or months to figure out this issue–with competing priorities of other projects and a history of things going wrong. Additionally, creating test data was very labor-intensive and the test environment brought its own issues causing multiple retests. Meanwhile, our business partners would still be manually updating data…

I’m risk averse. I pair very well with risk takers—we even each other out. So, I was surprised to hear myself proposing a move to production with an error loading data. But, when I thought things through and checked with the team, everyone was able to agree with these 3 statements:

  1. When the data loads, it loads correctly.
  2. When a transaction fails, it does not impact the system or corrupt data. It simply fails to load.
  3. We already have a process in place to detect data which has not been updated.

Therefore, I saw no reason to hold the release. We could get the vast majority of the benefit. Our resources would be better spent monitoring the production system for issues than creating test data and fighting the test environment.

So, I went to the business owner and made my proposal, with full disclosure of all of the information above. She easily decided to go live. We did. Today we got an email from her team that said “Thank you! Thank you! Thank you!”  We’ve had a real positive impact on our business partners.

That’s one of the tricks of product management—knowing when to release your product. Always take that step back and ask about the value to the users and possible costs. In this instance, we had high value and no known cost.

Yes, we’ve seen a few transaction failures since deploying. But, now we’re analyzing and collecting data which should allow us to knock those last few defects out.