Launching a New Product

Problem

At a previous company, I inherited a proof of concept used by a consulting team in order to provide a solution to customers. It worked well for the consulting team (who were employees of the company working with customers), but it wasn’t a full product -- it didn’t have the availability, features, or quality that customers would expect. I had a target timeframe of six months to turn it from a proof of concept used by the consultants to a full product. Also, I had to form a team moving some of the consultants to the development team, hire some new developers, and ask developers to move to the team from other parts of the company. I also worked with the product managers on the differences between what was needed by consultants and what was needed by customers.

Actions taken

One of the biggest challenges was that at a high level the needs of the consultants and the needs of customers looked very similar, but when you went down to the detail in some cases -- they were completely different! We had to agree on a common terminology in order to discover those differences and drill down on them. Then we had to have negotiations between the different needs of the people representing consultants and people representing customers to ensure that we were meeting both sets of their needs, even when they were mutually exclusive. For example, unlike customers, the consultants were fine with beta product-level quality, therefore we had to develop a monthly customer release in cadence with verified quality and availability. At the same time, the consultants could get a daily build that was not as reliable but had the features they needed.

At the end of the project, we had to be particularly careful about scope increases. As we were approaching the end of the full launch, there were things from the original scope that we couldn’t complete by the deadline. We had to balance the timeline, quality, and features and we weren’t willing to sacrifice the timeline nor quality. Instead of removing some features completely, we cut the scope of a portion of features to be able to launch it on time. We were able to launch it doing a high profile announcement and later saw a big uptick of customers embracing the newly launched product.

Lessons learned

• Identify where people disagree even if they don't realize they're disagreeing via a common vocabulary that they can agree upon.
• When changes are proposed, make sure the stakeholders understand all the repercussions of those changes (time, quality, scope).
• If scope needs to be cut to make the date, instead of cutting entire features, look at cutting portions of those features so that customers can get a feel for them and you can still make your deadline without cutting those features completely. That requires being very intuitive and very selective in what you do that with.