Product Development – Intro

Phase 4 of product management

Once the primary idea is established through business cases and prototype and the owner (please note when we talk of owner it can refer to the person(s) who have come up with solution idea – so that can be an entrepreneur/ product owner/ inventor/ innovator etc) and investor are relatively more confident about the potential of the idea, the process start becoming more structured. This structured approach for developing the product is what is termed as product development.

Product development is a discipline in itself and consists of different methods. And each method constitutes various steps. Given the vastness of the subject we will cover this in multiple posts covering various elements of it.

Lets start with understanding product development first. By now we are clear with what is product. Product development refers to the various methods used to develop a product in a structured, controlled and disciplined manner. There are various methods which are prevalent today, some more popular than others but also some more relevant than others depending on the situation. We will cover the situation relevance a bit later. Among the common methods used for product development – the ones most elementary and popular are:

1. Waterfall model
2. Agile model

Bear in mind, many of the other methods that are around are essentially derivatives of these 2 basic models at least they appear to be. We will discuss about other methods in a separate post. It is also important to note that given our focus on IT products, we are essentially looking software development lifecycle models(SDLC)

Waterfall model

The classic and the oldest method of software development is the waterfall model. It follows a linear approach i.e. next step is only initiated after the previous step is completed. It consists of the following steps

1. Requirement gathering : includes documenting ‘what’ is required to be build. We link the requirement to the problem statement which we discussed in the previous post. What do we need to solve that problem? The documentation covers in detail various requirements which is overall a part of the solution. Requirement documentation can be split into Business Requirement Document(BRD) and Functional Requirement Document or even called Functional Specification Document(FSD). BRD focuses on the ‘what’ aspect of the requirement. For instance we plan to build a home loan processing system for a bank which will be used for capturing the details of the applicant online and will have workflow from initial submission to drawdown. BRD would cover the requirements related to having a form to capture the applicants basic details, income details, rules for evaluating the application, workflow for managing the reviews and approval etc. FRD will cover the meta data of the form, the features that will support the requirements, the rules for evaluating the application process, validation for submission etc
2. Design: Design phase focuses converting the requirement into a targeted solution. The questions that we start exploring are: what will be the business architecture, how the users will interact with the system, user interface, data storage, network connectivity, desktop vs online . Output from this phase will include one or more of the following – UX designs, detailed technical designs, flowcharts, UML schemas, prototype etc. There is a significant amount of ground which is covered in this phase and is critical for the success of the development and the product. There are elements of design which will be covered in a different post. Overall a very exciting and interesting phase given our product starts taking shape in this phase – creative and innovative factors are the highest in this phase.
3. Implementation: Implementation refers to executing the solution design as was discussed and approved in the previous steps. Even though, waterfall model follows a sequential model – implementation does involve back and forth with the architects and business analysts which may end up refining the designs further. Ideally any changes to the original design need to be managed by a proper change control process to avoid scope creep and resource overrun. A point to note in this regard is that a detailed estimation of effort and cost is done before implementation actually starts. This is done in a much more granular detail than the one done during the business case creation. Hence the need to have tight control on any change of requirement or a change in design. If we compare this phase to constructing a house – this is where the brick and cement starts giving to the shape of what was drawn by the architect. Only difference here is that architects are system architects and the product is a software instead of an actual house
4. Testing: Testing phase involves ratifying what was build in implementation. Testers gather details of the products from various artefacts like the BRD, Functional Specs, technical design document etc and tries to validates if what was conceived conceptually is what is build. Testing can be functional(e.g upload documents, submit application form) or non functional( number of users who can concurrently work on the product, performance of the product).Testing can lead to various defects being identified which gets reported to the. Developers review the defect and agree on a prioritised list of defects which need to be fixed. Testers validates quality of the product built and answers questions like-
   • Does the solution include all the agreed functionalities
   • Are all the functionalities as defined in the design document working as expected
   • Is the output correct based on the input provided
5. Deployment: Deployment refers to making the product live i.e. it is in a ready state and can now be used by the end users. Deployment is an highly controlled activity and requires a very strict control management to ensure a properly tested and approved product is what is rolled out to a live environment. What is also critical is that there is a fall back plan in the event go live does not go as expected. Deployment also includes a post go live check to ensure at a high level the product is working as expected. Depending on the roll out strategy , the product may be made initially available to a small set of users before scaling up.
6. Maintenance: Now that the product is live, standard process of maintenance, incident and change management kicks in to handle any changes or issues to the product post go live.

Challenges with the waterfall model:

A key challenge that often gets highlighted with the waterfall model is that stakeholders need to wait for a quite sometime before they actually gets to see the solution. Given the process is linear it is not until after implementation that an initial view of the the product is available. This may lead to a dissatisfaction among the stakeholders as there is a limited opportunity to provide feedback to improve the product. And by the time the feedback is provided, it is usually too late or too expensive to make any changes.

Some of these challenges essentially led to an alternative method of SDLC known as agile methodology. Agile as the name suggests brings in the flexibility and agility in the development process by providing regular feedback loop for developing the product. We will cover the agile process and look at a popular agile method called scrum methodology in a different post.