There are so many tools and methodologies that do everything from product lifecycle planning to business process management and a lot of other tasks in between. Some appear to be helpful (if you can believe the salesperson); others seem to have been developed as a science project to see how much one company can charge for the least amount of value.

I have found some simple, yet useful tools that help PMs more easily break down and understand a project’s elements so you’re better prepared to prioritize tasks, features, or functions. Many of these tools have been used for years by themselves, but when you use the tools together, you often get very powerful results. I used these tools to address the complex problem of quantifying qualitative data.

I’m sure I couldn’t throw a nickel into a crowded room without hitting someone who has taken a survey at one point in time. (“Circle the most appropriate where 1 is least likely and 5 is most likely to solve all of your problems.”) But many of these scaled surveys need to be designed in a particular way to focus on an emotion, an intrinsic value, or a personal perception of the survey taker to try and glean some new insight that is going to make my product better than your product.

On the product development side, the team starts listing out all of the features and the functions of the envisioned product (“The Widget must do X, Y, and Z”). This is usually best done with a brainstorming session where there are a bunch of stakeholders in the room and the environment is such that everyone has equal input. This means the facilitator must push back on the steamrollers in the group and encourage the more shy members. The power of the brainstorming session is that ideas build off of other ideas, and you begin to capture a lot of great ideas on the product. Part of this process is to rank the features and the functions (this can be on a 1-5 scale). It’s important for everyone to have a functional understanding of all of the features and know where the features fit into the big picture.

You can use an Ishikawa or a Fishbone diagram here to make sure all of the cause and effect scenarios are hammered out, although many times, you can use an Affinity exercise to begin linking the product development team’s ideas with the customer’s desires.

First, you gather raw data from both the customer and the product development team; in addition, both sets of data are scored as far as importance to the product. With the Affinity exercise, I have used multi-colored stickies, where one color represents the customer survey data and another color represents the results of the product development team’s brainstorming session.

Basically, we have all members of the product development team go up and start grouping the stickies. The grouping is not scripted; there is some element that ties the items together as interpreted by each team member. There is no need to try and create artificial groups.

The first round typically has a few large groups and several smaller groups. At this point, the facilitator tries to functionally define the groups with the assembled team members. This usually helps to blend the team’s way of doing things with how the customer sees the company’s product. In essence, the group has created a functional definition of natural groupings that both the customer and the team member understand.

The smaller, outlying groups serve an important purpose: Any group of stickies that are made up of just the customer’s sticky color shows an unanswered desire or need on behalf of the customer. For the reverse situation (i.e., a group of stickies that are made up of just the product development’s sticky color), the team has discovered a group of features or functions that do not associate with a customer need. Because each of these items have been ranked or scored, the item importance can tell you how much work should be involved in making sure the smaller groupings are addressed appropriately.

One example that I have seen is a group of the product development team’s stickies were ranked very high but were not associated with customer needs or desires. The group interpreted this as:

  • A new strategic direction of the product that, based upon technology trends, social trends, etc., the team believes the product needs to head for longer term viability.
  • The customer does not associate our product or our company with the direction we want to take the product.

This is a key point of alignment. The team then needs to decide if this is just something the customer did not anticipate but would appreciate, or if the items, features, or functions should be developed into a separate product or an add-on for an additional charge.

Regardless of the team’s decision, the exercise accomplished these three things:

  • It prioritized the requirements in a customer-aligned manner using scores and rankings.
  • It presented opportunities for further research into new lines of business, different markets, or product placement.
  • It helped to functionally define the goals of the project and the product for the entire team due to their active participation in the process. This is the best form of communication because now the team understands the product from many more angles than they would have otherwise.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!