The Key To Product Management When Developing Software

Too of­ten a busi­ness owner or ex­ec­u­tive will as­sume the role of prod­uct man­ager with­out an­tic­i­pat­ing the time in­vest­ment re­quired. This leads to one of the biggest risks when de­vel­op­ing soft­ware - poor prod­uct man­ager en­gage­ment. Poor en­gage­ment halts de­vel­op­ment and re­stricts your team’s out­put. A de­vel­op­ment team can only move as fast as a prod­uct man­ager al­lows. So as a busi­ness owner or ex­ec­u­tive, the first ques­tion you must ask your­self is whether you’re able to com­mit the time needed to be a prod­uct man­ager. If not, the next step should be to ap­point a pro­ject man­ager ca­pa­ble of act­ing as the pri­mary point of con­tact.

Why is a Product Manager Needed?

Agile soft­ware de­vel­op­ment fo­cuses on mar­ket feed­back. This re­quires some­one (usually given the ti­tle prod­uct man­ager) to test the soft­ware in the mar­ket and seek user feed­back. Once com­pleted, that feed­back needs to be com­mu­ni­cated to the soft­ware de­vel­op­ment team so that any nec­es­sary changes can be made. The prod­uct man­ager is­n’t only re­spon­si­ble for test­ing the prod­uct in the mar­ket, they over­see the en­tire pro­ject.

This be­comes crit­i­cally im­por­tant dur­ing the Scoping phase. During Scoping you will need to trans­late those awe­some ideas that are in your head, onto pa­per. The prod­uct man­ager must be able to share that vi­sion. It would be great as de­vel­op­ers if we could stick a USB into the prod­uct man­agers head and down­load their vi­sion. Unfortunately this is­n’t (yet) pos­si­ble. So in­stead, we use Scoping work­shops to clar­ify the goals of the ap­pli­ca­tion. It’s crit­i­cal in soft­ware de­vel­op­ment to have a clear ac­tion plan be­fore com­menc­ing any de­vel­op­ment work.

Attributes of a Product Manager

As a prod­uct man­ager you should have three key skills. Firstly, a prod­uct man­ager must be able to pri­ori­tise. There may be a clear end goal of what an ap­pli­ca­tion will look like, but ag­ile stresses the im­por­tance of in­cre­men­tal de­liv­ery. From that pol­ished fi­nal prod­uct, what are the most im­por­tant com­po­nents to be de­liv­ered first?

Even af­ter the first ver­sion is re­leased pub­licly, a prod­uct man­ager will still need to pri­ori­tise which fea­tures re­quested from the mar­ket are the most im­por­tant. We use a re­quire­ments back­log to man­age and pri­ori­tise a pro­jec­t’s fea­tures.

A prod­uct man­ager should also be ac­cus­tomed to set­ting goals. Setting goals al­lows us to form our de­liv­er­ables. At the com­ple­tion of each de­liv­er­able, a re­lease is per­formed, en­abling you to con­duct your UATs. If you’re set­ting goals, you al­ready know what you want to achieve with each de­liv­er­able thus giv­ing you a roadmap to fol­low.

Finally, and most im­por­tantly a prod­uct man­ager needs to be avail­able. An ag­ile de­vel­op­ment team can’t con­tinue with de­vel­op­ment if they’re wait­ing for a prod­uct man­ager. Often this be­comes an is­sue dur­ing user ac­cep­tance test­ing (UATs). We re­lease into a beta en­vi­ron­ment while prod­uct man­agers con­duct their UATs. After that time, we make any nec­es­sary changes and de­ploy to a pro­duc­tion en­vi­ron­ment. We can’t de­ploy to a pro­duc­tion en­vi­ron­ment if we’re wait­ing on the prod­uct man­ager. The is­sue is usu­ally cen­tered around work­load. The prod­uct man­ager is not able to ded­i­cate time to the de­vel­op­ment of the soft­ware due to ex­ist­ing com­mit­ments.

For every part­ner, we pro­vide the prod­uct man­ager with a copy of our white pa­per so that they are in­formed of our process. Software de­vel­op­ment is a two way street so we take re­spon­si­bil­ity for ed­u­cat­ing and en­abling our part­ners to make in­formed de­ci­sions. Click here to down­load a copy of our white pa­per.


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call