Category: Product Management

The term agile refers to the flexibility or ability to adapt as and when needed. Agile product development, which today has become synonymous with various frameworks being used, is in essence an approach to product development which makes adaptation to constant changes feasible by running continuous short stints of “requirement to functional readiness” process. Requirements are drip fed into the process and constant feedback and continuous collaboration is encouraged to mature the product over multiple iterations.

A key challenge with the waterfall model that was highlighted in the previous posts was the huge and costly lag before stakeholders get to see the end product. Agile development hits at the heart of this issue by bringing in transparency to the whole process for stakeholders.

An excellent place to start if we want to know more about Agile product or software development movement started is the agile alliance website – https://www.agilealliance.org/agile101/ . It define agile development as

“Agile software development is more than frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).

Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions, and sprints.

Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.

One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.”

agilealiance.org

For ease of reference, we have provided below the manifesto and 12 principles of agile development as referenced in agilealiance.org.

The immense popularity of the approach in building software and IT products is a huge credit to the authors of ‘Agile Manifesto’ for defining a philosophy which works. It is important to note that the authors have only reiterated that these are the guidelines for building a good product efficiently. Around these guidelines were a set of frameworks developed like scrum, extreme programming etc which defines the methodology to be followed. There are quite a few of these frameworks which gets used today. However one of the more popular ones is Scrum. We will take a look at the Scrum process in the next post.

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.

Phase 3 of product management

Some may argue that this is really not an independent phase but more a part of the idea and business case. But the contrary view is that can we move something to mainline development without validating the idea or can we create a prototype without having funds to do so. In some organisational internal projects, there may be a possibility of leveraging some spare capacity and resources to come up with a basic and elementary model of the product. And so it may be the case with when entrepreneur would pool in their own money to get a basic version ready. In both the cases this phase can be clubbed with the idea and business case. Either way, the importance of having a prototype is not lost.

We are considering the phase separately given the importance it can play in make or break of the future funding. With the first cheque from the investors or sponsors, the team sets out to put together a working model. Here the roles of people involved gets diluted as the team is very small and one person may wear multiple hats. So the same person can draft requirements , provide a design and may test as well. Essentially the focus is to turn around a working model with limited budget and resource to prove that the idea works.

Once the prototype is ready, a demonstration session with all key stakeholders is held to show the idea in action. To be clear, what is built and what is demoed may not even be 5% of what is proposed but it proves the point that it works! This common conviction of both the owner and the investor is critical as it pretty much seals the next phase of the product management.

Now that the investors are convinced – they feel confident to write the next cheque. But bear in mind it is not a ‘blank check’ but milestone based one. The next milestone is agreed with the owner and this time a more generous check is offered as now the product work will go mainstream. Which essentially means a more structured approach to product development. This is covered in detail in the next postt.

Phase 2 of product management

Post identifying a problem statement, we set on course for identifying a solution to the problem, solution to the need that was identified. This phase can be quite dynamic – it can be individual led or it can be a team effort. Someone out of the blue can identify a solution and sometime a group of people can identify a solution as a collective and disciplined effort. Either ways an idea in itself cannot achieve much unless there is conviction to it but more importantly there are people ready to back (fund) the idea.

This is when we start putting together an initial view of how the idea would work. What starts with an idea slowly starts taking taking form through rough sketches, white board drawings and in some case even literal articulations. Over next few iterations – idea takes a definite shape and is ready to be presented to sponsors. Every idea every generated which has seen the light of the day would have been backed by a sponsor. In some cases the sponsor can be the owner of the idea itself whereas in other cases it can be deep pocket investors. For an established organisations, there are dedicated processes through which ideas are approved and funded. We will try covering the process of fund raising in a separate post. It’s quite an interesting area and definitely merits a dedicated post.

What we though need to understand is how the idea and its merits are communicated to the sponsors and other stakeholders. The proposer or owner consolidates all the relevant details about the idea and develops a business case supporting the initiative. An idea business case would contain:

1. Objective
2. Problem statement
3. Potential solution i.e the idea
4. Detailed flow including business and technical
5. Benefits of the idea
6. Cost Benefit analysis

It will be wishful thinking to expect sponsors to start funding the moment we present a business case. Putting together a business case is just a medium to facilitate discussion. Like any careful investor or sponsor decision, what follows are multiple rounds of discussion covering every element of the business case. The process can run into days , weeks or sometimes even months before the investor would say yes. After all it’s money. Here it is important to understand the concept of opportunity cost. Opportunity cost refers to the cost of giving up an alternative in favour of another. For instance if we have $100 and you can only either invest in an ‘Apple’ share or a ‘Google’ share. So the opportunity cost of investing in ‘Apple’ is foregone benefit of dividend and capital appreciation from ‘Google’. The reason opportunity cost is important is that investors would have more than one alternative to commit their money. So before they can make the decision they need to be doubly sure that it’s worth the opportunity cost not only of the money but also the effort and time spent. In an organisational set up the alternatives is between various projects that it can spend money. The budget is defined but at any time number of projects which requires investments will be more than the available budget.

If and when the business case is approved, investor will generally take a staggered approach to first convince the idea would actually work before putting additional money. The usual request is for a proof of concept or a prototype to be developed to validate the idea. This is essentially where we move to the next phase of the product management.

Phase 1 of Product Management

Before early humans discovered wheel, its worth imagining moving about or moving things about. A journey which today takes minutes or hours used to take days and months. Discovery of wheel started with a problem or need to improve a situation, to live a better life, to improve the quality of life. Come to think of it every invention, every innovation, every improvement always has the most fundamental driver of elevating human life to a higher standard or very importantly to counter fear. Even though our focus is specifically around IT products, as we covered in ‘What is a Product Management’, the general principles are applicable to wider spectrum of products. And it all starts with a need, a problem and what can be done to address them.

Question is how do you identify a need? It starts with when we identify that the current way of doing something is sub optimal. It is sub optimal in the context of effort, time, cost, risk and convenience. Sometimes all of them can be factors, sometime one or combination of factors can be a key driver for a need. Arguably, risk can trump everything else for a need to exist. One of the products that I build was an online ‘checklist’ functionality for investment banking operation users. Checklist sure should be a common term used across industries, however, from an investment banking perspective checklist refers to set of activities users are meant to do on daily, weekly, monthly, annually for ensuring smooth running and compliance to rules. The first discussion that we had before we got down to actually building it was to understand from the users what was driving the ask. When we spoke to the users, we were informed that current process was cumbersome with checklist being maintained in spreadsheets, paper, isolated utility tools etc. Primary issue that was being highlighted was the lack of consistent controls which essentially means the process was risky. In some cases misplaced documents or lack of control to ensure timely completion of regulated processes had resulted in regulatory warnings. It was effort intensive as some of them were being maintained on paper which had to be filed and regularly maintained.

If we want to take a more general example, lets evaluate iphones which disrupted and introduced a new way of doing things. Before the advent of iphones, and I will take the liberty of ignoring some prototypes in between, humans would need a mobile to call and message and the other products to listen to music, check weather, play video games, read news etc etc. Two factors that I can pick up from pre iphone days which drove the need was cost and inconvenience of buying and maintaining many different products. Actually with iphones Steve Jobs famously quoted’ “People don’t know what they want until you show it to them“. I wont be surprised if before iphones anyone even remotely thought what a smart phone could do. But what is important to note is that when Steve Jobs and his team thought of iphone, the need for having such a product was at the heart of the discussion.

When we refer to lifecycle, we essentially means that something having a beginning and an end. In case of product management, the lifecycle would always start with a problem statement. Some may argue that it is an idea where the process would start but ideas are always in relation to a problem to be solved. Now what we define as a problem can be subjective.

With problem comes the yearning to resolve the problem. Take a moment now and just look around the room. Every product which you see around solves a problem. Isnt it? So we think of an innovative idea to resolve a problem.

But how do we know if the idea will work? So we decide to create a prototype or proof of concept and test waters with the proof we created. We reach out to various touchpoints to validate the solution. All or some of them would have initially contributed to the process by defining the problem statement.

Once the solution is validated, feedback is incorporated and then actual process of building the solution starts. This is followed by rolling out the solution/product and eventually a feedback loop is put in place based on which additional features are added.

Final phase, as with anything, is the end of the product or phasing out the product.

What we have covered above is, in a nutshell, in summary the product management lifecycle. Let’s try putting this in phases as discovered above

1. Problem statement
2. Idea and business case
3. Build a prototype and demo
4. Product development
5. Product marketing, rollout and support
6. Product enhancements and new feature rollouts
7. Product wind down

We will cover each of the above area in detail one by one in the subsequent sections. A quick point on the fourth phase. Product development is detailed process in itself and can cover various steps.