Archived Articles
Working through the pain | Working through the pain |
|
|
|
When and how to split up product management Feature - February 13, 2008
By Peter Longini The clinical testing of new drugs follows a fairly standard process. Vital patient information is collected by doctors using lab tests and sensors that measure physiological events, like respiration. That data is then transmitted to the pharmaceutical companies. And the pharmaceutical companies, in turn, do an analysis to assess their drugs' effectiveness. But some events, like pain, can't be measured directly. So patients are asked to record their sensations in a paper diary. At least, that's the way it was done in clinical trials for generations of pharmaceutical products. There was just one problem: most of the data was unreliable. Instead of recording pain or other sensations at the time they were perceived, most patients would simply rely on memory, often for days at a time, and then hurriedly fill in the diaries minutes before their next appointment. Of course, everyone conducting clinical studies knew there were issues of recall bias with diaries. They just didn't know how bad it was - that is, until Pittsburgh-based invivodata published a landmark study. Worthless data Back in 2001, according to invivodata Marketing Vice President Tom Henson, the company supported Stonybrook University, New York, and the National Cancer Institute in running a study where they furnished patients with what appeared to be a standard paper diary. But every time it was opened, a concealed photo sensor would log in the date and time. "The researchers were able to go back and look at all of the patient entries and see, for example, that patients said they filled it out on Monday at 8:00 AM. But the diary was actually closed on Friday at 5:00 PM and wasn't opened again until Tuesday at 3:00 PM. So it would have been impossible for them to fill out the data when they said they did." In fact, according to the study, actual compliance rates for the paper diaries hovered somewhere around 11 percent. Absolutely abysmal. And it got even worse: "The bigger concern was that around half of the patients actually forward-filled it - entering data for days or weeks into the future. That's not recall bias; that's just fraudulent data. "The results made it into the respected British Medical Journal and it really drew attention to the need for a better way to capture Patient Reported Outcome data," Henson said. That better way, as it turns out, was a product at the heart of invivodata's business - a handheld electronic device that still looks a lot like the PDA it started out to be before the company reprogrammed it to record, retain, and report data the patient enters. And even though Big Pharma is notoriously conservative about innovation, industry acceptance of electronic data, and the extensive support and service system built around it, soon began a very steep climb. Overload That growth spurt put a lot of pressure on invivodata which, until Henson's arrival, had only one product manager. "When I arrived, it was obvious to me that this one product manager had about five times the amount of work on his plate than he could reasonably manage," Henson said. "We needed more processes and more ways to work with Development on planning out what it really takes to get something out to market. There were new products. There were enhancements to existing products. There were partnership integrations. It ran the gamut." Like many companies, invivodata began life without a product manager. But market growth and product line extensions quickly changed all that. "The evolution of product management went from no product management where everybody contributed - the co-founders provided the product vision, the VP of Sales provided the feedback from customers - to the point where we needed a product manager who could be the central point for all of those ideas and for working with Development on a time frame for getting new revisions out," Henson said. Pretty soon, the guy was swamped. Prioritize "It's very common for smaller companies to wait too long before they add the product manager. And then when they do, they figure: okay, we have a product manager, so now we can do all of these things," he noted. "But we needed to prioritize. We took our roadmap, which was a long list, and said okay, what are the things we've got to focus on? If you had 100 points, where would you apply them? And a lot of things just fell out. Then we started looking at which ones could we make money at. So we went through the more formal business case - it was either make us money or reduce our costs and increase efficiencies. "We actually did a time allotment exercise based on everything that needed to be done with projects in different phases," Henson recalled. "These guys would have to work 80 hours a week to get it all done. So if you want product management to drive the entire Operations team as well as a lot of the project management, you simply can't do as much. So we pushed some of that responsibility into the Operations side and some into the Development side. And then we looked at a few of the other ones and said you know what? If it's delayed three months, so be it; we can live with that." "We had to strategize about what the priorities were. What really needs to get out into the field? And when? It became obvious that we needed at least one more product manager," he said. But the detailed answer is different for every company, according to Henson, himself a veteran of FreeMarkets/Ariba and SmartOps. "What are the company's strengths? Is it Operations? Is it Sales? Is it Engineering? You've got to have your product management function adapt to that. So if Engineering is strong and all they need is a list of requirements, then your product managers can be more outbound-focused and concentrate on coordinating with Operations, with Sales, and with how to successfully roll out the next version or the next product." But if your company's core strength is Sales rather than Engineering, you'll need a technical product manager - someone who can focus on the development timeline, on how long it's going to take to test, on oversight of the specifications, and on related product development functions, he explained. "That's the challenge of product management - it's so broad that the focus can be on any area. A lot of times companies view one person as being able to cover all those areas." But that's a mistake. Pay attention Many companies seem to have developed short attention spans. "I've seen in a lot of companies where people tend to forget about the product that got them to where they are today," Henson observed. "They think: okay, the product is out there, now let's let it go and find the Next Big Thing - the new product line that's going to double our revenues. But at invivodata, we can't; this is still a new market. The regulations are evolving, the sponsors' needs are evolving. We've got to stay focused on the core and build out from there rather than finding some completely new market." But even then, new products require constant attention, Henson pointed out. Product management doesn't end with product launch. "We can't get into the mode of thinking: okay, Project A is done - it's out, we've trained sales, there's a blurb on our Web site about it; now the product manager can jump onto the next one," he said. "Success is sticking with that product, getting feedback from the customers, learning what's working from Sales, and finding out from the help desk what kinds of calls we're getting. It also means going through at least a few iterations to make sure it's hitting the mark with customers." Division "Over time, as the company grows, as its product line grows, its product management staff has to grow, too. Unless you're going to sunset products and decide that you're just not going to pay attention to them, somebody always has to be there answering the phone for Sales, working with Development on the next release," he said. But when you do add to the product management staff, exactly how do you divide the product management work? There are plenty of off-the-shelf answers - by product line, by function, by life cycle, by inbound vs. outbound focus, by management whim, and so on. But a great deal depends on the company's unique culture, strengths, and immediate needs, according to Henson. And there's typically not a bright line dividing or subdividing the product managers' assignments. As a result, some of it can be arbitrary. "In a perfect world, I would be able to look at all those different ways to segment and say okay, here's what makes the most sense," Henson said. But the real world works a little differently. "We just let everyone know that here's how we're dividing up the world - that this product manager has these applications, and this product manager has those. And while it's not perfect - there is still some gray area - from a work standpoint, it all balances out." About the Author:
To read our latest articles in Inside Product Strategy™ click here. |