Panel Discussion moderated by Stewart Rogers, Product Manager - PSG, Ryma Technology Solutions with Panelists: Carrie Dion, Senior PM Operations Manager, Trend Micro George Prehatin, Manager of Product Operations, Yantra Jeff Wade, Office Director for the PMM52 Program, Filenet Corporation - Our panel of industry executives will explore Product Management processes and tools. We will analyze what works well for them day-to-day, what tactical tools and processes they use and how they have implemented them. We will share war stories on what has and has not worked well in the past. Tools discussed will include Microsoft Office Suite, homegrown databases, and enterprise product management and development software tools. The panelists will focus on the pain points associated with the tactical gathering of market data, as well as implementing that data in a strategic market-facing analysis.

TRANSCRIPT

Stewart Rogers, Ryma Technology, Introduction:

Welcome to today's Insight Webinar, a panel discussion on Guidance on Product Management Processes and Tools. Our panel of industry executives will explore product management processes and tools today. We will analyze what works well for them today, what tactical tools and processes they use, and how they have implemented them.

Here are some quick introductions. I am the chair today. My name is Stewart Rogers. I am a product manager at Ryma. Our panel includes Jeff Wade from FileNet Corporation. He is the Office Director for the PMM52 Program. We also have George Prehatin, from Yantra, who is the Manager of Product Operations, and Carrie Dion, from Trend Micro. She is the Senior PM Operations Manager at Trend Micro.
Slide - Session Overview:

Briefly, here is our session overview for today. I will take a few minutes to discuss some key things to think about when defining a product management process. Our panel members will then discuss how they have implemented their process and received the all-important stakeholder buy-in.

Quickly, the first step in developing a product management process is to determine what type of company you work for. There are generally three types: technology-driven, where development typically drives the organization, sales-driven, which is more "deals-driven," with one-off customer decisions, and market-driven, where you use market data or market evidence to make decisions for your product.
Slide - Product Management Process:

This process is typically followed by doing a role assessment of the product manager. The product manager is typically responsible for the "four P's": positioning, placement, pricing, and promotion, of the product. The product managers are typically executing four tasks on a daily basis. They are acquiring content for their market requirements documents. They are managing the feature list. They are coordinating activities for the different functional groups. And then they are participating in the marketing activities for the product.

The goals of the product management process include: ensuring that you have a market-driven approach for the whole product offering, establishing a competitive product offering, ensuring that the distribution of that product is in place, and then contributing to effective marketing programs.
Slide - Methodologies:

I want to take a minute to highlight some of the product management methodologies or frameworks that are available for you. Some of these include Pragmatic Marketing, ZIGZAG Marketing, Blackblot, lifecycle strategies, and that of the Product Development Institute, with the Stage-Gate Process. And most of you are familiar with the Rational Unified Process. And, of course, there are many, many others. You can visit any of their respective websites for more information. At this point I am going to hand this over to Jeff Wade, so that he can begin his piece of the presentation.
Slide - Jeff Wade, FileNet Corporation :

Great. Thank you, Stewart. Yes, our program is called PMM52. We decided to have sort of a catchy acronym for that, so that everybody would tend to start "living and breathing" it on a regular basis. The acronym actually stands for "Product to Market Methodology." And there happen to be fifty-two major steps in that process, from conceptualizing a product or a release of a product to eventually, at the end of its lifecycle, performing an "end of life analysis" and execution.

I have been with FileNet for a number of years. I have done almost everything that you can do in marketing. And, about a year and a half ago, we started something called the "Product Lifecycle Initiative." I was asked to run that program.

We initially did bring in some consultant support to help us with a framework for what we were trying to accomplish. That also helps from a legitimacy perspective, in terms of the organization as a whole buying into the idea that this is needed, by understanding that we have brought in some professionals to give us some guidance. Once they go away and it's left for us to implement and continue to develop, we have that foundation in place. So that was a good idea. The program was actually directed by the office of the Chief Marketing Officer, but with significant support from all of executive management. That was a very helpful foundation, as well.

We did a number of things early on, essentially in the first year, using the consultants for direction initially and then making two major steps. One is creating a methodology for portfolio analysis and planning, across the product lines, developing metrics and measurements to analyze the stage of a lifecycle, in terms of where products were and the balance of investment across the portfolio. And there was planning for new products, OEMs, even some work in the M&A area to better define that process.

The second part was around this Stage-Gate process development that was referred to as one of the key tools used in product marketing methodology. We actually have combined a number of things. We incorporate Pragmatic Marketing, which we use extensively, and have for many years. We have incorporated Chasm Theory and the Stage-Gate process is really just the mechanics of how we are executing through the product lifecycle.

Once we established some underlying frameworks, we started actual deployment. We did start this prior to actually creating the entire set of artifacts, or even all the processes. We really just had a framework in place. But we felt that it was important to start real-time implementation while creating and while optimizing the continuous improvements. This has actually worked reasonably well to take that approach. It is a challenge in many ways, as I'll talk about with the next slide.
Slide - Current Challenges:

Let me just start with the first bullet. Some of the key goals that we have include consistency of process and artifacts across the organization, having everybody in product marketing and product management using the same tools. The second goal is to have transparency of information across the organization and the whole product team, in Chasm Theory. That includes the value of having people aware of the status of a product in its lifecycle, who is doing what, when, what the prerequisites are to getting things done, and what to expect in terms of output from certain groups. The transparency of this information across the organization is invaluable. The only way that can truly be achieved is with consistent process, so that everybody knows what to expect next.

The ultimate result of this is something that we call "No Surprises." It's one thing to actually bring a product to market and have it go smoothly, without any problems. But we all know that there are all kinds of unknowns that hit you at the end of the day. The key is to be aware of the potholes before you reach them, to have all organizations' readiness understood, whether it's a hundred percent or something less-than, and to know that there may be some soft spots and to deal with them.

I have just been reading a book called Flawless Execution, by James Murphy, the CEO of Afterburner. The concept of "flawless execution" from a military standpoint applies very well in business. This is that things will always go wrong. It's a matter of being prepared for them and having contingency plans, to deal with things before they affect your ultimate outcome and goals.

We have used these as our goals and objectives. Many of the bullets on this slide are essentially just "change management" challenges. You are always going to have to educate while causing change. You are always going to have to manage the enthusiasm. There are always going to be people who are eager to drive forward faster than you are ready for. There are always going to be people trying to hang onto the old ways. The concept of "change management" and being prepared for what that means is very important as you start to implement.

In our organization we actually have separate product management and separate product marketing groups. They are both under one senior vice-president of marketing. But what it does provide for is a separation of skill sets to groups that have a better affinity for working with development and concentrating on the functionality of the product, versus product marketing, which is more about the requirements, interacting with the customers in the field, creating the marketing programs to launch the product, et cetera.

So what we have tried to do is to define the "teaming" of a product-marketing and a product-management person over the various aspects of PMM52, which sometimes have not very black-and-white boundaries. As long as they are doing good teamwork, they can share in the responsibility of duties. But that has been a little bit of a challenge, in the sense that, as we add products to the portfolio, there is not always a product manager ready to jump in. Or, maybe we don't have a product marketing person yet assigned. Then that becomes a challenge, as opposed, perhaps, to what happens in a smaller organization that has one person doing all of those roles on his own.

FileNet is about a four hundred million dollar annual revenue company and we have about fifty products in our portfolio across enterprise content management, business process management, and compliance software. We are also implementing Feature Plan, by Ryma Tech. That is going quite well. We went live a couple of weeks ago in the product management team and engineering team and we're going to roll that out to additional users here next month. We are using that to manage all of our requirements and then to generate MRDs and PRDs. Also we are using it with some of our other processes, such as our Change Control Board, which we use to manage changes that happen to a product that has already been defined and is already being developed. These are changes in terms of schedule or content. They need to go through our Change Control Board process.
Slide - FileNet's Process:

As you might expect, and as is typical, spreadsheets and Word templates are the typical tools that we have used in the past and, for the most part, will continue to use in the future. However, products, including Feature Plan and our own content management system will allow us to make the integration with systems across the company a little bit more seamless. The more that we can automate things, the more we can create an easier process for the people creating artifacts, the more that we can integrate with customer service to gather requirements and with engineering to share in the planning of new products, then the more efficient our entire process will be.
Slide - The Utopian Process:

Ultimately we want the organization to self-drive with these tools that we are providing. Today it's very much a program-office-driven process, as we're getting people up to speed, as new people come on board. They need to be educated. As people start to use the artifacts, they need to understand the process related to the artifact. And, given that we're implementing over what we consider to be about an 18-24 month period, having just started about eight months ago, there is a lot of work to be done before it becomes something that is pervasive and consistent.

We have found that some of the artifacts that we create, some of the templates, we are enhancing and updating within thirty days after the first couple of people start to use them and have suggestions. But that is a good thing. It improves the best practice while implementing it. But that does take quite a bit of work while you are still trying to create artifacts and processes for areas where you have not yet imposed the process upon any individuals.

We are using repositories, using our own product to share information. That is working reasonably well. The challenge in the past has been that, with everybody having their own access and sort of "authorship rights" to the repository, the approach for storing and making available that information was not very consistent. As a result, people had trouble finding things and didn't know which was the latest version. That is exactly the opposite of what a content management system should be doing. So we have gotten a little bit better process in management around that, in terms of security and in terms of groups and in terms of methodologies that we have deployed for everybody to follow.

The reporting of our status is something that has also become very useful, in terms of that transparency. We are reporting more about the status of products. We have more information readily available on whom to contact for what aspect of a product and depending where it is in the lifecycle. And we are really involving groups from the very beginnings of a lifecycle all the way to getting it out the door and supporting it and making sure that all aspects of the launch, as well as the development, are integrated.

One of the projects that we are doing in parallel is some update on process within our engineering team. We are working together to make sure that their new processes for code development and test are revealed through the PMM52 process, where appropriate. So, certain artifacts that cross boundaries from the software development team into other organizations need to be called out and to be available at the appropriate time with the right information so that the rest of the organization and whole product team can benefit from that.
Slide - The Tools We Use:

Some of the things that we have implemented in the process include what we call both "internal" and "external" roadmaps. The external audience is field sales, customers, and partners. They need a different format and a different view of our roadmap that is more about the content and the ballpark timeframe. The internal roadmap really is much more oriented towards the schedule and the development timeline and making sure that the readiness of all the functional groups is there and also enabling the interaction between those groups.

We do a number of things around this Stage-Gate process. We have reports on the "gates" when products go through, with a specific board and members who meet monthly. The Governance Board is a senior executive-level board that handles escalations or exceptions from the Gate Review Board. What happens is that if a project is being reviewed and passes through the Gate Review Board at Plan Stage, but requires additional resources or investment in some way, then that needs to go to a more senior level of staff, if it is outside of budget for the calendar year. Then it can be approved, or at least reviewed, as an exception to be considered. So, there are a number of structural groups. In addition to just creating a life-cycle process, there is the whole program management and the coordination with these approval groups that needs to be handled.
Slide - FileNet's Lessons Learned:

I'll close with some of the lessons learned. When we were originally defining our "as is" process, we did find that a large percentage of our "utopian view" of the process was in place today. The biggest problem was that not everybody was doing it the same way. And not everybody was really looking at every step as they launched a product. That was the good news.

The bad news is that we didn't take the concept of best practice sample gathering as seriously as we should have. We didn't give ourselves credit for the fact that we do have more best practices than we thought. It's just that everybody's view of that was different, so nobody could really agree on what tool or what artifact was the best practice. So we may have caused some additional work to be accomplished later on by not gathering more up front.

The project program management of the process is probably a bigger job than we anticipated. It's hard to deploy something and expect it to "self program manage" when people are still learning the process itself. Over time they will be able to drive it on their own in a more efficient way, but right now it needs a lot of supervision. We did bring in an intern for some extra work. I had a very sharp person working for me. But, because he was part-time and didn't know the internal processes, it wasn't as efficient as it could have been having somebody who was in-house and fulltime focused on it. But that was a matter of resource allocation.

The security models and the planning around deploying our content management system probably need a little bit more up-front planning. But that has evolved and is working pretty well now. And, in building an evolving process as we go, we found that we were ready to implement Feature Plan, but we hadn't really nailed down the processes that we wanted to deploy in Feature Plan. So, given that we were doing them in parallel, that caused a little bit of extra effort, in terms of deployment. Again, we are beyond that now. I will welcome your questions. Now I'll turn it over to the next speaker.
Slide - George Prehatin, Yantra:

Thank you, Jeff. We go from a four hundred million dollar company to a thirty million dollar company. Yantra, within the past year, was acquired by Sterling Commerce. They are based out of Dublin, Ohio. But I am going to speak to you this afternoon about Yantra's challenges as a small startup as a thirty million dollar company.

I'll tell you a little bit about Yantra. This is a supply chain execution company. We started about eight years ago. Again, we have thirty million dollars in revenue. What we do is that we provide the infrastructure for companies like the GAP and VHO and FedEx, for them to do their distributed order management in warehouse management software. We, in essence, have one product with twenty-seven parts.
Slide - Current Challenges:

To try to manage that and collect that data and to fill these columns and different needs of our customers, we really needed to do two things. We needed to have a process and then we needed to have tools to manage that process. Our product management team decided on Pragmatic Marketing. We went to the classes and followed their approach. But, more importantly, after product management had learned that, we then had to get buy-in from development and pre-sales, the consulting, and the support group, so that we were all on the same page and all managing and using the same processes.

Another challenge for Yantra was this. Our product managers are highly, highly technical. Although they understand the very nature and details of the product, that doesn't necessarily make them good product managers, looking at the overall market, determining what is scalable and what processes and procedures can be used at other companies. So we had to focus on that, also.
Slide - Yantra's Process, BEFORE:

So, for "Before," - I think a lot of folks can relate to this - we had all these different organizations giving us inputs, whether it be on Excel spreadsheets or via email, giving us requirements, trying to manage timeframes and timetables. It was really, really quite confusing.
Slide - AFTER, Yantra's Product Management Process:

So, what we did is to come up with this process, which includes Product Expansion, Engineering Resource Allocation, and then finally, Product Maintenance. Again, this is probably a little bit different view. But it is the Pragmatic Marketing approach that we have taken.
Slide - The Utopian Process:

The "Utopian Process" was really to improve the alignment with value potential for customers and Yantra. We needed to provide clarity and direction, both internally and externally. We needed to permit objective influences at the strategic level, which is the business direction, not the tactical level. And we also needed MRD development and early identification of candidates for alternative development strategies, which would possibly be bringing in other third-party companies to integrate with our suite of offerings.
Slide - The Tools We Use:

We use the Pragmatic Marketing framework. We have been using Feature Plan for about seventeen months. I'll go a little bit into that process. When the product managers develop an MRD for a particular release, they will then take that MRD, socialize that with our engineering team, make the tradeoffs of what can and cannot be in that release, and then finally, using the Feature Plan tool, will write a full-blown product requirements document.

We've had some kind of added benefits to this whole structure of having a PRD. We found, as we were ready to release a product (or a month before release of a product), that the education department would come to us and say, "What kind of information do you have on the product that we can use to develop the classes?" Then we would hand them the PRD. Customer support would say, "We want to start to learn about this new release coming up. How can we learn about that?" So we used the PRD. We did not plan on this, but it was just fallout of both using the process and the tools, that this PRD has become a rather popular document within Yantra.

And finally, Clarify is our front-end system. Clarify is how our customers will provide us with requirements and what their needs are. We are in the process of integrating Clarify with Feature Plan. That should help to automate the process and make it go more smoothly.
Slide - Yantra's Lessons Learned:

What are our lessons learned? Boy! This is a process that is never-ending. We continue to learn.

The time and resources used to create detailed PRDs reduces the development time. Let me talk to you a little bit about that. The nice thing about process is that everybody is doing the same thing. But also, it really is a lot more time-consuming. However, having said that, if you put in the up-front time to develop clear market requirements and clear PRDs and hand that over to development, then they spend less time developing it. What we have found is that we are seeing a reduction even in bugs. Right from the beginning we have a great foundation. Development knows what they are designing. When they hand it over to QA, it is a cleaner product. And when it ships, we're seeing this. If you could look at it on a scale from 1-10, we are spending a lot more time up front, but then the back end is being shortened. Again, we didn't really think about this when we instituted it. It was just fallout from doing good work up front.

Then, finally, we needed to plan accordingly for the increased workload on product management time. I don't think that I can emphasize enough that when we do the process, we do it right. It does take much longer. As management, we have to plan for that accordingly. I'm going to hand this over to Carrie now.
Slide - Carrie Dion, Trend Micro:

Thank you very much. Trend is not so unlike FileNet. It is a large company. We have over twenty-six hundred employees, a global environment that we sell our products in, and a global developing and marketing department, too.

We made a lot of mistakes, as the other companies did. One was that we implemented Feature Plan as sort of a "spot fix" for a particular set of issues that we were having at Trend Micro. The new thing that we were trying to do was to create a framework for all the PMs to work in with a global implementation on different continents.

PMs were allowed to put together their own process for developing marketing requirement documents. So we were getting a lot of different levels of skill sets and process. We just were not getting a lot of the transparency that we needed, or the consistency of the documents that we wanted.

We were also looking for a repository, because Trend Micro was experiencing some situations where product managers were moving around. When a new product manager came in or took over a product, it was difficult to know where things were. Things were in people's email boxes and spreadsheets and Word documents. We do have a document management system, but people weren't using it consistently.

So, we were having a lot of the same issues that FileNet was having. We also managed roadmaps. And we were looking for a better way to manage those roadmaps, because that was taking a lot of our time.
Slide - Trend Micro's Process:

Those were the goals that we had. Then, after we started our implementation in the Feature Plan (and we are about nine months into that now), we started moving into the Pragmatic Marketing model. So we are sort of "retrofitting" and developing processes to align with our maturity in using our tools.

Currently, all of Feature Plan is rolled out to the product managers. We are all using it for the process part. That part of the infrastructure is pretty well in place now. We do, obviously, have the same learning and training curve that everybody else has. We manage our products and our resources through an executive management team called the Product Planning Committee. We have certain "gates" or "milestones," as we call them through which product teams come in and review their plans with us.

We use customer visits and surveys to validate marketing requirements. We have recently been completing a reorganization in the market segment. That is a bit of a challenge for us that I will get into in a moment. We are such a large company. We have enterprise customers and we have consumers. The marketing process for those two different markets is also different. So, we'll get into that a little.

And, of course, we try to manage our priorities by the Return On Investment and strategic value for each product.
Slide - Current Challenges:

Some of the current challenges include the distributed ownership. We now have this market segment organizational structure that has some bonuses. But the downside is that we still have products that are shared across business segments. With the global implementation, we have to be somewhat flexible in terms of exactly what parts of the process the PMCs adhere to. There is a basic framework that they have to work in and then there are areas of flexibility, depending on what your market segment looks like and how your process should be organized. For example, if you are in the consumer market, you might do mass customer surveys, but you would not go to customer sites and visit. That's one challenge.

Another challenge is that we are technology-driven and innovation is highly valued. We have had to develop processes that allow innovation inside of a structured product life-cycle process.

Another challenge for us, and I think this was mentioned before, is that the engineering department is a separate department from the marketing department. And they have their own set of processes. We have touch points, of course, where these overlap, but they are using a completely different set of tools than we are. So far they have been reluctant to use Feature Plan to develop their product requirements documents.

And then there is managing expectations. Of course, we have some people who just really went "gung-ho" with our tool and probably were trying to do things that we weren't ready to do. And then there are other people who are still reluctant to change old ways. So we had to develop the process and keep everyone in synch as we moved along that timeline. And that has been a little bit challenging.

I mentioned before the global deployment across market segments. We are working with product marketing groups that are in different countries and working with different market segments. So the processes tend to have to be somewhat flexible. As I said, we put together a framework for that, to work in and allow them to use flexibility where needed.
Q&A:

Thank you very much, Carrie, and the other panelists and the moderator. At this point we will begin with the questions.