The Responsibilities of a Successful Product Owner


Every soft­ware pro­ject be­gins with a vi­sion. Now, that vi­sion could be based on a gap iden­ti­fied in the mar­ket or a pain point that is felt within your busi­ness. Often, the suc­cess sto­ries that be­come em­bed­ded within our every­day lives (Uber, Airbnb, Xero) fo­cus on the big vi­sion. What we aren’t told about is the hun­dreds (possibly thou­sands) of small de­ci­sions made by a prod­uct owner that de­ter­mined whether the soft­ware suc­ceeded. This ar­ti­cle will fo­cus on the role of the prod­uct owner and the com­mit­ment re­quired to per­form the po­si­tion.

Firstly, it’s im­por­tant to draw a dis­tinc­tion be­tween the prod­uct owner and the busi­ness owner. In some cases these two roles may be per­formed by the same per­son. But they are two dis­tinctly dif­fer­ent roles. Where the busi­ness owner fo­cuses on fi­nan­cial and growth met­rics, the prod­uct owner is solely fo­cused on the prod­uct.

It is crit­i­cal that the prod­uct owner is a sin­gle per­son. If there’s one point you take away from this ar­ti­cle, let it be that. While there may be many stake­hold­ers or col­lab­o­ra­tors in­volved in the pro­ject, there needs to be a sin­gle voice that dis­tils stake­hold­ers feed­back and in­structs the de­vel­op­ment team. The role of the prod­uct owner is a near full-time role. If you’re con­sid­er­ing start­ing a soft­ware pro­ject and al­ready per­form the busi­ness owner role, con­sider whether you have the time avail­able to also be the prod­uct owner. We’ll out­line be­low the re­spon­si­bil­i­ties and time com­mit­ment re­quired at each stage.

Product Owner Role Description

The key role is to en­sure that items be­ing de­liv­ered are pro­vid­ing max­i­mum value pos­si­ble to the or­gan­i­sa­tion. This means hav­ing an in­ti­mate knowl­edge of the prod­uct back­log and the or­gan­i­sa­tions goals. A great prod­uct owner will al­most be­come a part of the team, their suc­cess is highly tied to the suc­cess of the de­vel­op­ment team.

While it’s im­por­tant to be that li­ai­son within the or­gan­i­sa­tion, it’s equally im­por­tant to un­der­stand the needs of the end users. Before you be­gin build­ing the prod­uct, this means set­ting up in­ter­views and hav­ing those con­ver­sa­tions with users. It’s im­por­tant to en­sure you’re acutely across the chal­lenges they are fac­ing and how your prod­uct can help them. Once the prod­uct is re­leased, this means mon­i­tor­ing the an­a­lyt­ics/​us­age of the ap­pli­ca­tion and mea­sur­ing its value.

The re­spon­si­bil­i­ties and com­mit­ment re­quired from a prod­uct owner does change based on the stage of the prod­uct. We’ll break down the stages as they’re out­lined in the Way of Working.


The pri­mary re­spon­si­bil­ity of the prod­uct owner dur­ing the Brief stage is to val­i­date the prob­lem state­ment with the tar­get au­di­ence. This means en­sur­ing that the soft­ware built is seek­ing to ad­dress a pain point, and a num­ber of peo­ple ex­pe­ri­ence that pain point. A prod­uct owner should be look­ing to ded­i­cate 1-2 days to this.

During the en­gage­ment with WorkingMouse (or an­other de­vel­op­ment com­pany), the prod­uct owner is ex­pected to at­tend the Brief meet­ing as well as a re­view ses­sion. During these meet­ings, the prod­uct own­ers ex­pe­ri­ence within the in­dus­try and knowl­edge of the or­gan­i­sa­tions goals and ob­jec­tives are crit­i­cal to de­vel­op­ing the prob­lem state­ment and the suc­cess cri­te­ria. This gen­er­ally re­quires a 3 hour com­mit­ment.


During Scoping, the prod­uct owner is ex­pected to at­tend every scop­ing meet­ing. It is crit­i­cally im­por­tant for them to be pre­sent to give feed­back and help guide the prod­uct suc­cess team. In ad­di­tion, they are re­spon­si­ble for con­nect­ing the team to users for in­ter­views. The time a prod­uct owner gen­er­ally spends with WorkingMouse dur­ing scope is 5 hours per week. This lasts for 2-4 weeks (depending on the Scope length).

Outside of the time di­rectly spent with WorkingMouse, a prod­uct owner is ex­pected to com­mu­ni­cate and fa­cil­i­tate with other stake­hold­ers within the busi­ness. As men­tioned above, it is im­por­tant to have a sin­gle voice to make de­ci­sions. But it is equally im­por­tant to un­der­stand that within an or­gan­i­sa­tion a prod­uct im­pacts many other ar­eas, whether it be at a C-suite level or em­ploy­ees ex­pected to use the soft­ware. So, the prod­uct owner must ded­i­cate time to com­mu­ni­cat­ing with other stake­hold­ers, dis­till­ing the in­for­ma­tion and pre­sent­ing the most rel­e­vant find­ings to the de­vel­op­ment team.

Tough ques­tions are asked dur­ing the pro­ject scope. The prod­uct owner should be pre­pared to an­swer these dif­fi­cult ques­tions to feed into the de­sign and de­vel­op­ment of the prod­uct.


As the pro­ject pro­ceeds into de­vel­op­ment, the prod­uct owner is ex­pected to be the con­sis­tent at­tendee to all scrum cer­e­monies (planning, re­view and UATs). These are on av­er­age a 4-5 hour com­mit­ment every fort­night. UATs should be com­pleted in ei­ther a ded­i­cated ses­sion or by al­low­ing 2-3 hours each fort­night.

Perhaps the most im­por­tant re­spon­si­bil­ity dur­ing de­vel­op­ment is to cham­pion the back­log. As with any ag­ile soft­ware pro­ject, pri­or­i­ties change as you make learn­ings. It is the prod­uct own­ers re­spon­si­bil­ity to en­sure that the back­log rep­re­sents cur­rent pri­or­i­ties and as such is an ac­cu­rate re­flec­tion of your plans for the prod­uct. If there is a pain point that is es­pe­cially time-sen­si­tive, en­sure that is com­mu­ni­cated to the squad lead and mod­ify the roadmap/​back­log ac­cord­ingly.

Additional re­spon­si­bil­i­ties in­clude:

  • Follow up on ac­tion items com­ing from meet­ings and dis­cus­sions.
  • Respond as promptly as pos­si­ble to squad lead/​de­vel­oper re­quests - gen­er­ally these are block­ers and could re­sult in lost time for your pro­ject.
  • Ensure all stake­hold­ers are up­dated on progress and de­ci­sion points, the de­vel­op­ment team treats you as the source of truth.


As the prod­uct is re­leased and tran­si­tions into sup­port, the prod­uct own­er’s re­spon­si­bil­i­ties change. Rather than work­ing in­ti­mately with the de­vel­op­ment team, they are in­stead work­ing closely with users. When the prod­uct can be tested in the mar­ket or within the or­gan­i­sa­tion, we max­imise the amount of learn­ings that can be made. It is the duty of the prod­uct owner to doc­u­ment these learn­ings to feed back into fu­ture de­vel­op­ment.

The pri­mary re­spon­si­bil­ity is to log and mon­i­tor any is­sues or en­hance­ments through the ser­vice desk. It is im­por­tant to give the sup­port team as much in­for­ma­tion as pos­si­ble when deal­ing with bugs so they can repli­cate and fix any edge cases that have been found. We be­lieve it’s im­por­tant to pro­vide train­ing on how to log a well-doc­u­mented sup­port ticket. If the sup­port team have queries about repli­cat­ing the bug, it’s im­por­tant for the prod­uct owner to be avail­able to han­dle these.

It is also nec­es­sary to con­duct user ac­cep­tance tests and fol­low the same re­lease process dur­ing sup­port. As a re­sult, many of the re­spon­si­bil­i­ties from de­vel­op­ment carry over into sup­port.

In Summary

  • Ensure there is only 1 prod­uct owner,
  • Treat it like a full-time po­si­tion,
  • Develop a strong re­la­tion­ship with the de­vel­op­ment team,
  • Upskill where needed.

Discover Software


Yianni Stergou

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

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion