Truth to Power: Building Solid Relationships with Product Development Partners

Truth to Power: Building Solid Relationships with Product Development Partners

Increasingly, companies are relying on developer partners to extend their value. Relying on partners has its risks, but finding a trusted partner has large benefits. Building the kind of “partner” relationship that makes the leap of repeated usage and reliance, requires strong communication, trust and agreed upon verification or checkpoints. Realizing the total value of this engagement requires the trust to avoid duplicate efforts and personnel. That is why building solid client/developer teams and relationships should be a key strategic priority.

For clients in the medical device industry, revenue projections drive development programs, often with few contingencies built in. More than ever before, medical device manufacturers face intense pressure to realize development goals and have less patience for projects that fall behind schedule. So as development teams race toward production, the overall goal is to deliver.

To build strong relationships in this environment, the best teams have two important characteristics:

• Optimized communications. This means handling communications at differing levels, from day-to-day updates to news of potential challenges that may arise, in a manner that not only helps manage overall expectations, but also engenders mutual respect and a deeper loyalty over the long-term.

• The ability to exercise good judgment. This means identifying challenges early and offering thoughtful mitigating options—not acting with alarmist overreaction. The ability to make these assertions comes from experience and the recognition to know what you don’t know—and then bring in the appropriate persons who do. It’s also about leaving biases out, reasoning around the pros and cons, considering possible consequences, and then having the integrity and courage to move ahead with your decision.

Starting with a Plan

Many in medical device development know that having the appropriate level of communication in a program requires an overall plan—one that balances realism with the right amount of risk and needed timing. It is the roadmap, and developers and clients must be in alignment on it. A good plan has both standard touch points—at the end of each development phase and at each design review—as well as customized touch points to fit the unique program and client.

Layering in Solid Communication

Making progress toward success involves balancing rigor and flexibility while operating with a sense of urgency. Throughout development, clients must be an integral part of the process with ongoing, multifaceted collaboration.

Tools that can aid in this collaboration can include:

• Weekly project updates via telephone or face-to-face with reports on progress and frank discussions on potential risks and their implications.

• A program dashboard, which is an all-in-one-view status report that provides information on progress, challenges, budgets, etc. Clients should have that level of granularity whenever they want it. For instance, they should be able to see their spending so they can ratchet it up or down when necessary.

• Visual views into the program’s progress, providing storyboards, presentations, illustrations, video, mapping, and other tools. This all enables clients to discuss and update others on their team, including senior leadership, about the program.

These steps all help teams avoid the unexpected. Moving in lockstep ensures everyone understands each others’ expectations. And when properly done, there should be few late surprises.

Embracing Critical Conversations

Despite these efforts, at some point developers are bound to experience points of misalignment. Client/developer teams should never postpone critical conversations when this occurs, but instead take the opportunity for a moment of pause. It’s not a time to overreact, jump to conclusions, or act on emotion, but one for a proactive fact-based evaluation. These are times where development teams must re-assess the direction, ensuring transparency with customers.

Some common catalysts leading to the pause include:

• Changes to product specifications, such that the program no longer fits the original project scope. This may include something major or even an aggregate of smaller changes that are leading to larger deviations in assumptions. Even when rushing toward development completion, it is better to pause briefly to reset the project and ensure optimal direction.

• Issues that may expose a client’s business or patients to excessive risk. In this business, there’s always going to be some risk, but we must ensure that the clients are aware of that risk and its potential consequences.

• Decisions that should be made early on. For example, patent work should be completed at the front end of a project. Discovering an infringement too late in development could jeopardize direction, which always is more expensive later on.

• Price points that aren’t adding up. If there are no prompts with cost questions, the team may get off track to the point where they’re developing a product without a worthy return on investment. Those questions need to be asked all along the way. It’s about reminding everyone: “Are we on the right track at this price point?”

These are all misalignments that a good development partner will catch. Identifying and informing a client about the unexpected, and then working through it, takes essential communication skills. So what should a client expect when initiating this sort of discussion?

We’ve Got Your Back

If the client/developer team has been communicating thoroughly, it will serve everyone well right about now—since the team only needs to address the issue at hand and not a deluge of issues. Still, the way difficult conversations are handled significantly can affect not only this program, but also the ongoing relationship. So everyone needs to know that we are pausing in the best interest of the program.

Some items to consider in preparation for and during the discussion:

1. The developer should take a little time to prepare for the conversation—but not much. If it’s a complicated problem, the developer should at least call to inform the client about the issue, the immediate plan, and a date to get back to him or her with more details. In any case, there should be preparation for the conversation by getting with the team to understand the issues, the causes, and most important, the solutions and the subsequent options to minimize impact.

2. Teams need to be open, honest, and declarative about the problem. In their book, “Crucial Conversations,” authors Patterson, Grenny, McMillan and Switzler, say, “the one thing at the core of every successful conversation lies the free flow of relevant information.”1 Honest dialogue will be appreciated and lead to better, stronger relationships over the long-term.

3. The right people need to be in the room. In some instances, this may mean senior leadership; in others, it may be principal engineers.

4. Everyone should quantify issues in terms of cost, time, and risk. Teams want to make the right decision. Making the right decision sometimes requires quantified information (i.e., “We would like to take two weeks right now and investigate this before moving forward,” “The risk is 10 percent that …,” “The risk is 90 percent that …”).

5. There should be solutions and options. This eliminates guesswork, maintains a sense of control around the issue, and makes it easier for teams to sleep at night until the problem is fully resolved.

After this information is conveyed, everyone should go back to the plan to recalibrate, building in more touch points if necessary until everything is back on an even keel.

Those who do this—and do it well—will tell you that it involves building trust, managing expectations, and navigating routine and critical conversations. These are the elements of engagement. Maintaining a high level of engagement keeps expectations on both sides aligned. Meeting and exceeding expectations around budgets, schedules, and innovation is what makes everyone happy. And happy relationships are strong relationships.

Reference:

1. Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler. Crucial Conversations. New York: McGraw-Hill, 2002.

As vice president of Program Management and Engineering, Michael Pereira leads Ximedica’s team of program management professionals who are charged with the development and launch of new devices from many of the world’s leading medical device manufacturers. His engineering background spans more than 20 years in product development and design for manufacture, encompassing dozens of Class I, II and III devices. Michael holds a bachelor of science degree in mechanical engineering from Worcester Polytechnic Institute and a master of science degree in mechanical engineering from Northeastern University. Ximedica is based in Providence, R.I.