07004 Get With the Program: A Programmatic Approach

My experience with Product Management has been one of trying to take the best ideas, and best practices, and applying them to each aspect of my job. It has involved lots of hard work. Yet with those top ideas and hard work, it seems as if it remains just as difficult to achieve results each time. With each time, for each release, with each marketing campaign, the results seem to have been just as vulnerable to failure.

Some of this ongoing difficulty is no doubt due to the downside of the flexibility I so prize. I have found that successful Product Management requires a generous portion of flexibility as a Product Manager moves from one product to another, and from company to company. Without the flexibility to adapt methods and processes to each new situation, Product Management becomes an exercise in forcing one's will on a very unwilling organization. The negative momentum that results from such forcing can derail the results of a Product Manager's most rigorous efforts.

Over the years I have gained experience with different products and organizations, and seen successes and failures through several attempts to help build flourishing businesses around software products. I have come to realize that there is a whole aspect to successful Product Management that is separate from, and in addition to, the many piece-meal strategies and tactics that I employ as a Product Manager. That aspect is the concept of a program approach to Product Management.

I have the Disaster Recovery and Business Continuity industry, the industry for the product I currently manage, to thank for introducing me to the program approach. The leading thinkers in Business Continuity Management advocate taking a program approach. Such an approach involves an ongoing effort that builds continuously on the previous years' efforts.

By following a program approach, a Product Manager can tie together all the necessary and disparate efforts — product design and development, marketing, sales, delivery and service — into a unified whole. By driving a program, a Product Manager can overcome some of the barriers to reaching common and very important Product Management goals.

Read on for an introduction to the program approach to Product Management.


The Downside of Flexibility

Having a flexible approach to the Product Manager role at a company may be the single most critical ingredient to success. Each company's situation and product is different enough that using an overly dogmatic or rigid approach can be counterproductive. Having long touted the benefits of — actually, the necessity for — flexibility in Product Management, I can see its downsides.

The main downside is that taking an automatically flexible approach right from the start can lead a Product Manager to give up too much in an effort to compromise. If the assumption is that Product Management is going to have trouble getting buy-in from Development for a specific and structured approach to product design and development, then the expectation right up front is that Development may very well get its way when it resists basic improvements.

The other problem with flexibility is that new approaches, once implemented, may continue to be viewed as candidates for pushback rather than as established approaches for Product Management. The soft approach to implementing them, with lots of consultation and consensus, may mean that everyone considers them fair game for modifying or scaling back with each new go-round. Therefore, the very flexibility which is so vital to a Product Manager's success may lay the groundwork for ongoing resistance to the Product Management initiatives.

The Problem With Projects

The flexible approach leads a Product Manager to apply many best practices and techniques to address specific needs. The Product Manager works to stabilize and manage the development cycle, to structure the design process, to develop sales and marketing tools, to collect requirements, and to fill in wherever a significant gap is holding back the product. Most of these efforts take the form of projects.

The problem with projects is that they are a once-and-done effort. When they end, there is no thought given to whether they need to recur, and when. If the development of a sales tool is completed, and nobody thinks about when that tool needs to be revisited and refreshed, Product Management has to sell the idea all over again when the time comes around to work on it once more. The Product Manager doesn't just have to sell the idea, but line up the resources and define the effort anew. When Product Management work is done as a project, very little momentum builds over time. Worse, the natural resistance to change builds up all over again between projects.

Product Management usually involves too few dedicated resources leveraging the cooperation and assistance of people who are not under its direct control. A Product Manager cannot afford to let resistance build or momentum peter out.

Business Continuity Management as a Role Model

The product I currently manage is a software tool for the business continuity and disaster recovery industry. This specialty finds itself in a similar predicament to Product Management. It is a specialty that is much more recent than many longstanding areas of expertise like Marketing or Product Development. Standard practices and understanding of the specialty vary widely from company to company. The industry is splintered, with individuals who focus on technology and hardware (disaster recovery, and those who focus on people and business functions (business continuity).

Doesn't this sound like Product Management? Even down to the product marketing vs. technical Product Managers?

Business continuity and disaster recovery professionals often find themselves struggling to accomplish a series of projects against a backdrop of resistance from those whose assistance is required. Consequently, a recent trend in the industry has been to advocate that disaster recovery and business continuity should be approached as a program.

What Is a Program?

What exactly does a program mean? How is it different from a series of projects? The key difference is that a program is an ongoing effort. It is considered a permanent and integral part of a company. Whereas Product Management is subject to becoming a mix of scattered efforts, a program is a holistic approach that ties together all efforts and activities, all strategies and techniques.

A program is a consolidated, overarching approach even when there are not enough resources to accomplish everything that a company wants. The fact that the program is ongoing, the fact that it is assumed that next year will see a continuation of this year's efforts, lets you take a multi-year approach to goals that is particularly suited to situations such as Product Management, where it seems there are never enough resources to accomplish the goals. A program lets those insufficient resources build on the prior year's efforts, accomplishing a little more each year.

A Program Approach and Flexibility

A program in no way precludes a flexible approach on the part of a Product Manager. And it's a good thing, too, considering most Product Managers have very little choice in the matter but to be flexible and accommodating. But a program, by installing an expectation of ongoing efforts, helps Product Management combat the resistance that tends to return from one development cycle to the next.

Flexibility will always have a place, but doesn't need to imply that methods and tactics are up for negotiation with each development cycle. Flexibility can be applied where it is most helpful, without undermining a Product Manager's existing progress.

The Program, Templates, and Artifacts

A program is not the same as best practices and techniques. Rather, these are independent of the Product Management program. The program ties together all efforts and techniques.

For individual efforts, Product Managers may apply best practices and templates to improve them. Product Managers use other artifacts, such as reports, charts, and documents that mark the milestones of a release. These artifacts are independent of the program. You have the flexibility to use and change these as you see fit, without changing the structure of the overall program, nor its cyclical nature and goals.

The Program and Momentum

The power of a program is that it builds on all the accomplishments completed before. Product Managers face a job that requires much more resources than they have, and they learn to make do with less. But with limited resources, Product Managers can tackle a portion of what needs to be done each year. And the next year, the program builds on the previous year's accomplishments. Many of last year's milestones and assumptions are accepted and do not need to be re-implemented. Instead, the Product Manager can take things a little further than they reached the year before.

A program approach lets Product Management keep up the momentum and build on it year over year. This is vital to improving your Product Management in a situation where additional resources are slow in coming, even with growth in the organization.

Programs and Progress

Because the program serves as a base of previous accomplishments upon which to build, a Product Manager can make more progress than their limited resources would suggest. The key is to have the whole organization expect Product Management to be a continuous and ongoing activity where a little more is accomplished each year.

To get a little more accomplished, you take the acceptance throughout the organization of the previous year's efforts and ask a little bit more of teammates in terms of cooperation and effort. This is the same model as all Product Management efforts where the Product Manager serves more as a coordinator, facilitator, and director. But the program approach helps you make progress each year, so you don't end up climbing the same hill with each release cycle.

A Shift In Priorities

A program approach leads to a shift in priorities, and a change in perspective. A Product Manager's focus moves from the activities themselves towards the definition of a mission for Product Management, efforts to obtain buy-in from management and to get everyone on the same page and pulling together towards the same goals. A program also focuses on effecting a change in the company culture so that Product Management is adequately understood and automatically incorporated in all applicable activities.

As you can imagine, a program approach is a very different undertaking than simply applying best practices and using great techniques.

Ongoing Program, Ongoing Advice

For a Product Manager who is experienced in methods and techniques, the concept of a Product Management program represents a significant new subject area to master. Just as a program is ongoing, my effort to write about this topic will be ongoing. Later articles will cover more aspects of this concept, including how to implement a program, and more detail about what a program entails.

The program concept is very powerful and highly applicable to Product Management. It may offer success where that has eluded Product Managers so many times before.

— Jacques Murphy, Product Management Challenges




Comments are closed.