A quick Google search of “Product Lifecycle” usually brings up that chart you might have seen once in school.
This lifecycle encompasses four stages: Development (or Introduction), Growth, Maturity, and Decline.
That first stage, development, is where engineering, product, and design teams create products. Yet, there’s not much information available about this phase of the Product Lifecycle, which contains an additional cycle within it called the Product Development Life Cycle.
The main reason is because every organization is different. It’s not exactly a “one size fits all” process. Even two software companies with similar tech stacks, the same number of developers, and similar users will develop different software. While the high-level steps (like ideation and research) might be the same, there’s a lot of variation within each of those steps.
Despite these challenges, Melissa Chenok, former Group Product Manager at DC-based startup Quorum, took the time to create a detailed set of steps for the company’s Product Development Lifecycle (PDLC) which includes a Software Development Lifecycle (SDLC) within the implementation stage of the PDLC.
We asked Melissa to break down the steps in detail.
The PDLC and SDLC processes implemented at Quorum are surprisingly universal. While some tweaks may be necessary to accommodate for different programming languages, type of SaaS software or other variables, the overall process can be applied for developing most products and features. Although these cycles look seemingly linear, because software teams are increasingly moving to agile environments, many times over the course of a product development life cycle there will be iteration over previous stages.
Why is it worth following a standard process?
Following these PDLC and SDLC processes allows for standardization and scale of software and teams. New team members will be able to jump in and get up to speed quickly and existing team members can automate some of the basic project management related to developing new products. A standard process also enables cross functional teams to collaborate more effectively and efficiently since they’re all on the same page about each step that needs to be taken and dependencies to take into account.
A Look at Quorum’s Product Development Lifecycle
The 7-step process takes Quorum’s team through the entire journey, from product ideation to development and launch.
All of their products and features go through this process, which, in an agile environment, sometimes take place multiple times over the course of developing a product or feature. Everyone who’s part of the lifecycle, from engineering to customer support, contributes to and has bought into the mission. They all know what the process entails and what they need to do in order to make each product a success. Each of the steps are outlined at a high level below and once you finalize each step, the team can move to the next step.
Should we do something? To answer this question, you have to look at a variety of sources, such as customer pain points, competitor and market analysis, and client (or potential client) requests.
You also have to take resource constraints into consideration: How long will the project take? What will the impact be on the bottom line? Does this solve user pain points and to what extent? What other projects are currently happening? How many product and engineering team members are available?
What are we doing? This is when you determine whether there’s potential for growth. It involves user research, developing prototypes, and feature analysis. The product manager, tech lead, and designer work together to come up with the initial requirements and wireframes that will be included in the product requirements document.
How are we going to do it? This phase involves writing detailed product and design requirements and plan. Now’s the time to look at expenses, required resources, and UX/UI outputs. Other key steps include drafting technical design documents and deciding what the ticketing system will look like.
Do the thing. This phase is where the Software Development Lifecycle (SDLC) comes in. The SDLC is important because it allows the team to see up front goals, like what you’re building and why you’re building it.
In a lot of ways, the SDLC is the engineer’s day-to-day job. The SDLC includes defining tasks, building and testing software, getting code and product reviews, and deploying final code onto the production environment.
(Note: Keep reading below for a full description of the SDLC model used at Quorum!)
Now it’s time to bring in the rest of the organization. Create marketing materials, train the team, determine the final launch date, write internal and client guides, and more.
The product goes live for clients! This step includes communicating to current clients and the broader ecosystem that the product or feature that the team has been working on is live. There are many steps that go into the higher level step including sending out marketing collateral, turning the code on for clients, implementing sales plans, etc.
Measure and Maintain
Keep track of Key Performance Indicators and metrics that the product and sales teams have put in place. This is also the time to make updates based on client needs, create proposals for additional features, and decide if anything should be done to improve or enhance functionality.
This is also when many teams conduct retrospectives with all team members who were involved with any step of the product life cycle – from marketing to infrastructure. They ask, “What went well and what could have gone better?”
By bringing all the key stakeholders into this question, they gain a broad perspective of the process and learn how to collaborate better on the next product launch or feature release.
A Look at Quorum’s Software Development Lifecycle
In the middle of the PDLC, during the implementation phase, is the Software Development Lifecycle (SDLC). Each of the steps, similar to the PDLC, are implemented, and when each step is completed the team or engineer can move to the subsequent step.
This is your chance to break down the work defined in the technical design documents. Create an outline of all the tasks that need to be done. Then enter those tasks into the ticketing tool so the product and engineering teams know exactly what sprint each task belongs in. Often, because we work in an agile environment, these tasks need to be expanded on over time.
Build and Test
During this time, the engineers focus on actually building and testing the code. Both during and once code is written, engineers will also write unit, end to end, infrastructure and security tests for the code.
At Quorum, for feature and product launches, the full product team will conduct manual testing sessions in addition to the automated tests that the engineers have written.
The review process involves peer code review and often code review by tech leads or engineering managers. When relevant, this also includes a weekly demo and product into design sign off.
Once everything is approved by engineering and product (on the backend) and design (on the front end), it’s time to deploy and make live for clients!
Keep scalability in mind
To design a scalable PDLC and SDLC, you need to make sure to keep a few things in mind.
It’s important to understand what the current state of the process is in order to identify any gaps. To do this, ask questions: What’s taking more time than we would expect or like? Are there areas where we are deploying too many resources? In a perfect world, what would this look like?
Your processes should also be easy to remember and follow. That helps reduce the potential for errors. When new people join the team, they can easily jump in and follow (and enhance) the processes in place.
Two additional ways to help with scale are software and clear documentation and checklists. These help to ensure the processes are easy to follow and all steps are straightforward. This kind of scalability allows new team members to jump in and get up to speed quickly, positioning your company for growth.