From ROM through SoW: The Importance of Communication During Product Development

Developing a new product is exciting — but risky. Especially when you need a partner with specific expertise to either augment your team or bring your idea from inside your head to out in the real world.

Over the last two decades, we’ve successfully completed more than 800 projects resulting in 200-plus commercialized products, establishing ourselves as a trustworthy leader in digital and physical product design and development. How did we earn that reputation? Through a unique fusion of product engineering expertise and proactive client communications.

Since it can be challenging to understand where to start, we’ve outlined the way we communicate during the product engineering process, from the initial call to putting together the rough order of magnitude estimate to delivering the statement of work.

Collaborating and Deep Engineering Expertise

Leveraging their engineering degrees, our Solutions Managers understand how different target technologies work and can discuss your project in depth, bridging your goals with technical needs. In fact, two of our Solutions Managers have Master’s degrees in engineering and one has taught engineering at the university level. Our Solutions Manager serves as your primary contact, understanding your needs and the target market, brainstorming and collaborating with your team, and facilitating your journey from end to end.

The Initial Call

During the initial discovery call, our solutions managers will ask probing questions to understand your product requirements, your market segment and end users. The goals of this initial discussion are to:

  1. Understand the market need for your product, what is required to design and develop it, and any schedule or budget constraints.
  2. Determine whether we are the right partner to help bring your project to life.

If we are indeed the right company for your project, we typically bring our senior engineering staff into the conversation to develop a greater understanding of what exactly needs to be done and what already exists. Through this follow-up meeting, we develop an initial estimate of the NRE (non-recurring engineering) cost of a project — a rough order of magnitude (ROM) — and sometimes the bill of materials (BOM).

product definition in the product engineering process

Calculating a ROM Estimate

A general estimate of a project’s level of effort and cost, ROM estimates generally serve as a go/no-go decision point before you invest too much time. Unless you have a large engineering team with a significant amount of previous electronic product development experience, it is difficult to put together a realistic ROM estimate on your own. Since we are an outsourced engineering firm, all we do is product development for customers, making our team uniquely qualified to quickly ballpark a project by comparing similar efforts we have completed in the past.

We generally don’t help with initial product ideation because we expect our customers to know their markets, what their brand is known for and what their customers want. We focus on technology implementation and leave initial ideation, sales and marketing up to you. However, we certainly comment on:

  • The best ways to implement features
  • Which technologies to use
  • Future expandability
  • Bill of materials (BOM)
  • Operational costs
  • Interesting markets where the product might have traction
  • Other groups to work with from a technical or market point of view

As mentioned above, a ROM estimate may inform you that your business model might not be profitable since the non-recurring engineering cost (NRE) won’t be recovered quickly enough. While this is unfortunate news, it is better than continuing to invest a lot of time and energy into an idea that simply doesn’t make economic sense. If your business model still makes sense, we’ll begin the dialogue on the features for your minimum viable product (MVP) that fits within your budget and schedule. By quickly understanding what drives the budget and schedule, we can collaborate with you to determine the right course of action and save time.

Think of Cardinal Peak as a chief technology officer-like guide, advising you through the early stages of product development by pointing out current design trends and state-of-the-art technologies to help refine your feature set. Our goal during this stage is to provide a rough estimate to serve as a starting point for moving forward with your project.

Developing the Statement of Work

At Cardinal Peak, we are 100% time and materials, so our statement of work (SoW) process is really a discovery and communication tool for both sides. When establishing the SoW, we aim to digest what you’re asking for and reiterate it back in terms of an engineering architecture and the tasks to implement it to ensure everyone is on the same page.

We don’t need a detailed requirements document. All we need is a basic marketing description of what the product needs to do. You can save a lot of time and effort by coming to us with whatever you have because we can jump in and do the rest.

What Does a Statement of Work Include?

To create an accurate estimate, it is necessary to break down the project into the component tasks so they can be estimated individually. To avoid misunderstandings, our easy-to-understand SoWs typically include the following information:

  • A short product description
  • A high-level architecture diagram
  • A list of risks
  • A list of assumptions
  • A list of tasks and deliverables
  • Budget and schedule milestones, which tend to be logical places for demos and integration tests
  • An appendix that shows our work, listing the individual tasks necessary to design and develop the product, with each task generally in the 1-3 person/day range

Additionally, quality assurance and testing are built into any SoW we deliver because for us to build any product — physical or digital — we need to be able to test it. If we can’t test it, we can’t say that it works. We have a robust QA team that comprises 15%-20% of our technical staff. As our QA team is deeply integrated into our development process and is well practiced with end-to-end system testing, we like to own end-to-end testing of the system (unless you have an equally experienced QA team).

Since all of the work that we do is unique, the SoW is a back-and-forth conversation in which prices (the labor estimate multiplied by the rate) change based on the understanding of the work and the features you decide to implement. We supply all of the SoW details so that you can recognize whether there are any tasks that your team has already completed or will be done internally — and whether we missed anything. A key piece to making any SoW work is a clear division of labor. It is in your best interest to make sure any gaps in our knowledge are discovered so that estimates and schedules will be as accurate as possible.

Compressing the Schedule

Every customer is looking to shorten their development schedule so they can launch the product and start making money or demo it at the big trade show in their industry.

At Cardinal Peak, we recognize that interdependencies between tasks expand the schedule. For example, embedded software development can’t begin until the hardware is ready, and the app developer can’t do anything because the cloud isn’t there yet. Interdependencies can lead to teams sitting idle. That’s why we uncouple these dependencies as much as possible by segmenting the project so all areas of development can progress in parallel instead of serially.

For example, if we are building an app that gets data from a cloud service that is going to be developed under the project, our first step is to define the interface between the app and cloud (the API). Then we’ll make a simple dummy cloud service to provide correctly formatted data when requested using the agreed-upon API. With the dummy cloud service providing responses to all the API queries, our app developers can work in parallel to the cloud team. When the actual cloud service is developed, we switch over. Similarly, for hardware projects, our embedded developers start development on a dev kit while the hardware is being developed.

Given there’s no schedule pressure, we will put the minimum number of people (based on unique skills) onto the project to efficiently use resources by minimizing the communications load. If you need to hit certain deadlines, like a trade show or shipping product for the holiday season, we double up engineers on the project where necessary.

product development tasks occur in parallel

Proof-of-Concept Projects

At Cardinal Peak, we like to estimate product development all the way to completion (i.e. ready for manufacturing transition), rather than focusing on intermediate goals such as a proof-of-concept or prototype.

By estimating the complete project all the way to the manufacturing release, you can start the project with the end in mind. If there isn’t a path to the end goal, then don’t start. Occasionally, there might be a need to de-risk a couple of items, or to demo a prototype at a trade show, but those milestones are just stepping stones in the overall project schedule. You can always elect to stop a development project at any time, but you don’t want to start investing in a proof-of-concept model without understanding what it will take to get the product to production.

We encourage the development of meaningful demos that fit in the overall project schedule. It is not uncommon for the marketing team to find features or functionality that they want to change when they — and their customers — get their hands on a working prototype. Regular demos help minimize any surprises.

Conclusion

At the end of the day, product development has challenges and presents risks. There are a lot of moving parts, and communication is key to ensure alignment and that nothing falls through the cracks. That’s why we’ve developed a proven process that we can tailor for your exact situation. Our estimating process is the fastest way for you to gain deep insights on cost and schedule to develop your product. Best of all, we do all of this free of charge.

From the initial call through the ROM to the SoW, the importance of communication in the product development process cannot be overstated. And if you’re curious about how we actually execute projects, check out this blog post highlighting our project execution process.

Our team possesses deep expertise in audio, video, voice, IoT, UX/UI, hardware, embedded, cloud, mobile and quality assurance, so if you’re looking for a product engineering partner that can take your project from your initial concept to the final market launch, connect with us!