The Keys to Successfully Outsourcing Product Development

Tyler Kern: [00:00:00] Welcome under the sunrise podcast, powered by sunrise labs. 

Welcome to this episode of the sunrise podcast. I’m your host Tyler Kern on the podcast today. We’re going to be discussing outsourcing product development and the potential pitfalls, and also the keys to doing it effectively. And joining me to talk about this is Lauren Noel, the VP of business development at sunrise labs.

Lauren, thank you so much for joining me today. 

Laurin Noel: [00:00:26] My pleasure, Tyler. Thanks for having me on. Absolutely. 

Tyler Kern: [00:00:29] Absolutely. So after 27 years of being in business and hundreds and hundreds of projects delivered, sunrise has a lot of experience in this area. Right? So w with that, I’m sure comes some wisdom on best practices.

Is that right?

Laurin Noel: [00:00:40] Absolutely. Um, I think one of the things that we really pride ourselves on as an organization is, uh, continuous improvement. And so we really take that to heart it’s of course, part of what comes with the ISO certification that we. Work under, which is the ISO 1345 important really for medical product development.

But as part of that really continuous improvement. So always looking at what are we doing in the way we work with clients? How can we do that work more efficiently, more effectively? Are there things that we need to think about to make sure we’re delivering. The best services we can to meet our client needs.

Tyler Kern: [00:01:20] Yeah, absolutely. And when we talk about kind of delivering that exceptional service, delivering the right product for what your, your customers want. I mean, I would imagine that I’m getting off on the right foot and having everyone on the same page is huge to the success of a project overall. So what are those initial conversations and communications look like when you first receive a new project?

And you’re trying to get off on that, right. 

Laurin Noel: [00:01:40] Yeah, that’s a great question, Tyler, because it’s something we talk about a lot here at sunrise. I think there’s a couple of things that we look at. One of them certainly is trying to look at the nature of the project and make sure the. Process that we’re thinking about for product development is a good fit.

There’s a wide variety of projects that we see here in terms of the technical challenges, as well as the business challenges that our clients are trying to meet. So we look at, for instance, is it a program with a fairly well understood technology? Fairly well understood path to get from. The entry point to the completed product, whatever that may mean for the client in that case, um, a traditional waterfall type product development process probably is a good choice.

We, however, see quite a few programs come in where there’s. A lot of TBDs things, really still needing to be understood. Things need needing to be better, defined to be able to lay a solid foundation, to build the product development program around in those types of projects. We most typically would recommend, um, a much more agile iterative type of approach to the clients for how we’d like to manage their projects.

There’s certainly pros and cons to both of those, but I think that’s a key difference in terms of thinking about the nature of the project, what you’re trying to achieve again on the project. Both in the technology and the business and think about what really will work best to meet those project needs.

Tyler Kern: [00:03:28] Yeah. Yeah. That’s a great point. And I think kind of, just as you’re saying that what came up in my mind was that I’m sure on some level, every project is slightly different. Right. So how do you approach each project as its own unique thing while also not reinventing the wheel every time? If that makes sense.

Laurin Noel: [00:03:41] Absolutely. Yeah, because of the number of projects that we’ve done through the years is there’s a lot of both knowledge that our team has. Developed around developing medical products in general, and then specifically a lot of the. Um, challenges of particular segments where we specialize, for instance, in cardiovascular, uh, robotic surgeries is a lot of areas of specialization that our team has very deep experience.

And I think that being able to leverage some of that experience is always interesting to our clients and valuable to the program to be able to help reduce risk. Because anytime that you’re starting with something that’s. Reasonably well understood or, um, perhaps even developed and tested as a module or an aspect of a program that reduces program risk.

And anytime you reduce program risk, you’re also reducing schedule and budget risks. So those, those are the kinds of things clients like to hear. And one of the things that I think we really bring to product development because of the years of experience that the company has. Um, been doing product development, as well as the breadth and depth of the engineering capabilities on our team here at sunrise.

Um, Really we have, um, a very experienced team. And I think it’s really looking at the, um, makeup of the team that you need to apply to a project. And whether it’s sunrise or another design firm, I mean, this, this, a lot of these principles certainly apply. Um, as product development in general, across many different types of projects, but also working with many different design firms.

I think those principles still hold true. That’s a great point. What you mentioned there about team members, because having the right team, having the right members of a team really makes a huge difference as well. Right? So, so it’s, it’s important to make sure that you have those team members that can carry out a project.

Tyler Kern: [00:05:41] So those years of experience, when it comes to the engineering and the things that you need to really completely fulfill what a client is looking for. 

Laurin Noel: [00:05:48] Right. There’s um, one thing that we’ve seen in some projects in a, uh, a tip I’d also like to share with the audience is around the nature of the project.

We talked about, um, projects that are pretty well-defined versus those with a lot of TBDs. The other aspect of that is the nature of the. Engagement that a client might be considering. We see many cases where the client has a lot of in-house resources to bring, to bear to a program. So they’re not necessarily looking to outsource source the complete development effort, but they’re looking for a partner who can really bolster those areas of either technical knowledge or experience that they may not have, or maybe.

Shorthanded on internally. So what we’ve send that sometimes seen is in those cases where there’s going to be a division of responsibility and shared responsibility, really in executing on that product development program is looking to understand who at the client company. Would be tasked with coordinating that effort.

Um, we like to think of that individual most typically as a system engineer, um, and in that system engineering role, really having somebody who’s both technical and I was seniority and experience level that they’re in a position to help drive and make those trade-off decisions between different modules or different aspects of the program.

Um, as they come together because there’s ultimately going to always be trade-offs in those product development programs. So having that technical resource on the client’s side in those situations is really critical. Um, certainly we can apply system engineering to a program, um, and, and that often works best when we’re also responsible for the overall program development.

But again, it’s a point to really just. Look at who that individual is, whether they’re on the client side or the design outsource design team side, and understand really the roles and responsibilities. Well, as you really start to think about the program. 

Tyler Kern: [00:08:05] Yeah, absolutely. As you’re talking about that, it strikes me just that that communication and collaboration is really, really important.

Just having that, that person and having that relationship with them to be able to go back and forth on a project. And it feels like, you know, Um, communication is obviously so vital, but not all communication is created equal, right? There’s communication. That’s obviously going to be better than others.

So what makes a positive communication between two groups that are trying to collaborate on a project rather than just noise? What is effective communication, I suppose is really the heart of my question. 

Laurin Noel: [00:08:36] Oh, yeah, no communication is so key. That’s, that’s something we talk about a lot here. Um, I think it really starts with setting expectations.

We talked a little bit about expectations, but one of the ways that we try to capture those expectations at sunrise and to make sure that everybody is. On the same page with regard to roles and responsibilities, as you start a program is using something called the RACI model, which is a method to really identify.

Roles and responsibilities. And you can do that down a full task list to identify who’s going to need to be informed of decisions. Who’s really responsible for those decisions who might be consulted on those decisions and who needs to approve those decisions. Um, not necessarily in those orders, but those, those, um, those are really what make up a racing model and going through that whole process of, um, defining.

Who’s really responsible for those different aspects, I think is important for the program from the beginning. And then revisiting that, you know, really not just saying, okay know, that’s it. And we move forward. I think just doing a little bit of a check on that through the course of a program, um, making sure that nothing has changed in terms of how the work is being done and.

And the other big thing there is certainly, um, trying to make sure from an early stage of the program that you understand who the key stakeholders are. In the program. Um, there’s often many different voices that influence, um, a product through its life cycle. So certainly understanding again, um, you know, from the marketing perspective, the technical team, the manufacturing team, um, the sales team in terms of that field experience.

And certainly of course, the executive team in a company. Because there’s often done in sometimes conflicting, um, interest across those, um, individuals. So really making sure you understand it at an early stage of the program who those stakeholders are, what’s important to them and really trying to balance what sometimes can be conflicting needs or expectations.

Um, and then, you know, the other thing about effective communication that we talk about a lot here is. Um, utilizing what we call in, which again is known. And this is something that has been written about is assumption of positive intent and assumption of positive intent is really a way of thinking and something that we practice here at sunrise.

And I say practice because it takes work, it takes reminding yourself, um, that you need to approach a prod of a problem or an issue with an assumption of positive intent. And it basically is. Seeing an issue that perhaps you don’t understand why someone has taken actions or you really are struggling to imagine why the decision that was made is the right decision.

It’s about going to that individual that is making that statement or making that decision with an assumption of positive intent, which means that you approach it. Expecting that they did. So for the right reasons and with good rationale. And so really approaching it that way and asking them about what that decision process was.

It keeps the communication. Really at a much more positive interaction and level in and helps to really in our experience reduce conflicts and defensiveness, which can occur. And in situations where people have different viewpoints by really opening up a conversation about. And understanding of the process.

It sounding may have made a decision on which perhaps you don’t agree with at the outset, but hopefully you may, um, align through those conversations. Actually, our president talks a lot about, um, An individual he knows and holds the highest steams and has that individual on his wrist has tattooed, um, the words I may be wrong because I think again, it’s keeping that open mind, not approaching a situation, thinking you’re right.

And your way is the only way, but. Having that open mind is really important for how we work here. 

Tyler Kern: [00:13:14] Yeah. Yeah. That’s a great point. And I’m really glad you brought that up actually, because I, uh, I did a podcast with your president, Eric Soderbergh, uh, back, I think in the spring where we just talked about the company culture.

Yeah. There at sunrise labs. And it’s fantastic to see that that’s not just an internal thing, but that also shapes and guides and directs how you interact with outside clients as well. Um, , I guess it’s a 360 degree view of how to do business and how to treat others. It’s just that it’s assumption of positive intent, like you mentioned, and that’s really, really good to hear.

Laurin Noel: [00:13:43] Yeah. And it’s interesting because it does also tie very directly into the whole product development process. So for instance, um, we had a situation where a client, you know, very big company. Medical device company, very, very knowledgeable and experienced team had done some great work. They’d set the requirements for the product.

They had developed an architecture, they had selected certain technology choices and they asked us to come in and review those choices. So in looking at those areas that we would have done differently. And it was interesting because. Here’s a client that has done great work and asking us to review this information by frankly, I think not necessarily expecting that we would disagree with the choices they made, but I think it was through some really interesting dialogue in meetings to say, we want to understand why you were thinking about that particular software architecture or those particular technology choices that you have chosen.

And through that discussion, gaining their perspective. And then also being able to share with them here are some things we would suggest you consider because our team has done so much work with such a wide range of technologies for so many years that our exposure is much broader than. Often many of our clients who, again, you know, very bright, very knowledgeable about product development and very knowledgeable about their products, but they just don’t have necessarily the same experience to stay up to date with emerging and evolving technologies and specifically.

Not having that hands-on experience on working with some of those different technologies, which, um, has been helpful, but you know, it’s really approaching even those situations with an assumption that there were good reasons they chose those choices. Let’s talk about those and then share some thoughts and see if.

There’s other things that might be worth considering. Yeah. Yeah. 

Tyler Kern: [00:15:59] I really like that approach. And I think that that’s, um, that that’s absolutely fantastic. So one of the things that, uh, I’m wondering now, so if a company is listening to this and they are thinking through, okay, should we work with an outside team on product development or not?

What are some of the benefits to working with an outside team, uh, when it comes to product development? Can you walk me through? 

Laurin Noel: [00:16:19] Sure. Yeah, I think that, um, One of the key things certainly is the opportunity to take advantage of knowledge that your in-house team may not have. And also potentially too often to accelerate schedules.

Um, our clients, for instance, we had done a lot of work these days. Wireless connectivity, a lot of Bluetooth, Bluetooth, low energy based wireless designs and on the surface, um, I think everybody’s saying so. Yeah. You know, you just buy a Bluetooth module and drop that in, but in fact is a tremendous amount.

To that in terms of the requirements, um, in terms of Bluetooth technology implementation and design, and having had that experience, um, I think that’s an area we would help accelerate. Working with clients and collaboration, if they have that as part of their design, as well as you know, that certain expense extends across many other areas, motors, motor controls, um, miniaturization.

There’s a lot of hot topic areas that, um, clients often are really looking for. Somebody that’s been there, done that had that experience to be able to help accelerate their program. Um, you know, th the one thing that we really caution. Um, potential clients and clients is to not, um, necessarily, and hopefully to not come in with the idea that they’re just gonna be able to put that whole project on our plate and walk away.

Um, you know, most clients do, but I’m surprised that sometimes there are clients that. You know, they’re, they’re considering outsourcing for a pretty common reason. They’re way too busy. They can’t get to this themselves, but yet it’s a really important program, but too often, um, they don’t think about allocating some time to be able to support their outside team, a team like sunrise, and that can lead to, um, delays, which again can impact those schedule and budget.

So I think that’s one of the things that clients should consider if they’re considering outsourcing, um, to make sure they do have some bandwidth enough of the right bandwidth, relative to what they’re trying to outsource to make sure they can keep their outsource. Partner effective and working efficiently.

Tyler Kern: [00:18:50] Yeah. 

That’s a good word of, uh, I guess caution almost, just so that people are aware of that, that, that is the case, right. That there is going to be time that needs to be dedicated to making sure that the project is going to the way that they would like for it to go. Right. And so I think that that’s a good word of caution.

Are there any other potential pitfalls that you’ve experienced that you’ve seen over the years? Uh, that people should be aware of when they enter into a, a, you know, an outside, uh, product development team, uh, relationship. Are there any of those other pitfalls that people should be aware of or look out for? 

Laurin Noel: [00:19:21] There are. I think one of the things we hear about a lot, and I think, frankly, I think a lot of clients are getting more and more savvy about outsourcing and I’m happy for that because I see more and more clients asking some of these really important questions. Um, And if they’re not asking these questions, I try to encourage them to think about them as part of the process of looking at outsourcing and the type of partner that they choose.

But, you know, what is the makeup of the team that will actually work on your project? I think certainly it’s hard for a company like sunrise to. Necessarily guarantee from an early stage. I mean, clients will come to us and say, if I do this project in six months, who’s, who’s going to be the team that you’ll put on it.

Well, no luck can change in six months, um, where we’re lucky to have very low turnover. So likely all the same people will be here, but it’s, it’s a matter of matching up the right team to the project and looking at that relative to their schedule, but really understanding who those team members are and who is.

Likely to be at least the key team members that will be assigned to your team that, that I think is really important. Um, and then also understanding, um, how project is being estimated. Um, and I think that our team tends to put a lot of work and a lot of thought into. Developing an estimate for a project and, um, tend to be fairly comprehensive and thorough in terms of how we think about product development.

And unfortunately we’ve seen cases where, uh, mother firms just really don’t understand what will be needed for, um, aspects of the design. For instance, everything from very early. Um, gaining the appropriate user inputs through the whole process of verifying, um, and validation of software and other design aspects.

And we really encourage clients to try to think about that product development in a pretty holistic way. Again, whether or not we’re personally responsible for it. I think it’s important that they. Try to have a reasonable understanding of what it’s really going to take. Um, uh, certainly most of the large medical product companies that we work with have a good sense of that.

They’ve developed a lot of products. It’s um, some of the startup companies that we, um, we talked to and we really try to educate because we really don’t want to see somebody just spending money on something that they can’t develop and fund. Based on, you know, unfortunately, sometimes they mistake and expectation of the money it will take to.

So, so I think, you know, trying to share that realistic expectation of what it’s going to take for product development and then also, uh, you know, manufacturing, manufacturing, ramp, and marketing. I think sometimes companies, particularly startups get really excited about the product development, but they don’t necessarily think through the whole process of, okay, so.

Um, you know, what’s my sales and distribution channel. And hopefully they’ve thought before, you know, at the very earliest stages of product development, who’s going to buy this, what are they going to pay for it? Um, and what’s important to those potential customers because that, that again is part for us part of the foundation, but I’m sometimes surprised at some of the products and projects that I see that.

It seems that really haven’t given enough attention to those kinds of questions until quite late in the development project. Um, and as I’d mentioned earlier, the later you start to think about those things and perhaps need to change course because of new information, the more impactful those changes will be to project costs time and, and potentially features, you know, if, uh, The client has been working on a program that, um, they need to change course midstream sometimes.

Unfortunately it’s a matter of having to cut back on features to be able to still. Get to market with a less fully functional project because they hadn’t put the time in upfront to really understand the priorities and what it’s going to take to get through that. 

Tyler Kern: [00:23:49] Wow, that makes a lot of sense. And, uh, boy, this podcast has just a lot of experience and a lot of wisdom behind it when it comes to outsourcing product development.

So Lauren Noel, VP of business development at sunrise labs. Thank you so much for joining me today. Here on the sunrise podcast and sharing, sharing a little bit more. 

Laurin Noel: [00:24:05] My great pleasure, Tyler. Thank you so much for having me and for the insightful questions 

and thank you everybody so much for listening to this episode of the podcast.

Be sure to go subscribe on iTunes or Spotify to get the latest episodes downloaded directly to your device. And we’re going to be back soon with another episode of the sun rise podcast, but until then I’ve been your host. Tyler cur. Thank you so much for listening. .