Ideation and Innovation In The Product Design and Development Life Cycle

For the the past 8 years or so, I have been designing, developing and delivering cloud based enterprise software in a quarterly cadence for use by employees and customers of organizations. This model is normally referred to as business to business to consumer (B2B2C) model. I have done this in the human capital management, health benefits and recently in the financial technology industries. In all these organizations, I followed a quarterly development cycle where senior executives and product leaders set the business goals for a year and product managers defined features that need to be developed to meet those goals with quarterly planning and delivery cycles. 

When developing functionality rapidly quarter after quarter, I noticed that sometimes product teams become delivery oriented and lose their ability to innovate. They stop meeting users and customers in a planned and systematic way. Market research and innovations becomes the responsibility of a few individuals. No matter how smart those individuals are, they eventually run out of energy, ideas, and lose touch with the capabilities of the organization. When this happens, product managers who deliver a product, start looking up to senior executives to point them to the next big thing. If they do not hear a clear direction from senior executives, they become demotivated and may leave the organization or become less engaged with the with the mission of the company. Slowly but steadily, talented people leave and the organization fails.

There is another extreme scenario that happens in some startup organizations where there is no successful product yet. In such organizations, every work session and every meeting becomes a new product brain storming session with no frameworks or business processes to listen to the voice of the market, identify the pain of a customer, test the feasibility of a solution, confirm a hypothesis, clarify the details of a solution, pilot it for a customer and build a product in a phased manner. In this scenario, the organization makes poor investment decisions, product decisions and commercialization decisions. The organization either fails or takes a very long time to become successful.

These are not  good results for any organization.

I believe it is necessary for the sustainability of an enterprise software business to incorporate the process of ideation and innovation in the product design and development process. It is also important to tap the creativity and talent of many people in the organization rather than rely on the vision of one or two people in the company. I developed the following framework a few years back to do this. It has worked well for me and has helped me created products that bring multiple millions in annual recurring revenue. Please note that this framework has been tested only in business to business to consumer software models. This is designed to work in an existing medium sized software organization with 100 to 500 employees. Smaller organizations may take a different more nimbler approach. 

1. Proof of concept : This is the stage where executives have a hypothesis about a market need and a product manager or engineer has an idea to build a solution. At this stage, one senior product manager working with a senior engineering architect builds a proof of concept to test the feasibility of the solution. They may show the solution to end consumers and get their inputs at this stage. No formal customer co-innovation or user testing is done. At the end of this session they produce a functioning proof of concept that proves that their idea works. I normally prefer to make this a project to be completed within a quarter. This proof of concept is formally tracked as a quarterly objective. It should take about 25 percent of an experienced and motivated product manager's time and about 25 percent of an engineering architect's time.. That translates to about 200 hours of work in a quarter.

2. Co-Innovation: Once a solution is proven to be feasible with the capabilities available in the organization, it is time to go meet 2-3 customers for 2 hours work sessions. Product managers will have to create detailed concept stories with low fidelity mock-ups to tell the story to customers. usually 2-3 concept stories explaining 2-3 user cases will work. Once they complete the co-innovation sessions with 2-3 customers or prospects, they should be able to define a possible solution and prototype it using medium fidelity mocks. It is important that they prototype almost 90 percent of the functionality to ensure that prototype conveys the user experience and value created for a customer. Co-Innovation sessions require senior product leaders who understand the design thinking process, a user experience designer and a sales executive. The sales executive's role is to guide the team to work with appropriate prospects and customers who are most likely to co-innovate and most likely to buy the proposed solution. The co-innovation session should be led by the product team and not the sales team. If done well, this should lead to a paid pilot project with a customer.

3. Pilot: This is the stage where one customers is willing to pay to test the solution. At this time, it is important to commit to the delivery of the solution as long as the customer signs a contract or statement of work. The project will be considered a pilot only if there is a paying customer. If no customer is willing to pay, then the co-innovation process continues until the product meet the needs of a customer. Even when one customer is using the solution, it is still not appropriate to call it a product, until the solution has been implemented for at least two customers.

4. Minimum Viable Product: I consider any functionality or solution to be a product, even a minimum viable one, only when it meets the needs of at least two paying customers. Once the solution has been implemented for two customers, the sales team can start selling the product to several customers. This stage will require multiple senior product managers  and multiple engineering teams working full time to build features that meet the needs of the market and strategic customers. It is important to note that a product considered minimum viable for one customer may not be so for another customer. this will be the case until the product reaches about 10 customers.

5. Growth: When a product goes beyond two customers, it is time to think about scaling the product for dozens of customers. This is when a platform product manager, usually a senior leader in the team, and a senior engineering architect join the team to build foundations such as configuration tools, reports, scalable infrastructure and data models. This usually takes about on 1-2 product managers working with multiple engineering teams for 2-3 quarters. The skills required to do this are very different from the skills required to build a minimum viable product.

The key take aways:

• It is possible to incorporate an innovation framework into the quarterly product planning and development process to tap into the talent and creativity of many people in the organization in a systematic and sustainable manner.
• Product organizations that recognize the different stages of product design and development and apply different execution frameworks to each type of work will outperform those who don't.

Executive teams that recognize this and invest in such frameworks and people will outperform those who do not do so.