What is innovation development lifecycle and why it precedes SDLC?

Kinesh Doshi,

Aswani Karteek Yadavilli

Many years back, at a conference on innovation, someone asked Paul Flaherty, the original founder of Altavista – the famed search engine of the yesteryears, “Now that a lot has already been invented, would the pace of innovation slow down?” Paul promptly replied “quite to the contrary, it will only accelerate.” he went on to explain that “with each new innovation, mankind will get a new lever to innovate with, and hence the design space, or the opportunity to innovate will exponentially grow.” This exchange left a lasting impression and has been our viewpoint to help clients find newer ways to combine innovations and create greater impact. Today, 10-12 years later, we know that innovation has only accelerated.

The problems facing mankind have always been the big driver of innovation, and the problems in front of us are just unbelievable. A lot of these problems can be solved by software and technology. And so, we don’t really have the liberty to slow down on innovation. Most of the problems of today demand a faster problem-to-solution lifecycle. And, while most of our customers are busy managing business-as-usual, we realized that we had to address the best way to start from a basic question – ‘How do we take up a problem and create a solution for it.’

Imagine for a moment that one had data about, all the movies and TV shows that were ever made, data of all their scripts, the schedules when they ran, what equipment was rented, what were the expenses for it, etc. How do you make sense of all this data? Is there something to learn from it? Can it be monetized? How do find answers to these questions, what is the best approach to solve them?

The visionaries, CTOs and CIOs don’t have time nowadays and usually will give you a one-line problem statement that they want you to solve. They may want to increase the engagement of their employees with an Amazon-like experience, or reduce their customer onboarding time from two months to two days. They may want to double the efficiency of their frontline agents using A.I. assisted learning, and so on. What you often receive is the vision statement or a problem statement from a customer and they really want you to figure out the solution. And today, if the product development itself is an 18 months cycle, we cannnot have requirements gathering going-on for 3 months. It has to be faster.

A lot of our tech leads and project managers were asked, “How many times have you encountered a situation where the customer had previously sent you the requirements and you felt like they’re changing the requirements once you’re done? How many times do you feel like you’ve had no requirements given to you? The answer we got – all the time. Similarly, when customers were asked, “How many times do you believe that you had shared all the requirements, but when you received the product it was completely different from what was requested? The answer we got – all the time. This is a recurring problem, where the tech teams feel that the requirements are incomplete and they don’t receive the specifications in detail. On the other side, customers believe that they had given enough details, but the tech teams are unable to comprehend them. So, there is an expectation mismatch from both sides.

We then started to brainstorm on how do we solve this problem and bring the two thought-processes together. In the process, we realised that there is an important step before Software Development Lifecycle (SDLC) where we expect some kind of semblance of requirements and build the software on that. Speed also becomes important as work across distributed teams spread out in different geographies and timezones and each one needs to be on the same pace of development. As we consider all of these questions, ideas for solutions that come to us, that pattern is what we are attempting, to call as the Accion Innovation Delivery Lifecycle (IDLC).

Accion Innovation Delivery Lifecycle (IDLC)

Historically, what we have always done is, proposed what we call a discovery workshop with customers. The problem with ‘discovery approach’ was that it seemed as we were trying aimlessly to reach to a destination without a sense of direction. It was good for simple fixes, but product development today demands 360 degree approach to understand, what is the core problem you want to solve and how will you go about it. We then came up with the idea of a structured approach where you had the stakeholders to think about, how to do the right things and figure out which things to go after first.

The Accion IDLC talks about five different stages in doing so. The first one talks about the ecosystems and analysing them. Second, identifying the ideas and generating them, and then looking at which path is worth pursuing along with whether we are thinking about this the right way and then looking at all those innovation levers. And third, seeing is this the right way to solve this problem? How do I think about this problem? As you keep asking those why and how questions, you try to evolve your understanding of the problem, to a point where you can think about designing your solution. That’s the fourth step. And once you found your solution, you can start thinking about the fifth stage, how do to take it to the market. What is my market? What features should I build first? Should I try to build tires and then try connecting them like a car? Or do I think about looking at what learnings I need out of them and start iteratively, developing things based on what I learned. So that is what we’re looking at as innovation delivery lifecycle.

Levers of Innovation

What ‘digital’ does to an organization, is that it makes it run fast and change fast. And you are not going to achieve the speed, by just transformation of your back end technologies alone, you have to modernize your frontend technologies too to match up to the speed and experience for today. Hence innovation. And as technology evolves, you get new technology levers. So when barcode was invented, it suddenly changed the way we did supply chain. As social media came along, you changed the way, you interacted with your customers and we saw arrival of social commerce. So similarly machine learning, blockchain and many of these emerging technologies are the technology levers. As you add a new technology, your design space grows. When these technologies combine like mobility, cloud, social media and blockchain – you will get something new. The thought process we are going towards is that when we look at a problem and try to find a solution, we should approach it from the design space concept, using the best-suited technology levers for the problem. In traditional discovery workshop, we try and follow a workflow based process, and that hinders a type of discontinuous innovation, where you are really breaking an old box and build a new one altogether – reinvent it in a new design space.

Principles of Accion IDLC

A famous economist and speaker also spoke about, “It’s about fast fish and slow fish. It’s no longer about the big fish and the small fish.

In coming up with this innovation development lifecycle we’ve identified a few things that can be understood as principles. You’ve got to think about building to change. Building to last is important, but you must first think about building to change. Otherwise you are going to be in your own way changing. Start thinking about metadata and instrumentation from the moment you start building the application. Don’t plan on building the application and then thinking about how to analyse the data, because if you do that you’ve already lost the battle.”

A problem or a pain is an opportunity waiting to be solved.
Ecosystem is a sum of people, projects, products, process, plans and of course pains
Digital Transformation is more than just great visual design or user experience
Analysis … Too much vs too little. Have a bias towards Accion (Action)
Choose and Choose wisely – Iterate or Pivot or Quit.
Build to Change – Fast fish eat slow fish!
Think Metadata & Instrumentation
Technology, by itself doesn’t solve every problem.
Innovation doesn’t have to be chaotic.
Have a Value Driven, Architecture-First Approach

6P Framework

The whole idea is that doing the right things is important, as is knowing what you want to solve first. What we’re saying is – when a customer gives you a problem, and you go ahead and solve all the problems statements up front – that is the most dangerous thing you can do. You first need to understand the ecosystem. We have what we call the 6P framework, where we look at all the products, all the people involved and all the different projects that are going on and validating if the problem that you’re currently solving is the right one. Sometimes the problem itself can be the wrong one, so you need to rephrase the big problem statement and break it into smaller and more easily solved problems. That’s what we call problem validation or opportunity validation. The words problem and opportunity can be used interchangeably, because at Accion, we believe that sometimes the problem that the user is telling you about is not the opportunity you should be of fixing or solving. After that, we perform a solution definition and what we call a lever analysis. That involves taking each mini problem that you have or mini opportunity that you have and mapping it to all the technology levers you have and basically realizing that this problem can be solved by using a schema-less database or a NoSQL database, this problem can be solved using machine learning, and you can have multiple levers solving a specific problem. This creates a sort of matrix that you can further develop. At this point, your UX architect has been on this journey with you thus far and now that you have identified which tech levers will help you solve which problems; you can enter the UX design process. Once your products UX design and some of the interfaces are ready, you do the MVP planning and go to market planning at that point in time. Some of these phases can go in parallel. The planning phase could go in parallel with the UX design as well and of course after that you can switch to SDLC. This process of IDLC can be done frequently and with with each release but the concept remains the same.

Who are the actors in IDLC?

In the development lifecycle of innovation, there are three important roles at play. The first is the product architect whose focus is going to be upon which levers to look at for each problem, whether this is the right problem to solve and the right opportunity to solve it. This individual works at understanding which levers to apply. The second role is the UX architect, who finds out how to solve each problem as you look at these levers. The third role is the product manager who helps to prioritize things, making sure that we are looking at issues in the right order, such as figuring out where to draw the cut line, or going to market strategy and Interfacing with the different teams who focus on those areas. For each of these roles we do have examples of how we have done things specifically for each one of those problems and what our vision looks like.

How to look at opportunity lever mapping, and then create a solution diagram that outlines the solution by creating the user journey and trying to identify what are the things that we have to fine tune are in each of those journeys. We then build those aspects that you need.

As you build along the way, you then start working on MVP, how not to think about MVP, how to continuously keep learning throughout the journey and go to market strategy, how you may have tons of options to choose from and who you focus on prioritizing and building distribution for. That is a summation of our thoughts now and how we’re looking to build innovative digital products at Accion. We’ve been inspired by the LUMA Institute and they have contributed a lot in this work, there are also others who contributed their thoughts and worked with us on this.

‘How do you take a problem and create a solution.’

A lot of our tech leads and project managers when asked a question, “How many times have you encountered a situation where the customer has previously sent you the requirements and you feel like they’re changing the requirements once you’re done? How many times do you feel like you’ve had no requirements given to you? The answer we got – all the time.

Similarly, when customers are asked, “How many times do you believe you have shared the requirements, but you receive a product that is completely different from what was requested? The answer we got – all the time.

So, there is an expectation mismatch from both sides. It is a recurring problem where the tech teams feel that the requirements are incomplete and we don’t receive the specifications very well. On the other side, customers believe that they have given enough details. It’s a commonly faced issue.

We started brainstorming on how do we solve this problem and bring the two thought-processes together. In the process, we realised that there is an important step before Software Development Lifecycle SDLC where we expect some kind of semblance of requirements and build the software on that.

If, product development is happening in an 18 months cycle, we cannnot have requirements gathering for 3 months. It has to be faster, particularly in a distributed world with different time zones. Also in the last few years, we have seen that customers don’t have the time, these are the visionaries, CTOs and CIOs and they give you a one-line problem statement describing the problem they have.

They may want to increase the engagement of their employees with an Amazon-like experience, or reduce their customer onboarding time from two months to two days. They may want to double the efficiency of their frontline agents using A.I. assisted learning, and so on. What you often receive is the vision statement or a problem statement from a customer and they really want you to figure out the solution.

As something else to think about, imagine for a moment that one had data about all the movies and all the TV shows that were ever made, and data about all of their scripts. This may include when the schedules ran, what equipment was rented how much should was paid for it. How do you make sense of all this data? Is there something to learn from it? Can it be monetized? These kinds of problems have all being talked about for a long time. But how do we solve them?

As we consider all of these questions, ideas for solutions that come to us. That pattern is what we are attempting to call as the Accion Innovation Delivery Lifecycle (IDLC).

Accion Innovation Delivery Lifecycle (IDLC)

Historically, what we have always done proposing what we call a discovery workshop. We tell customers that we’re going to come in and make some discoveries with you. Now, the word discovery makes it look like we are aimless, so our thought process was that, we need to change that thinking of just spending a week together and making some discoveries. That’s where we came up with the idea of following a structured approach around this.

To sum it all up in simple words, you need to think about how to do the right things and figure out which things to go after. We will focus on figuring out what those right things are.

The Accion IDLC talks about the five different stages in doing so. The first one talks about the ecosystems and analysing them. Identifying the ideas and generating them, and then looking at which path is worth pursuing along with whether we are thinking about this the right way and then looking at all those innovation levers. And seeing is this the right way to solve this problem? How do I think about this problem?

As you keep asking those why and how questions, you try to evolve your understanding of the problem, to a point where you can think about designing your solution. And once you found your solution, you can start thinking about how do to take it to the market. What is my market? What features should I build first? Should I try to build tires and then try connecting them like a car? Or do I think about looking at what I need out of them and start iteratively, developing things based on what I learned. So that is what we’re looking at as innovation delivery lifecycle.

We have what we call the 6P framework, where we look at all the products, all the people involved and all the different projects that are going on and validating if the problem that you’re currently solving is the right one.

Sometimes the problem itself can be the wrong one, so you need to rephrase the issue and break it into smaller and more easily solved problems. That’s what we call problem validation or opportunity validation. The words problem and opportunity can be used interchangeably, because at Accion, we believe that sometimes the problem that the user is telling you about is not the opportunity you should be of fixing or solving.

After that, we perform a solution definition and what we call a lever analysis. That involves taking each mini problem that you have or mini opportunity that you have and mapping it to all the technology levers you have and basically realizing that this problem can be solved by using a Schema-Less database or a NoSQL database, this problem can be solved using machine learning, and you can have multiple levers solving a specific problem. This creates a sort of matrix that you can further develop. At this point, your UX architect has been on this journey with you thus far and now that you have identified which tech levers will help you solve which problems; you can enter the UX design process. Once your products UX design and some of the interfaces are ready, you do the MVP planning and go to market planning at that point in time. Some of these phases can go in parallel. The planning phase could go in parallel with the UX design as well and of course after that you can switch to SDLC. This process of IDLC can be done frequently and with with each release but the concept remains the same.

In coming up with this innovation development lifecycle we’ve identified a few things that can be understood as principles. I don’t want to go through each one of them and bore you, but I’ll talk about the one which a famous economist and speaker also spoke about. It’s about fast fish and slow fish. It’s no longer about the big fish and the small fish. Size is not a reason to not move fast enough or else the slow fish are going to eat you slowly bit by bit. Stop thinking about big and small, start thinking about fast and slow. Otherwise the fast fish are going to eat you for a meal.

How to look at opportunity lever mapping and create a solution diagram outlining the solution and then attempting to do so by creating the user journey and trying to identify what the things that we have to fine tune are in each of those journeys.

We then build those aspects that you need. As you build along the way and then start working on how to think about MVP, how not to think about MVP, how to continuously keep learning throughout the journey and go to market strategy, how you may have tons of options to choose from and who you focus on prioritizing and building distribution for. That is a summation of our thoughts now and how we’re looking to build this. We’ve been inspired by the LUMA institute quite a lot in our work, but there are also others who contributed their thoughts and worked with us on this.