Taking a Product From a Concept to Launch

Problem

I had been hearing from my customers that they loved my company and its products, but they were not happy that we did not provide a way to easily manage those products. They needed to invest significant time and effort to do that themselves, which for many was an investment beyond what they were willing to make. I took this to my VP and made the case to do the market analysis for this problem.

Actions taken

I worked closely with various stakeholders to gather different types of data which would help make the business case. I worked with the marketing and competitive analysis team to see what our competitors were offering in terms of management solutions. I worked with the customers, sales, and biz dev teams to understand the pain points of the customers, what they were doing to workaround these issues, how their deployment environments were structured, etc. I also did an analysis of what the benefits to my company would be to build a product to solve these management issues and what that would imply from a business standpoint.

Having done the analysis, I developed a product requirements document to call out the various requirements. Those were categorized as an MVP for Phase 1 and requirements that could be supported in Phase 2. I also defined the metrics that should be tracked. Those requirements were reviewed with a cross-functional set of stakeholders.

In addition, I did a build-versus-buy analysis to support the speed with which we needed the execution to happen. I presented the recommendations to the executive team. Based on these recommendations, we got the green signal to OEM a third-party vendor software and build integrations around that in the existing product. We also developed the pricing and packaging around the OEMed offering.

Working with an OEM vendor required being very much on top of daily progress and milestones, tracking these, and pivoting quickly with decisions. In the end, we were able to launch the product within the projected time frame, and we got good traction with customers.

Lessons learned

• Do a 360-degree analysis. You need to take into account the market conditions, customer pain points, integration aspects, even the existing roadmap. Not doing a 360-degree analysis can result in an inadequate set of data points that you use as a foundation of your plan.
• In-house building of a product may not always be the correct route, although it may be the easier route. Do a thorough build vs. buy analysis to make the best decision. For example, if the time to market is critical, buying is a better route to follow so that your in-house building can catch up with it. That ties back into a 360-degree analysis since you have to analyze every variable of the equation.
• Make decisions quickly, fail fast. Whether it is about building vs. buying or prioritizing on things, give yourself time to analyze but without getting into analysis paralysis. Make decisions quickly, though not in haste. Once you can see a mistake coming, immediately reiterate and change the course.
• Test thoroughly with end-to-end customer scenarios. Regardless if you are building a product from scratch or OEMed, make sure that whatever you are doing, you are solving customers’ problems in the customers’ deployment scenario, not in your theoretical lab testing scenario.