In the previous issue, Fits and Starts: Creating Product Management at a Startup, I explained that Product Management is a custom solution every time. While it would be great if you could pick up the established methods and launch cycles that worked so successfully for you at a prior company, and plunk them down ready-made into your new environment, it is highly unlikely that such a cookie-cutter approach will work. There’s no getting around the fact that each new company, product, or team may require customizing the way you conduct Product Management in order for it to take hold and succeed.

If you have had to serve in a consulting role at any point in your career – implementation consultant, advisor to a project, person who has been called in to clean up a messy initiative, etc. – then you have had the experience that most consultants face at the beginning of every project. You must first convince the people you are called to help that you truly understand what makes their situation unique, that you appreciate the importance of their situation, their likes, dislikes, and goals, and finally that you are going to deliver a solution that takes all that into account. Only when it’s clear that you’re not planning to just dispense advice without tailoring it to the situation at hand will the inevitable resistance to your ideas begin to diminish.

You can probably point to some notable failures where the Product Manager didn’t wind up getting anywhere, despite ideas that in the absolute were good. You may even have been that Product Manager. Chances are those ideas didn’t take into account some critical component of the organization.

It is critical that you tailor the Product Management function to suit your current company, product, market, and team. Read on for tips on going about the process of developing a Product Management approach that fits the present situation and is therefore successful.

[private]

New Paint On a Jalopy

Before we begin this whole discussion, it would be off the mark to contend that all it takes is the right approach by a Product Manager to get a product progressing and give it competitive momentum. The nicest paint job on a car whose engine doesn’t run will get you no closer to where you want to go.

A company may very well have other deficits, failings that have nothing to do with the product, but which will prevent the product from succeeding. Insufficient strategy, direction, funding or execution in a major part of the company can prevent the whole team from reaching the goal.

It’s important to recognize that your efforts to improve Product Management will only succeed when the other key functions at the company are succeeding as well, and trying harder on the Product Management may not get you any results.

Flexing Your Methodology

If you have used Product Management tools and methodologies very successfully before, you are faced with a challenge. They may have worked very well in another environment, but you need to be prepared to modify them to fit the new situation.

It’s hard to let go of something that you saw work amazingly well for a past job. But there’s most likely nothing sacred about some of the approaches you took in the past that worked so well.

So how do you modify your methodologies without sacrificing what made them effective in the first place? Take a long, hard look at what the various tools and practices are meant to accomplish, and figure out what you can tweak and change without foregoing the central benefit.

Here’s a good example. I’m convinced that when it comes to developing new features, a development cycle of three months or even less is ideal. It gives the entire development team a clear focus and timeline, with the leeway to defer selected features to the next release, which can never be more than six months away, and is usually sooner than that at the point when you put off completing a capability.

But customers, especially a large customer base of an established product, could not possibly support a quarterly upgrade schedule. If only to give your customers breathing room to absorb new capabilities, you need a less frequent product release cycle. The ideal cycle for that is once a year, at the same time each year.

However, one year is a long time to keep developers focused and track progress. You may need to combine an external release cycle of one year with an internal development cycle that is on a quarterly or even more frequent basis (such as the month-long cycles so successfully used by Extreme Programming).

The Management Team

First and foremost in the effort to customize your Product Management effort comes the formation of a tight fit with the management team. You’ll need to work with all the functions – Sales, Marketing, Development, Professional Services, and more – to get understanding, agreement, and backing for how you want to proceed.

To create a good fit, the challenge is not so much the usual agendas, such as Sales not wanting to follow processes, Marketing not wanting to wait for new capabilities to be planned before touting them, or Development not wanting to agree that they’ll do something until it’s fully scoped and planned. The challenges are more along the lines of what the team considers an acceptable frequency for releases, or how much definition, analysis, review and approval is required for requirements.

To build an approach that suits the team, start by presenting your ideal approach for the release cycle, requirements, and product launches. Dig for concerns and objections, and determine which of those are based on outside influences beyond the company’s ability to control, such as industry and customer expectations, or dictates of the business model. Then make the appropriate changes and get the buy-in from the team.

For example, as a Product Manager you may want a standing product launch team that meets throughout the release cycle, with individuals representing each function that is touched by the product. (By the way, that would be every function at the company, including Legal, with the exception of the janitorial staff.) But you’ll probably get pushback from the management team. Some may not see the necessity for a permanent meeting rather than one that begins four to six months before an upcoming release and disbands until the same point in the next one. Others don’t want to see their staff spending time in the meeting. If the product launch doesn’t happen more than once a year, you may have to concede the point, though grudgingly.

You may find that you pare down either the span of time for the product launch team so that it’s only functioning six months or less for each release. Or you whittle down the membership at the meetings so as not to burden the schedules of specific individuals which the management team wants to spare. Someone from Finance may relay the information to Legal, for example (usually contract related issues). The Development representative may choose to represent Documentation and QA.

The Development Team

The Development team is the one that is most concerned by product requirements. If done right, the requirements process can help focus and drive their entire work effort. Since requirements determine what their job will be like, this is the area of highest interest to them. They especially want to make sure that they won’t be beset by unrealistic expectations or hard-and-fast deadlines without hard-and-fast requirements. They’re usually all for more structure and definition as long as that structure and definition applies all the way down the line.

Much of the effort to win over the Development team does not involve changing, it involves explaining, reassuring, and following through on commitments and promises to them, promises such as: “When you have a question that’s holding you up, don’t wait around, come see me and I’ll make sure I clarify it, and if I can’t give the answer, I’ll make sure to find out what the right answer is.”

But other components of your plan for Product Management may require adapting to the Development team. For example, the level of design details is going to depend upon the team members’ ability to use them or produce them. My bias is towards minimal design documents and technical requirements – just enough to understand what to do, without a lot of questions, and no more. But what to me is an empowering way to give developers the leeway to understand from Product Management what they should do but determine on their own how they will do it can be overwhelming for more junior level programmers. You may need to settle for more detailed design specs than you’d like to see the team spend its precious time on. That adds time to the release cycle.

The Development Manager

Without the support of the manager of Development, you won’t be able to control whatever release cycle and requirements process you want to put in place. Different managers run things very differently, and each one brings a unique mix of skills, methodology experience, biases, and preferences to the job.

So whatever release cycle you want to implement, you will need the agreement and active support of the person in charge of Development. This person is the one out of all the management team that you most want to win over. He or she is also the one who will be most impacted by anything you propose for the release cycle or requirements process. It is worth your while to focus much of your time helping clarify and talk through his or her concerns, and making tweaks and changes that will assuage any concerns.

(It’s always worth clarifying that the release cycle is not the development methodology or development cycle. The release cycle is the overall cycle for product launch. While Product Management controls the release cycle, Development controls the development cycle within that.)

Do you report to the person who manages Development? Then you face an unusually challenging situation. It’s important that the Product Management program you develop look beyond the circle of concern of Development and incorporate the priorities of Marketing, Sales, and Professional Services. You may need to prepare yourself for a selling effort that takes some time. You may need to accept certain limitations in year one and work to have those limitations eliminated in year two. For example, it may be difficult to get Development to give enough weight to the opinions of Marketing or Sales or top management for new capabilities that are functionally significant but not architecturally significant or challenging. One of the most important contributions you can make as a Product Manager working from within Development is to help create a channel that funnels such requirements to the department.

The Role of Visionary

The person who is the visionary for the product is usually a founder or the head of a startup. Other companies, no longer run by their founders, do not necessarily expect the CEO or President to be the visionary for the product, at least not at the level of detailed capabilities. Still other CEOs or Presidents choose not to be the visionary.

If you are a Product Manager hired in to a company that already has a visionary, it is your role to assist, rather than take the place of, the visionary. Your role as product champion cannot include much of the initial work of setting the product vision, perhaps not even refining and defining it. But you will be a critical contributor to its execution.

On the other hand, if there is no product visionary, Product Management supplies that role.

Schedules and Deadlines

From what I can see, Product Management can only benefit from fixed and predictable deadlines. The Product Manager gets credit (along with Development) for capabilities that come out as promised. Each promise met gives new credibility to your statement about future functionality.

But some organizations have a near phobia of deadlines. This is especially true of Development, which has often been blamed for not meeting fixed deadlines while being asked to work from a moving and expanding set of requirements.

Marketing, Sales, and top management may be afraid of fixed deadlines because that approach demands requirements be fixed, or added only at the expense of other requirements. So you may find yourself fighting the impossible battle to institute and stick with specific product release and launch deadlines. Your best bet at compromise is to get agreement on a somewhat looser timeframe, for example, create an initial schedule that finishes in January, but declare to the world that the release is due for completion sometime during the first quarter.

Another compromise is to stick with a certain length of time for a release – say, six months – but don’t commit to the same dates each year. Don’t say you will have a new version every May and October. That way, if one release slips one month, the next release is still six months after the actual release date. And the team begins to think in terms of six month cycles.

The Customer Thinks He’s Always Right

A set release cycle demands that new requirements from customers get submitted only for the next release, never the current one. Yet refusing a customer’s request for new functionality now is often beyond the ability or disposition of your management team. So customer requirements are allowed to modify and delay planned development.

One compromise is to still try for a first-pass review of requirements requested by customers to see which ones can wait until the next planned release cycle. You may still find that customers insist on certain features right away, but agree that others can wait and hence don’t disrupt current development.

The Requirements Process

Product Management works to bring a more defined and consistent approach to gathering, qualifying, and communicating market requirements to the organization. Ideally, the Development organization is poised and ready to pick up the requirements and begin design, planning, and development when you pass them the baton.

But you will probably find that each company has its own idea of just what information needs to be considered when categorizing, analyzing, and prioritizing requirements. Some have a very defined and numbers-based method to calculate ROI, while others are more concerned with software benefits.

As a Product Manager driving the requirements process, the key is having a structured process that is understood throughout the organization. The details of which information is tracked, whether prioritizing is complex or simple, and how criteria such as value and level of effort are measured, are just details. Accommodating Development and the management team on these details will provide them the assurance they need to gain confidence in the process.

You may not see the importance of a particular detail, but you are better off conceding on the details, especially if you manage to get the organization to respond positively towards a more structured and systematic requirements process, and respect and expect it.

Just like when a consultant tailors the approach to a specific company by adding a step to his or her project plan, while still achieving the same result, you may find that you need to add steps to the basic requirements process. For example, a company that sells as an OEM or through channels may feel that it’s essential to develop a completely thorough analysis of exactly which partners want each specific requirement. You cannot get away with knowing that one or two channel partners have asked for a new capability. Instead, you need to poll each and every one and have them prioritize the list of requirements for themselves.

This example is really just an added step to the same basic process, where you are aiming to have a consistent and thorough prioritizing of each requirement.

It’s Only a Success If They Use It

Just like a consultant’s advice, your contribution is only meaningful if it gets put to use. So the Product Management function is better off building its strategies and methods to fit the company and it’s limitations and preferences, if that’s what makes the difference between a resistant team or an accepting one.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]