6 Keys to a Successful Product Development Partnership

We’ve all been there or had nightmares about being there. It’s time for the unveiling of your product development team’s work. They’re practically glowing. They lift the metaphorical curtain and…it’s not at all what you were expecting.

The rhythm of product development has evolved, and success today relies on active partnerships with clearly defined goals. A partnership is no longer just handing off a set of requirements and picking up the results. Engineers and industrial designers work together in a collaborative partnership that involves an ongoing exchange of ideas coming from both sides.

Here are six tips for maximizing the probability that you will get what you expect from your product development service provider. Whether you’re focused on execution-oriented projects or a research-focused initiative, success for all parties is grounded in making sure everyone is on the same page at the start.

1.) Create Clear Requirements

Seems simple, right? You’d be surprised how rarely a product development partner starts with clarity around expressed (and implied) expectations. Whenever you engage with a product development consulting firm, clearly defined goals are crucial—even when the project is open-ended and research-oriented. Regardless of the type of project, it’s essential to establish parameters for expectations. Both you and your partner must understand those goals at the start to avoid confusion and conflict later.

Too often, I’ve seen product development experts called into meetings with prospective clients where the product development requirements are loosely defined. An experienced product development partner will encourage those clients to complete a brief and inexpensive “discovery” phase to gather baseline requirements. With those requirements in hand, clients are in a better position to seek competitive proposals and can be confident they are getting apples-to-apples responses for even comparison.

Investing upfront in the development of a comprehensive requirements document that defines project interim and exit characteristics is always money well spent. It will greatly reduce the probability of misalignment and dissatisfaction at the end.

2.) Check Qualifications

Product development projects require diverse skills to execute. Understanding which skills are key to your particular product and which you lack can help you choose the right partner. Perhaps your internal core competencies are in backend infrastructure, analytics, and mobile app development. If that’s the case, look for a partner who doesn’t duplicate those skills but has expertise and experience in microprocessors, energy management, RF or wired communications, sensing technology, mechanical design, and hardware industrial design.

Also look for partners who have all of the skills you want in-house. They will be more accountable and better able to execute the vision than a firm that assembles a team from several subcontractors. Those cobbled together teams often have problems “herding cats” because partners possess conflicting cultures and budgetary expectations.

Make sure your product development partner has sufficient bandwidth to handle a project of your scope and complexity. And find out who specifically will be the key team members assigned to your program. Watch out for the bait and switch in which you meet several individuals you expect to be on the team only to later find out the assigned team members are not the people you expected (nor of the expected caliber).

3.) Clarify Deliverables

Nearly as dangerous as sketchy requirements are loosely defined deliverables. Having a common understanding of deliverables is not just a measure to satisfy procurement teams. It is necessary to understand how your partner will demonstrate results.

Lack of agreement on deliverables from the outset of the relationship can be a big cause of dissatisfaction for both buyers and providers. It opens the door to debates over the quality and quantity of the deliverables.

Identifying quality standards for documents also is important to aligning your needs with the mission of your product development partner. This can be as simple as providing sample documents or, if available, formal internal or industrial/commercial standards.

4.) Be Open to Collaboration

Engineers and industrial designers today often work in agile ways, constantly exchanging ideas and fine-tuning plans and concepts based on feedback and new information. As a client, it’s your right and in your best interest to participate in the process as much as possible. Be sure to establish this as an expectation at the outset of the relationship to ensure you’re working with a firm that values and welcomes your input.

Your partner needs to build this into their project management planning. As a client, you need to be prepared for situations where changing requirements based on new or evolving information can lead to costly or time-consuming change requests. It is unfair to expect your partner to absorb the fiscal burden of changing requirements.

5.) Create Clear Expectations Around Acceptance Criteria

Misalignment over acceptance criteria is one of the most frequent and difficult issues. Are the quality expectations well understood by both sides? When someone says they are delivering sketches, do they have rough hand-drawn pictures in mind while you’re thinking nicely rendered computer-generated images? Is a proof-of-concept model something that demonstrates the functional properties of the idea, without regard for aesthetics or reliability of the functions, or are you imagining a fully functional and reliable prototype with appealing aesthetics?

There are no objective, standard definitions of the terms “proof-of-concept system,” “prototype,” or “model.” Make sure both client and product development partner align on expectations. Dialing them in too loosely may result in quicker delivery or lower cost, but it risks not meeting functional, aesthetic, or reliability goals. Dialing them in too tightly may result in a much greater level-of-effort around full development, test, and validation all with much higher costs and longer schedules. Nail these down in the sweet spot.

6.) Share a Clear Definition of “Complete”

This is often the most difficult issue because it typically comes up when the schedule is running out of time and the money is nearly exhausted.

It’s common to break larger programs into phases. Often, final or interim payments are contingent on certain work being “complete.” Both buyer and provider must have a common definition of what that means. A final review meeting that allows time for reviewing all deliverables—followed by a formal acceptance on the part of the client including, wherever possible, tested and validated quantitative results—is a good way to reach consensus on the completion of a phase.

From a service provider’s viewpoint, this is when they can safely provide a final phase invoice. From a client standpoint, the review summarizes each phase and provides confidence that all the commitments have been satisfied.

If you’ve provided for these six items, you’ll be ready to hold your service partners accountable for meeting their commitments. With a clear definition of requirements and acceptance criteria, you have a rationale upon which to accept or reject the work of your product development partner. By following these tips, you’ll put yourself in a strong position for successful product development partnership—and the creation of a successful product.

Mitch Maiman is the President and Cofounder of Intelligent Product Solutions (IPS). He honed his deep knowledge of product design on the strength of a 30-year career with companies that manufacture commercially successful products for the consumer, industrial, and DoD markets. Prior to launching IPS, Mitch was VP of Engineering at Symbol Technologies.  He can be reached at [email protected].

Related articles:

5 Lessons Startups Can Learn from Big Companies

Starting a Services Company: 5 More Tips for Ongoing Success

What to Consider When Starting a Services Company

[main image source: Pixabay]