Through this article, we will attempt to demystify what is a product development in the Financial Services industry! What are the various types of product development models that exist for software development and what are the few facts and dope that Chartered accountants need to be aware about and what are the few things they need to be knowledgeable about.
Any google search on the words “Product Development” would yield lot of results about the same including a wide variety of the stages involved in Product Development.
Generically speaking, a product development life cycle goes all the way from the birth of a product to its decline. However, we will focus this article on how a product is developed and launched in the market especially in the Financial Services domain, and especially from a system and software perspective.
There are no exact number of stages that one can assign for developing a product. From my various experiences of working in Banks, it broadly spans about six stages or six steps that are important before the Customers finally experience the product or solution.
There are a couple of important topics that I have deliberately kept out of the purview of this article like Investment needed for launching the product, Budget tracking, Project Management, ROI computation, Digital Marketing, etc., which are more a part of the overall Product Management (and a super set of Product Development).
We will more focus on product development from a market launch perspective. It is important to note that when Financial Services Companies - be it Broking, NBFCs or Banks - create products there is a method to how the same are developed.
There are six broad stages how a product is developed. We will go through each of these in detail.
1. Ideation or Concept Stage:
The soul of any product is its idea. Any idea is not valid in vacuum but if it creates value for its end users (or Customers in this case) then it not only becomes valid but also valuable.
Any concept has to address a problem for its end users. The problem definition is the first step in the idea creation process. It is what leads to whether the idea (or the solution) creates value for its users.
Let us take an example of Home Loan. Getting a home loan is not the problem definition for a user but getting a home is (in a real sense)! However many a times this becomes the biggest bottleneck for various reasons.
While there are various steps involved in a home buying process, Financial Services industry fulfils only part of this for its Customers. However, most of the times, this home loan process becomes the most important (or rather the critical) step for any homebuyer in his/her home buying process.
Therefore, the idea for any Financial Institution would be to make the process of applying for loans and the process of disbursing loans, as easy and as seamless as possible.
This would make the home buying process a memorable one for the Customers. In addition, it should create so much of trust and loyalty with the Customers.
Financial institutions or Lenders should therefore dig deep and whiteboard all the existing problems that their Customers face. They should define and solve those problems for Customers, and this would be the best place to start any ideation process.
Team ideating a concept
The important part of ideation is to identify the problem and put them on a wall. Also, identify what ideas are possible solutions to the problems put-up! This, exercise is done best in an environment where people are free to ideate and collaborate from various departments.
Creating the Backlog or demand funnel:
Having ideated on possible solutions for existing problems, the team needs to pick-up those solutions which can be implemented – whether immediately or later. This helps us create a backlog and or a demand funnel so that we can move to the next stage of creating requirements or user stories.
Creating a backlog is an integral part of the product development process. It helps teams understand the scope of work and the capacity that would be required before they pick up the story for development. However, before a requirement or a story is picked-up for development, the same needs to be written or made ready. This is the logical next stage in the product development cycle.
2. User Story or requirements:
The bridge between ideas and development happen in the form of writing requirements or writing user stories.
From a software development perspective, the developers do not understand ideas. They need to know exactly what needs to be developed. In this regard, the developers need a document (by whatever name called) that will explain to them among other things, the following:
a. What is the exact requirement or the story (solution proposed)?
b. What is the business context? As in, what problem are we trying to solve through this requirement (solution)?
c. What is in scope for this requirement or story?
d. What is out of scope of this requirement or story?
e. What have been the assumptions made?
f. What is the acceptance criteria? As in what is the given problem? When does the problem happen? Then what do we do about the same?
g. What are the dependencies?
Now that we have our requirements ready, we can start the software development process to bring to life the solution we have envisaged. There are two ways of developing software:
- The waterfall methodology and
- The agile methodology.
Waterfall methodology follows a slow and structured way of developing software where each phase of development is completed before the next phase begins. There is no overlapping in the phases. While the agile methodology follows a quick “test and learn” way of developing a feature or software. For more on this please refer to Principles behind the Agile Manifesto.
The difference between the two methods is primarily two-fold:
a. Speed of delivery, i.e., how quickly we want to develop and release the software;
b. Extent of Testing, i.e. extent of testing before we release the final product, or solution.
If the requirement is very complex and touches the core solution of the software or is a fundamental change to how we have been operating it is better to do a waterfall
3. (Software) Development of the requirements:
The software development is done in a waterfall or in an agile manner.
In a waterfall methodology, the software is developed in small programs called units. Each unit is developed and tested for its functionality. This is referred to as Unit Testing. These small programs are then integrated in the next phase.
All the units developed in the implementation phase are integrated into a single software after testing of each unit. Post integration the entire software is tested for any faults and failures.
In Agile methodology, Test-driven development (TDD) is the software development process adopted. Software requirements are converted to test cases before software is fully developed.
Software development is tracked by repeatedly testing the software against all test cases identified. In TDD, developers start creating small test cases for every feature based on their initial understanding. The primary intention of this technique is to modify or write new code only if the tests fail. This prevents duplication of test scripts.
Three phases of Test Driven Development (TDD)
Create precise tests: Developers need to create precise unit tests to verify the functionality of specific features. They must ensure that the test compiles so that it can execute. In most cases, the test is bound to fail. This is a meaningful failure as developers are creating compact tests based on their assumptions of how the feature will behave.
Correcting the Code: Once a test fails, developers need to make the minimal changes required to correct the code so that it can run successfully when re-executed.
Refactor the Code: Once the test runs successfully, check for redundancy or any possible code optimizations to enhance overall performance. Ensure that refactoring does not affect the external behaviour of the program.
4. Quality Assurance (QA):
Quality Assurance is the process that checks and certifies whether the code meets the quality or not.
In the waterfall method, Quality Assurance is on individual modules.
However, in TDD approach, both developers and QA use test cases to develop their code and execute test cases respectively. So writing test cases that have good coverage of requirements is important for making TDD successful.
QA process should know the overall system much better than the development process (as a QA tests the system End-to-End). Therefore, it is required to involve the QA team in every phase of TDD and that too from the very beginning. QA should work together with the developer to make sure that unit testing is built into the core of the application.
Acceptance Test Driven Development (ATDD):
In the planning phase, QA will understand from customers about the acceptance criteria of each functionality. Then the QA will work together with developers to create test cases. Developers working with QA help in designing better test cases. However, QA can set up the acceptance tests upfront, that are at higher level than Unit tests and thus realizing Acceptance Test Driven Development (ATDD).
ATDD helps developers in deriving Unit tests based on requirements captured as part of acceptance tests.
Developers would be using TDD to test at lower level i.e. individual units. Developers will be concerned with the functional implementation whereas QA would be concerned about the overall implementation where individual units are integrated to form the complete system.
Finally, QA team should be the final judge of whether or not your product meets the quality standards set by the client and your organization.
5. User Testing (UAT):
UAT or User acceptance testing is one of the most important phases of product development. Here actual users and/or testers test all test scenarios (real life scenarios). The actual users / units that interact with users sign off the test scenarios, and test cases along with acceptance criteria for sign off. This is done either upfront or before the testing process starts and executed manually, or in an automated manner using scripts.
Unless the UAT is signed-off, the software is not released to the actual users in a production (or LIVE) environment.
How UAT is done and/or how UAT gets carried out is a comprehensive topic and cannot be covered here. However, more literature can be found on the link: What is User Acceptance Testing (UAT)? - Definition from Techopedia!
6. Feedback and Improvement
The most important part of the product development is receiving feedback. Feedback can be in multiple forms but the key is that it needs to be continuous. The teams that have ideated the solution and the teams that have developed the solution (as a software or a system) need feedback on how the solution is being perceived by end users (or Customers).
This can simply be a bug or a requirement for enhancement or sometimes we may end-up redoing the solution with new inputs or feedback from users.
If you are looking to partner with a team who can help you create products with technology, reach out to us today on info@executepartners.com.
Comments