Better company performance requires a better-performing product management team

Feature

Transitioning a technically-oriented product management function into a market-focused one requires re-engineering people’s expectations as much as reorganizing their workflow.  Veteran product strategist Jason Baim has led that effort at TeleTracking Technologies and talks about the evolution.

By PSN Staff Writer

Over its 17-year history, TeleTracking Technologies - a software company with 200 employees and a product line focused on automating patient flow in hospitals - had established itself as a leader in its market space.  And for most of that time, the company included a product management function.  But, according to Jason Baim, a seasoned business strategist and technology product manager who joined the company as its director of product management in early 2007, product management at TeleTracking was a job whose primary role was to support engineering, sales, and implementation.

"Our product managers were highly responsive to customers, with their work focusing very much on the technical side," Baim recalled.  "Their role was to help write functional specs, install and configure the product for clients, support beta testing, perform demos, triage product defects, and test new features.  And they were doing the job they had been asked to do." 

All of the tasks they did were important, but with a maturing marketplace and new competitors, the company needed to build on its established technical strengths and expand beyond the markets and customers it had served in the past.  That required a different product management focus - one directed toward identifying the needs and requirements of the broader market. "Traditional product management tasks, such as writing requirements documents and roadmapping, were either not well structured or just not being done.  And with relatively few products in the portfolio, most product strategy was done from the top down, with little involvement from product managers," he said. 

Even within the product management group itself, there were significant challenges, Baim observed.  "With most of the Product Managers being remote and with a robust travel schedule, communication suffered and there was little in the way of shared best practices.  There was little standardization of the tools they were using.  There was little opportunity or encouragement to work cross-functionally with other parts of the organization or with one another.  Even though their roles were similarly defined, the nuances of each product and market segment lent to a ‘silo' mentality versus functioning as a team." 

There were also inconsistencies in the ways various product management practices were being applied.  "We brought customers into our process, but not in a consistent way and not in a comprehensive way.  We were doing alpha and beta testing but it wasn't clear what the goals of that testing were," he said.  "There wasn't a very clear notion of what alpha testing was for - which to my mind is addressing usability, workflow, and testing the functionality of a product to make sure the feature is defined correctly - and there wasn't really a notion of beta testing either, which is testing integration, scalability and performance in a production environment.  The two stages tended to blur together without strict measurements." 

What do you expect?

Then, about three years ago, TeleTracking determined that its familiar pattern of operation needed to change for the company to realize its goal of accelerated growth.  Although it was already doing well, its business environment was changing.  The introduction of new products into the marketplace, together with new competition and its own organic growth, had effectively altered the game.  And raising the company's overall level of performance would require making several new hires.  One was a VP of Engineering and CTO to head product development and technology strategy.  Another was someone to rev up its product management team, initially in the area of product life cycle management.  That's when Baim, whose background included senior product management and strategic roles at EMC Corporation, Lucent Technologies, and FTP Software, was brought on board.

Once he got there, Baim began to assess the situation on the ground.  Initially, it involved interviewing internal and external customers - particularly his counterparts in other functional areas of the company - for their thoughts about product management.  "One of the first things I did was to ask ‘what is product management about in TeleTracking today and where is it falling short?'  I wanted to get an idea of what other people thought that product managers were supposed to do.  What are they being called on to do?  Where are their challenges?  Where are they not meeting your expectations?  And it didn't matter whether those expectations were appropriate or not."

That's because even though some expectations are unrealistic, the work which product managers already do creates expectations in others.  "It almost doesn't matter if what they're doing now is what they'll be doing in the future.  If it's going to change, there's a gap that will have to be filled.  And one of the biggest mistakes people can make in trying to change the product management organization is that even if you want to change it, and even if you have executive support to change it, you can't change it and leave gaps.  If you do, product managers are going to be seen as this group of people who used to do something, but now they've dropped the ball. 

"There's always something that product managers are being called on to do that doesn't align with the vision of a product manager as the owner of the business," he said.  "Sometimes you simply have to roll-up your sleeves, but also have to identify that point where certain tasks begin to compete with true product management functions. A lot of times it'll be some sort of routine administrative action that should really belong to another organization: defect triage, doing demos, or any number of other examples.  So it's incumbent upon a product management team to make sure the gap is being filled somehow, even if it's not by your own team." 

Phasing in new practices

Building up his product managers' tactical toolkit became another important challenge.  But, as it turned out, many of the needed resources were actually already at hand, even though they had never been tapped before.  "We had several people on the team who had come from other companies and had life-cycle documentation experience.  So we were able to tap into their prior experience to introduce something into the company and get it to take hold.  In fact, we had a lot of skilled people on board at the time that had never been tasked to do things like write requirements documents, or to manage according to a full lifecycle plan versus just a development plan.  We had the capacity, but that capacity had never been tapped. 

"Don't assume that because the team hasn't been performing as well as desired doesn't mean that they're incapable of doing so," he said.  "Maybe they've never been asked.  Maybe they've never been challenged to do so.  You might find some very pleasant surprises." 

Of course, people's skill and experience levels weren't uniform.  Some people didn't have the right mix and found new roles, a few ended up separated from the organization.  Still others were brought in from outside to address critical roles where hitting the ground running is key.  "I hired a program manager with extensive experience in commercial software to come on board," Baim pointed out.    

"In any change, 20 percent of the people are going to change right away, 20 percent are never going to change, and 60 percent are going to wait and see.  It's almost the same for changing a team dynamic.  Some people are just not going to change.  They're not going to either have the skills or the desire to change.  But you're going to find people who have the capacity, the willingness, and all they really need is the opportunity." 

Don't jettison everything

However there are limits.  In an ongoing business, Baim warns, there are constraints on how quickly you can move.  "When you have releases flying out the door, you can't stop what you're doing on every single project and start all over again.  You have to try and change the wheels on the car while it's driving.  So the approach we've taken is that you have to introduce tools to the team in a measured fashion," he said.  "For example, we tried a new approach to the alpha testing phase of one of our new product releases, trialed it, and had some good learning.  So now we're standardizing it across the product management team and across the company. 

"Same with requirements documentation.  We had a lot of products that were reasonably well-vetted for market acceptance, had already moved beyond the functional spec stage and were well into development.  So we couldn't just say: ‘STOP; we're going to go back and do a requirements document.'  Instead, to introduce requirements documentation, we selected the next appropriate project far enough into the future so that we could start doing the right things and then roll it out. 

The moral: "You can't re-engineer everything all at once," Baim said.  "In the healthcare field, that's especially important; we have to make sure that when we change a system, the disruption to the hospital environment is minimal.  Because if we mess up, ultimately it is the patients that suffer."

Check in

To learn how it's going, seek out feedback  "It's important to check in on a fairly regular basis with the people you originally interviewed about the role of product management as well as with your executive team," Baim advised.  "As you start making changes, track your progress.  So, for example, if you're now running alpha programs and getting feedback early into the product line, check back with the engineering team and say: is it working?  Are we making the right choices?  Are we driving the right kinds of behaviors?   Make sure the new process is still working. 

"The final thing is to periodically check in with your own team.  Ask ‘do you enjoy the new role you're in?  Is it working for you?'  People will tell you they're advocates of change, but it's still very hard if they've been involved in one role for a very long time.  Some will say it's great and they'll become energized.  Others will go along with it, but they're really not comfortable.  That doesn't mean they're not a good employee or that there isn't a role for them in the company.  But they may not be operating as effectively as they can.  Just don't force someone into product management if it's not the right job for them." 

To read our latest articles in Inside Product Strategy™ click here.