Building in an Experimental Mindset in your Product Development Process

By Prashanth Nanjundappa, VP of Product Management, CHEF Business Unit at Progress

Experimentation is at the heart of innovation and while it is the norm in creative fields, it is not always the ‘go-to’ approach in business. Many associate it with failure – while your experiment might be successful, it might also fail – and in business, no one wants to fail. Consequently, many enterprise leaders often try to stay away from it. That is the reason why true innovation happens so rarely. But to create something new and unseen, you must get out of your comfort zone and experiment without knowing what lies ahead.

Introducing an experimental mindset in developing and commercialising new products is crucial. Knowing the right way to integrate it into the development process can determine the success of all efforts across teams and functions. In this article, I am sharing some of my experiences in building in the experimental mindset through the key steps of new product development, with the lessons I have learned and the challenges and opportunities I have seen.

Innovation starts with discovering a problem worth solving

A study from McKinsey Global Institute found that for every seven product ideas, only 1.5 launch and one succeeds. Identifying a key problem that needs to be solved is essential for product development and may be an area of concern for entrepreneurs.

Asking customers what they want might not lead to ideas or suggestions that can be implemented because customers themselves may not be aware of what is possible beyond the obvious. Innovation teams should embark on a discovery journey to make sure they are on the right track.

The first step of this journey involves looking for a problem that a large group of people or businesses are experiencing and for which there is no satisfactory solution available or those available are not effective or commercially viable. The problem should be critical so that users would be willing to pay for its solution. Also, the problem is aligned with your organisation’s business strategy, and finally you should have the expertise, experience and resources to solve it.

Interestingly, sometimes those who face a certain problem for which you can find a solution may not be the key decision-makers in their company. In this case, product teams must balance end-customer satisfaction and revenue generation.

We sometimes invest in a project only to find later that it is not going the way we expected. There is little or no room for course correction or recovery. The best thing about an experiment is that failure is a learning opportunity. Innovators and product managers need to be prepared to fail fast and recover. Once we see that the investment is not going to work, we must stop, adapt quickly and make the required course corrections or sometimes even pull back the investment.

Devising a framework that delivers, based on experimenting and learning from failure

Navigating challenges in product development is key. Establishing a culture of innovation helps companies go through each stage of the innovation cycle quickly through collaboration among different teams. I have found that creating a repeatable process and framework, based on an experimental mindset works best. This framework should cover the entire process of product development – from creating the concept and big picture to tracking the execution of each small step towards completion.

The following table summarises the framework that is put into practice to create repeatable processes.

Stage  Time  Goal  Metric for the Next Stage 
1. Problem/Solution Fit ·         +2 Months

·         +1 Month Buffer

·         Identify the market segment and pain points

·         Define personas (users and buyers)

·         Calculating addressable markets

·         UI Mocks or User Journey Documents OR POCs

·         X Customer Conversations

·         Y Pilot Ready-Leads

2. Customer Validation ·         +3 Months

·         +1 Month Buffer

·         Implementation in the customer environment

·         Get customer testimonials

·         POC, Landing Pages, Sales Enablement

·         X Pilots (Not GA, may be free of cost)

·         Y SQOs (sales qualified opportunities)

·         Z SQLs (sales qualified leads)

3. Product Launch

1-PM, 1-UX, X Sales, large Engineering team

·         +3 Months

·         +1 Month Buffer

·         Go live ·         X paying customers

·         Y pilots

·         Z SQOs (Z++ SQLs)

4. Scale Product ·         Continues Process

In the first stage, after you have identified your problem and decided on a framework, you focus on understanding the market segments and their pain points, defining the personas, such as users and buyers and estimating the addressable market. Easier said than done. It includes building artefacts, such as user experience mocks or user journey documents. We can then start building the product. At this customer validation stage, we implement our pilots in a customer environment and get their feedback.

In the next two stages, we use the learnings to accelerate into the iterative development of the product. We get it ready for release into the smaller segment of the market and refine it based on feedback to make it available to a broader segment. This stage takes a long time as we work to finalise the product, run trials, outline sale targets, plan for release and arrange for customer support. Also, if the customer feedback is not as good as we expect, we get back to the drawing board to develop a new product altogether. If we are not able to get the traction we need during this cycle, stopping further investment is a clear possibility, too. We cut our losses, learn from the experience and apply our learnings in other experiments or products under development.

The stage involves scaling the product – you have some paying customers, and based on the traction received, decide how much more to invest and scale the product. By this time, you would have found a set of paying customers and numerous leads who had expressed interest at various levels to buy the product if some conditions are met.

We applied this framework in many products but this is one such example. Our team and I worked back-end on a free tool that had about a million monthly active users and a good brand recall value. The product was not making money, but we still had to support an increasing user base. We had rationalised investing in developers supporting this product without any revenue as it was a loyal userbase and the product was used in business-critical operations, too. Our research showed that there were some core problems that the customers were facing and are willing to pay for a product that bridged those gaps. We identified them and introduced a new product with these features as a paid version. It was done by applying the framework, through which within a year we were able to identify product-solution fit, validate customers and launch the paid version of the product, alongside the free version maintaining differentiation between both.

Bringing in business innovation and transformation

Creating an experimental mindset is not without its challenges. Without management support, it will not work. It must be something the whole organisation adopts. Failure is the inability to identify when the project is not going in the intended way. I believe in failing fast and applying the learnings to future experiments. As it calls for increased agility and responsiveness, we also need a flexible team that can move from project to project and stay motivated.

Following an experimental mindset is an evolving methodology that has shown greater success of products that are launched and a faster time-to-market. A flexible team that has adopted agile development methodologies and processes is necessary. It is not only essential for business continuity but also for business growth.

product development
Comments (1)
Add Comment
  • Phani

    Very Nice article. I strongly beleive in fail fast and apply learnings in future experiments.