Product managing your digital presence: defining the work program

Any digital presence implementation with a large number of stakeholders will generate far more requests than could ever be implemented.  So how do you determine what gets onto the work program and then implemented? 

One key element is to have a work program that is updated, implemented, and reported on in a routine, regular schedule (the work program is one of many cadences of change in a digital presence). For example, perhaps you publish a new work program every quarter. Having a routinely-published work program allows you to more methodically react to changes than being completely ad hoc (of course some change needs to be fast). 

There are several streams where potential features could get added to the system:

• User requests (either internal or external)

• Stability / security

• Performance / scalability

• Hardware / infrastructure

• Long range requirements

So even an important user request may not make it onto your near term work program if, for example, there is a severe stability issue that needs to be addressed quickly.  So there is something of an air gap between the requests coming in and what winds up on the work program.  This is one of the most important roles of the product manager, and the product manager needs to consider the following factors.

Backend needs

As mentioned above, key security, scalability, performance, or manageability issues may trump any other requests.  Notably, these may be items that your key stakeholders may not be aware of, much less actually requesting them.

Batching

Your near-term work program needs to be consistent, meaningfully grouping changes.  This is both for communications and technical reasons.  From a communications perspective, if the items being addressed are consistent then everyone can quickly understand what's happening.  From a technical perspective, if you need to completely rewrite a subsystem to address and issue then it might make sense to address many of the issues with that subsystem at once. 

Resource constraints

Obviously you need to have the resources to implement your work program.  This is both for a raw number of hours as well as balancing key resources.  For instance, if your DBA is required for many requests then you may be able to only do some DBA-limited requests at once.

Popularity

Of course, the popularity of a request is very important, but, again, not the only factor).  All other factors being equal, a more popular item should be placed on the work program before others.  In practice, it may make sense to delay your top-requested feature in order to address the next three (for instance if the next three could be implemented in the same effort as the first).

Note two factors that are NOT listed as factors:

• a group being willing to pay for certain functionality

• the length of time that an issue has been discussed

In the end, the product manager must be able to justify the work program to the stakeholders.  Although clearly more of an art than a science, the factors (and non-factors) should help in forming that solid work program.