Sometimes it's OK to ship late

If your product doesn't have enough quality or reliability for users, it can kill you right away

Early in my product career, I was the young and very naive product manager for Quicken Online. I inherited the project about six months prior to launch.

It was an amazing team made up of some of the best engineers who worked on the Quicken product. However, for many of us, it was our first time developing a fully web-based product, so the learning curve was very steep.

However, competitors were releasing on what felt like a frequent basis. First it was Wesabe, but we knew great companies like Mint.com were near release as well.

As the PM, I thought it was critical to ship as soon as possible. So we set a deadline as team to ship in the summer of 2007. With about three months before our launch deadline, it was clear we weren't going to be feature complete.

However, I was naive and thought we should just launch with what we had and add the rest later, which were some of the most critical features like visualizations, helping people manage paycheck to paycheck, and critical fixes to aggregation.

The product leader for Quicken, Jim Del Favero, took me aside to level with me. He told me I love your drive for speed, but this product isn’t ready and if we ship it in this state, it’s not going to have the impact we desire.

I thought it was not possible that the team or our leadership would accept this news. We’d established this crazy deadline and we were pushing hard. We had to make it.

Jim, however, made the right call. The engineers needed more time to refine and build the right product. We needed more time to have a complete feature set. We couldn’t tell a good story about our product to users if it wasn’t creating value.

It was a hard lesson early in my career. And it’s not always the right call, but in this case it was. Had we shipped what we had, it would not have had any chance of success. Even though we had to launch after Mint, we were still more successful than most people realize.

We were able to accumulate 1 million users, we launched one of the first iPhone apps at Intuit, and we were doing very innovative things to help people predict how much money they’d actually have at the end of the month.

The learning was that being late is a very hard decision. But if the tradeoff is between being fast but incredibly flawed, especially when it comes to something as important as finances, you need to make sure the data and the product are right.

The takeaway for me is not that MVPs or moving quickly for learnings is wrong at all (I worked at IMVU later after all). Instead, it’s that you need to understand the goal of a launch, the sensitivity of the data, and the dynamics of your product in making that determination.

There’s no one size fits all strategy for speed and execution. You need to evaluate your market, your users, and your product to determine the right timing and the right speed. It doesn’t mean speed is unimportant, it’s critical. But it needs to be balanced as well with quality.