Product Marketing Portfolio Definition Methodologies in an ISO 13485 world
With an ever-increasing number of cloud-based product management tools out there, the question is begged — is there a substitute for experience? Is there a way to formulate metrics that will allow one to create perfect product fit and placement? Can you create software that will support the ideation process in a manner that is extensible, e.g., can you grow the idea into a story?
To this day, I find it amazing that many of those in the device or software development sector are for the most part unaware of textbook product management methodologies that have been around since product management became a thing. While AI and automation can enhance the product portfolio management process, they cannot replace it.
Over the last three decades, I’ve had the good fortune of working for a couple of very large companies, a couple of middle-size companies, and even a couple of start-up companies in product and product line development, and I believe my treatise to hold true across the board, that that there is no substitute for a good product manager. What are your thoughts?
With the ever-increasing number of entrepreneurs in the medical device/software ecosystem, there is an inclination to apply technology to the process of developing technology. Remember what Thomas Alva Edison famously never really said about VOC data, “If I had listened to what my customers wanted, I would have built a faster horse”. Indeed, most product managers go into development meetings oftentimes armed with a good notion as to what the market is looking for. But don’t expect the users to build your product. Remember that the client’s level of excitement might only relate to the quality of the catering that you provided for your Lean Sigma ideation sessions.
In the medical technology space, more than other industries, I think there is a predilection for throwing technology at a problem that may or may not be real. I will even be honest enough to raise my hand here with a certain STEMI EMS2EMR project that shall go nameless, but as they say “if you cannot be a role model, at least be a lesson to avoid”. I have actually worked on a code blue team back in my younger days of respiratory therapy and know that time is of the essence and that medical product developers also need to know when to get out of the way. At the same time, the problem that we were trying to solve was the ability to provide a comparative ECG for chest pain, or so-called “DRG 313” admission. The problem was real, but the method of solving was specious at best.
The product ideology cadence from the metaphorical product management playbook typically starts with a marketing requirements document or MRD. This is the why of the product development. It may be that you must include a certain feature-set every time you do a project and so creating “x” software will not only save “x” amount of money but will also create a revenue stream with cross-sell capabilities defined to be special projects, etc. And the goal is always to make revenue. There are way too many, what we used to call “science fair projects”. These are things that do not make money. And then there are products that evolve from a need and are in fact designed to a need.
My favorite story along those lines was at Marquette Electronics, I was a young stress-testing product manager and worked with a software engineer by the name of Bruce Langenbach. He became my best friend and we ate lunch every day at the Bistro, the restaurant at Tower Ave, or at Yen Ching, my favorite Chinese restaurant in Milwaukee. In 1994, I was working on a project at Hartford Hospital where they had four Quinton stress testing systems. The salesperson had found out that their cardiology group was doing some ground-breaking research, in the sense that they wanted to capture data from the device, IoT style. The CASE (computerized assisted system for exercise), had recently been redesigned from CASE 12 due to the big Mortara-Cudahy divide that would see ultimately see Dr. David Mortara strike out on his own. The CASE 15 had a single port that would export the final report out in ASCII to a parallel port.
Bruce and I had been playing with parsing the ASCII data dump that was the final report generation of its day. Microsoft had just released Word 6.0 that had Visual Basic tools for macros. In those days if you wanted a pretty report, you had to use Crystal Reports, but everyone recognized that embedded data into an MS Word or XLS document was the better way to go. Long story short, we provided them an X rev Visual Basic executable to import stress testing ST-segment level and slope for every minute of pre-exercise, exercise, and recovery phases. This ultimately replaced all four of the competitive systems and soon thereafter, they replaced all of their house-wide patient monitoring systems with Marquette. I believe MUSEWord is still sold by GE to this day, and with some old-fashioned PM/Engineering networking going on, et voila, good things happen for patients and shareholders alike. There was no directive or enhancement request. It evolved naturally.
When I came on board to Mortara, we were building a whole new product portfolio from the ground up. There is no AI-based portfolio decision-making tool that existed that would be able to simulate the very large testicles required to change the entire storage protocol of resting 12 lead ECGs </snark>. It was a decision predicated on market experience, technical expertise, and guts. My old boss at GE told me at the American College of Cardiology (ACC) meeting when we released it that DICOM 12 lead ECG would be “the standard of one”. Frost and Sullivan awarded the 12 lead ECG DICOM protocol, the 2008 Strategic Marketing award”, as it was a truly technology disrupter, as it was strategic, and it worked extremely well.
Product Portfolio Definition Tools
1. Product Managers — In my opinion, for product portfolio definition, nothing beats a passionate product manager. I can remember several in my career and can clearly recant what they brought the party, so to speak, in terms of defining a product roadmap. The product manager is the orchestra leader, able to deal with parts substitutions on the product line, listen to salespeople’s wish feature wish lists, and correctly quell any CAPA-bearing complaints. Product managers often come from an engineering or clinical background and are often considered “evangelist number one” for a product. As portfolio designers, they have the necessary market background to be able to make strategic decisions intelligently.
2. Marketing Requirements Document (MRD). The “why” of the product that is being contemplated. There should be metrics to define the before and after of the product inclusion. What are the cross-sells? What are the larger strategic implications? (as for me, DICOM 12-ad ECG will always stick as a top example of “disruptive technology” that actually changed the global marketplace). The MRD should be honest and be prepared to say no with factual engineering and sales forecasts whether the project should move forward or not.
3. Product Requirements Document (PRD) With a green light given with the MRD, the Product Requirements Document will take a deeper dive into the architecture, risk and regulatory management aspects, user interface, interfaces, and service considerations. The PRD is important as not only does it begin the engineering specifications file, but all of the design information also begins the Design History File or DHF. In the medical device design world, the ISO-13485 regulations basically say that your product should match your design, and that should match the intended purpose of the product, software or system, by illuminating the similarities with the predicate device.
4. User Requirement Documents The URD can be used as a guide for planning costs, timetables, milestones, testing, etc. The explicit nature of the URD allows customers to show it to various stakeholders to make sure all necessary features are described. Formulating a URD requires negotiations to determine what is technically and economically feasible. Preparing a URD is one of those projects that requires a duality of skills — requiring both software technical skills and interpersonal skills.
5. Engineering Specifications: Note that in the world of ISO-13485 and especially in light of the changes coming for the FDA Case for Quality (CFQ), all of the engineering specifications from PCB schematic capture, to 3D mechanical drawings to simulation files should be referenced and accessible in the DHF.
Can software and AI enhance these processes? Absolutely! After all, a good bit of the product development and quality process is actually project management, which is a matter of keeping the project stakeholders moving forward. A good cloud-based tool can enhance the communications and traceability required to build a good product. But in my mind, product portfolio development is not just an art, it is a hard skill, not a soft skill, and not one easily replaced by software, algorithms, or dashboards.
