Whether developing a new product or improving an existing one, the product development process has risks. Every product development project faces unique challenges and requires a proven process to minimize risks and raise areas of concern quickly to the team. When a bump in the road is encountered, it is important to communicate the options clearly before the budget is significantly impacted.
At Cardinal Peak, we understand the risks and have developed a product development process that has enabled us to successfully complete more than 1,000 projects resulting in 200-plus commercialized products. By meeting clients at their point of need, working with existing teams and vendors, and supporting every aspect of the product engineering process, we’ve earned the reputation of a trusted leader in digital and physical product design and development.
Because taking a product from initial concept to market launch can be daunting, this informative post will walk you through the project execution portion of the Cardinal Peak product development process. Check out this blog if you’re curious about our process from the initial call to delivering the statement of work (SoW).
Contents
Treat Customers as Partners in Product Development
Most of the projects that we execute involve collaboration between our internal development team and our customer’s team. While we can absolutely develop a product from end to end, it is more common that our customer executes some pieces of the project. The majority of our partners have very capable engineering teams, but they often lack specific skill sets (generally surrounding newer technologies) or enough engineers to meet the schedule.
We recommend focusing your internal efforts on your secret sauce and outsourcing the less differentiated — or perhaps the nonsteady — work. For service delivery, outsourcing sections of the design is generally better than staff augmentation since it allows our team to take full responsibility for the design and testing, which offloads your management team.
Cardinal Peak is big enough that we have a repeatable and established process including:
- Breaking down and assigning weekly tasks
- Running QA acceptance tests
- Documenting work and communicating with our customers
We are also able to accommodate any specific design processes our partners want us to plug into. This means that we’re more organized than smaller design firms with their informal processes and more flexible than massive product development corporations.
An example where you would want us to adapt to your process is if you have a quality management system (QMS) because you operate in a highly regulated industry. You’ll want your product development partner to design your product using your processes and complete all the supporting documentation to pass regulatory hurdles without adding a substantial amount of work to your plate.
Product Development: The Cardinal Peak Way
We kick off the product development process on day one by loading all of the individual tasks (stories — typically 1-3 days engineer-days of effort) estimated in the SoW into Atlassian’s Jira, a well-known agile project management tool. That Jira instance is then shared with you and is one of the deliverables at the end of the project.
For execution, these individual stories are prioritized and executed in sprints. A sprint is the repeatable schedule block that makes up a project. Typically, we use two-week sprints, but that can vary.
All work is tracked in Jira, giving you complete visibility into each project — all the way down to an engineer’s daily tasks — every deliverable and a ticket-by-ticket history.
Your Product Development Partner’s Sprint Cycle
First, the Cardinal Peak project manager in charge of your project collaborates with a point of contact (PoC) at your organization to prioritize any tasks that are in the Jira backlog, which typically involves minimal fine-tuning since this was done two weeks earlier. Tuning accommodates requests to add new features or implement specific features a little earlier to support a demo — and we need to remain aware of the current priorities.
Then, the project team comes together in the sprint planning meeting to assign tasks in the backlog to team members. These tasks typically have some estimate from the SoW, which is discussed during the planning meeting to ensure alignment and that there isn’t any misunderstanding about the specific feature being developed. Tasks are assigned until each team member’s plate is full for the sprint.
An engineer generally works on one story (or ticket) at a time. We usually apply engineers in whole number values to projects, so it is rare for an engineer to work on multiple projects at the same time because we believe task switching is inefficient. Once a ticket is complete, the developer assigns it to QA for testing and moves on to their next ticket. The QA tester is the only person that can close a ticket. When a ticket is assigned to QA, a tester tests that feature, and if it passes, then they close it. Otherwise, the QA tester will add notes about the defect and how to recreate it in the Jira story, then assign the ticket back to the developer.
At the end of every sprint, our QA team executes limited regression testing to verify that no functionality broke when the development team added new features. Sprint-based regression testing generally involves a subset of all features as testing everything every time is expensive. Some tests are automated and can be rerun frequently. Automated tests are especially valuable for tests that will be repeated many times and repeated after the product is launched whenever new features are added. While automated tests cost more to develop initially, they can reduce the overall QA testing investment and save money in the long run. Any defects discovered in regression testing are added to Jira, and the original ticket is reopened (where possible) so that the entire history of the feature is collected.
Project Reporting
When each sprint concludes, your project manager prepares two different reports. One report is a technical status report (a handful of slides) that is reviewed with the client’s engineering team in a half-hour call. The other report is a one-page summary of the project status, which we send to our point of contact and their executive management team. During the hundreds of successful projects we’ve managed, we’ve found that there can be disconnects in our client’s reporting chain and that the longer a challenge goes unrecognized by senior management, the bigger the pain will be. That’s why we send the report to both our customer partner’s PoC and the leadership team.
Our summary reports are limited to one page so that they are more easily consumable and significant problems don’t go unnoticed because they were buried in 30 pages of technical detail. Since we regularly communicate with our PoC and have regular half-hour engineering meetings with the client’s engineering team, they already know the details of any issues.
All code is always stored in a repository to which the customer has access. We also encourage our customers to run each subsequent (more fully featured) build from each sprint. While not required, this lets the customer see whether the system is meeting expectations and whether they want to fine-tune certain aspects of operation after gaining some hands-on experience. From there, the sprint cycle repeats until the product is ready for launch, but there is occasionally a “quality sprint” in which no new features are added, but defects are tackled to make sure the product is ready for a demo or launch.
In a perfect world, we try to execute features end to end in a given sprint, implementing one in the firmware, the cloud and a mobile app in the same sprint so that it can be end-to-end tested by QA and the customer. While that is our goal, it doesn’t always work that way.
We recognize that projects don’t suddenly go off the rails in the days leading up to launch — they slowly fall behind. Testing as we go allows you to feel confident that the work completed is completed at production level so that you can really know where we are in terms of accomplishments and budget. We want to identify any issues as early as possible so they can be discussed — and fixed — before they become bigger problems. There are risks with any product development efforts, but we don’t want to magnify those issues with poor reporting and communication.
Quality Assurance
At Cardinal Peak, we engineer quality testing into each step of the engineering process so that each feature is tested as it is developed. As noted, at the end of each sprint, some level of regression testing is done, and a higher level of regression testing is completed at major milestones. Even if your team is responsible for some portion of the work, we prefer to own end-to-end testing because end-to-end full integration testing is critical.
Looking at a typical IoT project, for example, no single part of the project is impossibly hard, but there are many different interfaces and protocols used. Everywhere data is transferred is a location where it can fall through the cracks. Without a talented QA group, it is not possible to achieve the level of quality necessary in today’s review-centric world.
Quality assurance requires constant assessment to ensure every feature works as expected and that when new elements are added, the product doesn’t break. By detecting defects or unmet requirements early on, we can rework the product, ensuring the release of a higher-quality product in the end.
Conclusion
We get it. Product development is inherently challenging. With so many moving, interrelated elements, each project requires a proven process that prioritizes you as a product development partner. Working together with your product development company helps ensure both parties are aligned and that nothing slips through the cracks.
Our product development process treats each customer as the partner they truly are. At the end of the day, your reputation is on the line, and we want to do everything we can to support you in launching quality products that work as designed. From the sprint cycle to reporting and quality assurance, the way we execute product development empowers you with a partner capable of delivering innovative, fully tested, market-ready solutions that meet your project’s unique needs.
Whether your project requires expertise in audio, video, voice, IoT, UX/UI, hardware, embedded, cloud, mobile or quality assurance, we are the product engineering partner that can take your project from your initial concept to the final market launch. Kick off your project and meet your Cardinal Peak solutions manager today!