Guiding Programs by Product Goals

A term that I use when describing product goals that are tangible and drive program decisions is “Product Asset.”

A Product Asset is “a fundamental attribute of a product that can be characterized as a quantitative measurable goal.”

The five Product Assets that I commonly select are the following:

technology features
reliability/quality
time to market
product cost
development program cost (considered an anchor asset)

Here’s what qualifies a Product Asset:

It must be a predetermined product or program characteristic.
It must be quantifiably measurable.
It must require company resources.

Development program cost

I tagged development program cost as an anchor asset because it will be used as the translating variable among the other product assets.

Development program cost is defined as “the investment a company makes to implement or create the deliverable product or service.” It is typically budgeted and tracked and can be measured in dollars.

Program cost is the tangible form of the third qualifier of a Program Asset (i.e., requiring company resources).

Product asset goals

Product Asset goals are often set in the initial stages of a program by marketing and upper management (e.g., a shelf price of $12.95, a release date of 10/5/2018, includes Bluetooth, has an auto sleep mode, has a touchscreen, or demonstrates an 80% confidence for 98% reliability at release through testing).

As many can attest, these goals are set and then adjusted throughout the program; for example, shelf price now has to be $10.50 to be competitive, redesign has pushed us out to a delivery of 2/15/2019, no touch screen can be implemented at the $10.50 price point, and we aren’t doing enough testing to demonstrate a 50% confidence in the reliability goal because of the compressed schedule.

If these adjustments were coming from a vantage point that included the established program goals and intended destination they would be small course corrections along the journey that take all the Product Assets into consideration.

Impact of changed goals

The realization of the impact of these changed goals typically takes place a few months after release.

Maybe Web reviews begin to accumulate, pointing out the product’s poor reliability or how inconvenient it is without a touchscreen, angry customers are canceling orders, or the service team is chronically on the road.

The only program decisions that can be made at that point are “pull the plug” on the product or keep it limping along until a next-generation product can be put on the market.

Unfortunately, this will likely be done using the same development methodology, starting the whole cycle over again.

Focus cycling process

A method I like to use to keep these Product Asset goals directing key decisions throughout the program is “Focus Cycling.”

The Focus Cycling process begins with introducing the team to the project Product Assets at kickoff.

This means that they have been selected, documented, and communicated as measurable metrics and goals. Each week one of the product assets is the “Focus Asset.”

For the week the selected Focus Asset is brought up at the beginning of each regular reoccurring project meeting, design review, Exec reviews, etc.

It is mentioned again at the end of the meeting to observe whether anything discussed in the meeting affects the asset. If there is nothing to expand in reference to the asset, then a total of 10 seconds was invested in the exercise.

If the Product Asset current status or goal is related to what was discussed, then a great opportunity has arisen for a small course correction or confirmation that we are on track.

The following week another Product Asset will be in the spotlight. The Assets are cycled through allowing each asset to be given direct attention at a frequency of approximately once a month.

Throughout the program, many slight steering corrections will be made with this method.

This is a great alternative to a sudden and large correction late in the program that arises from a sudden awareness of being far off course.

3 Elements of Reliability Goal Setting (article)

When is the Best Time to Establish Reliability Goals? (article)

Guiding Programs by Product Goals (article)