Editors Note: This episode, Enabling Product Development Success with Josh Turpen, is part of the Innovation in Compliance podcast series and originally ran on The Compliance Network. Below you can find the recording and an abbreviated transcript of the podcast.
Tom Fox: Hello, everyone, this is Tom Fox back for another episode and today, I have with me, Josh Turpen. Josh is with Jama Software, and he’s going to talk to us about the solution the company has developed and compliance from a little different perspective than we typically hear, but I think it’s going to resonate with my listeners, our listeners. They’re going to be your listeners as well.
Tom Fox: So with that incredibly long-winded introduction, first of all, Josh, welcome, and thank you so much for taking the time to visit with me today.
Josh Turpen: Thank you, Tom. I very much appreciate you inviting me on.
Tom Fox: Josh, could you give us a little bit about your professional background?
Josh Turpen: Sure. My name’s Josh Turpen. I’m the Chief Product Officer here at Jama Software. I’ve been at Jama for about a year now, actually a year tomorrow, as a matter of fact.
My background is in enterprise software development. I’ve done that for a number of years, most recently at Cherwell software, led teams all over the world, Scotland, the US, Europe, Asia, pretty much everywhere where you can have development teams. Kind of much further back in my background and one of the things that really attracted me to Jama was my work in the Department of Defense and very heavily, both regulated and safety critical set of work that really, very early on in my career, made me understand and really drove home the importance of good requirements, good testing, and being able to wrap all that together.
Medical Device Risk Management
Tom Fox: I’d like to turn to medical device risk management. And many of my listeners come from a world where risk management is second nature, at least the phrase. They understand the risk management process, but you guys have, I think, a really unique way to help a company with that. So I was wondering if you could maybe introduce that topic, and we’ll go from there.
Josh Turpen: Sure. So one of the things that we look at when we’re working with a customer is, obviously, we work across a lot of different industries and bringing that expertise of what we learn across those industries to bear on… silly kind of example, but what we learned out of automotive, bringing that to medical device, what we learned on a medical device, bringing that to semi-conductor helps us give our customers a pretty well-rounded and a larger view on risk.
And one of the things that I think we do a good job with is making sure that we’re tying risk back to very discreet product requirements and tests so that we can validate, “This is what we said we were going to do. This is what the testing showed. These are gaps in there. And then, what are the risks that we need to resolve? What do we need to keep an eye on?” And then thinking about just the product development life cycle. When you change something, how does that impact both your requirement, your test, and your risk. So I think what we do is tie all that together to give a really good visibility to our customers.
RELATED: 3 Ways Products Became More Complex in the Last Five Years
Product Development Success Can’t Happen Without Proper Risk Management
Tom Fox: Josh, we’re going to move into advanced compliance and geek speak here. I’m not going to pass up the opportunity to talk with someone like yourself on the-
Josh Turpen: Be easy on me, Tom. I’m an engineer, so…
Tom Fox: … you talk about the risk management process, and you talk about how you have to continually evaluate risk because risk can change. So for instance, I think you gave you the example of a product update. Can risk change from the external environment as in the time we’re in now when we’re recording this in mid-August, from what a company’s risk was six months ago or nine months ago before COVID-19 health crisis, to the point we are now. Perhaps moving into 2021, it seems to me that the risk parameters may have changed, and it would really call for the need for another risk assessment to see if risks have either gone up or down.
Josh Turpen: I think that’s an excellent point, Tom. I think what we’re seeing right now is the rapid iteration of use cases in the market. You’re seeing it with drugs, you’re seeing it with medical devices, and you’re just seeing it with different environments that people are in. Things that you might’ve done in a in-patient, you might be doing outpatient. So I think, overall, re-evaluating risk with external events in mind is a good practice. And you’ve got to have a system that enables that because if you’re constantly re-evaluating risk in a manual or laborious process, you’re not going to do it. You’re going to end up punting.
Tom Fox: And that really brings me to the next point I wanted to visit with you about which is the problem or at least the differences between document-based solutions versus item-based, and I know you advocate item-based. So could you spend a little bit of time explaining that to the audience, how someone would think through it because it may be a very unique way for many compliance practitioners in my compliance space to think about this solution.
Josh Turpen: For sure. And it was unique to me when I came to Jama. I was born and bred in the old way of doing this where documents were passed back and forth. That eventually moved to Word and Excel and those kinds of things and even with some systems, but the basic difference is that instead of having a monolithic document that is the requirements, we look at requirements as discrete items that can be revved, can be commented on, can be tested against, can be evaluated from a risk perspective. And each one of those can be independent. And what that allows for is more focus. You can scope your reviews, both from a risk test and reviewer perspective, but it also gives you much more control over the relationship between entities in your system. So having a requirement with a set of tests associated with it, with a set of risks associated with it gives you that real easy traceability between one item tests and risks.
Collaboration is Key to Risk Management
Tom Fox: And how does Jama Connect help put this risk management plan into action?
Josh Turpen: Well, first off, it fosters the collaboration, I think, that’s necessary for good risk management. In a disconnected, distributed world, context is king. And we don’t have the ability to just run into somebody and strike up a conversation, so making sure that we’re capturing information in a low friction way is a big part of that. You would be amazed at the risks that we see identified just out of comments and conversations that are happening during reviews or discussions about items. So I think that’s one way that we do things a little bit differently and one of the benefits, like I said, of the item-based approach to risk management.
Tom Fox: Once again, because of the time we are in now and much of the work in every business is virtual now, I was wondering if you could share with us some thoughts on how you can optimize product development through team development. As an engineer, you probably deal with complexity a fair amount. Now we’ve added on another layer or another level of complexity which is the distance. I recognize you and I are doing this podcast remotely. How do you move towards true product development when your team members are literally, if not across the country, across the globe, and how can you manage that process?
Josh Turpen: That’s a really good question. I think there’s a lot of different strategies for it, but I always come back to making sure that your teams know why they’re building what they’re building and what they’re building. So in a pure software world that might be user stories, in a complex world that might be requirements linked to user stories, linked to reviews and risk and tests, but ultimately, having a repository or a method for engineers to see not only what they’re building, but the context around it and the why behind it helps decision-making.
Josh Turpen: I mean, people forget that engineering is a discipline of thousands of decisions that you’re making all the time. Do I write this code? Do I write that code? Do I build it this way? Do I build it that way? And it’s impossible to codify all of that into a single requirement. So you need to provide as much context as humanly possible to your engineering teams so that they can make those decisions and make more right decisions than wrong decisions.
Tom Fox: Many of my listeners are corporate compliance officers. They may be lawyers by professional training. That’s my background. The son of an engineer, so I have some understanding of what you’re talking about. But it strikes me that answering that why question, that’s viewed as a critical element to obtain buy-in from individuals. Does that hold true for engineers as well?
Josh Turpen: Well, interestingly enough, I am the son of an attorney. So we’ve got a flip flop. I think it absolutely holds true for engineers. It amazed me kind of progressing through my career, even all the way back to the DOD, the amount and weight of decisions that were entrusted to engineers every single day. If you really stop to think about it, you’re not going to sleep very well at night, but I think by providing that context, getting the engineers bought in on why this matters? Why is it so safety critical? Why do I need to pay attention to this and the tests and the risk and the ecosystem is absolutely critical to the success or failure of your product development effort, and it will help separate quickly the great engineers from the average or poor.
RELATED: Strategies for Remote Engineering Teams
Key Enablers for Product Development Success
Tom Fox: So what are some of the key enablers of product development success or utilizing a team to help develop a product?
Josh Turpen: I think one of the enablers is knowing what you want to build and being able to describe that, as pedantic as that sounds, is often incredibly difficult. So being able to describe what you want and then being able to communicate that out in such a way that it’s consumable by the teams that are actually building it.
Josh Turpen: If you go to a building analogy and all analogies break down over time, right? A lot of the ways that we build software is somebody designs a building and builds blueprints for it, and then they cut out sections of it and hand it to an engineer with no visibility to the larger blueprint. And so decisions are made based on that. And you can see the effect of that in late products, extended product cycles, extended revision cycles, potential recalls, safety problems. So I think one of the key enablers of success is that holistic picture that both your product engineering, compliance, QA, that everybody is bought in on and understands.
Tom Fox: Josh, I was very much intrigued or really wanted to ask you the following question because of your role at Jama Software and that’s management of the process. It occurs to me that you have to work in a managerial role and probably in addition to a hands-on role, but how do you… or what are some of the strategies you utilize or you found successful for the management of this process?
Josh Turpen: That’s a good question. Well, first off, hire good people that makes your job as a manager just so much easier. I’ve had good luck with that. I think second is be an enabler. My job, for the most part, is to set direction and then help my folks get there in any way that I can, whether they need a specific tool, they need more context, they need time with me to understand some of the strategy elements, whatever that happens to be. I think, too often, managers think of themselves as deciders and gatekeepers, and I look at it in the opposite way. I look at myself as an enabler and a cheerleader when things are going well and a coach when we need to course correct. So I think, for me, that’s the biggest thing that I’ve learned in my career is especially transitioning from engineering, it’s not what you do, it’s what you can help your team do.
RELATED: How to Realign Engineering Teams for Remote Work with Minimal Disruption
Tom Fox: Josh, one of the things that I found great to help me prepare for this podcast, but also really as a resource for your customers and clients are the amount of information on the Jama Software site. You’ve got a number of blogs, a lot of great technical information, a lot of great management information, and frankly, a lot of great, what I saw as, risk management information. And I wanted to maybe ask you about a couple of those which is number one, could you detail for us the product development life cycle management?
Josh Turpen: Sure. I appreciate you calling that out, Tom, because it’s one of the things… Jama’s been around for a while now, and we’ve done thousands of these implementations and conversations with customers. And I think it’s really one of our kind of hidden strengths is our depth of knowledge around how to do this and what’s important.
Josh Turpen: But, product development life cycle management is really that holistic picture of product from we have our initial idea of what we want to build all the way through deployment and feedback and making sure that you can connect that and that you can tie all of that together. I personally see from just my years of development, being able to see that whole process and have a window into how your teams are executing, what they’re executing on, what they’re doing well, what they’re not doing well, what the feedback mechanism is. And tying all that together is absolutely critical to an iterative development process that most of us are in.
Josh Turpen: People think that it’s just about doing the next thing, doing the next thing, but it’s much more about understanding where you’re coming from, what the feedback is, what the context of that feedback is, and then how you react to that. So when we talk about product development life cycle management, it’s really about that entire scope and making sure that you can see from end to end.
RELATED: Best Practices for Change Impact Analysis
Tom Fox: And then what are the three steps of a change impact analysis?
Josh Turpen: There’s several steps in a change impact analysis. I mean, to refer to the blog, identification of the sequence, determining whether the change is on the product’s critical path, estimate the impact of the proposed change on schedule and cost, evaluate the change’s priority, and then report on the impact analysis to all the stakeholders.
So I think it’s a pretty normal motion for anybody who’s in this business, and it’s easy to forget all of the steps that go into it. But I think thinking about that and what that looks like and what your process needs to be is an important part of product development. Making sure others know the impact of requested changes helps to prioritize the requested changes, obviously, but also helps to align the business and development on this change is valuable or, “Hey, this was just an idea. Now that we understand what the impact is, we might go a different direction.” So I think that’s a good kind of loop back for the product teams and the business, in general.
