When I was offered a place on the graduate scheme at CDK the
most common question I was asked by my friends and family was (unsurprisingly),
“so what will you be doing?” At first I found it near on impossible to give an
answer: I could tell them all about the graduate scheme and that my first role
was a Product Owner, but nothing in addition to that because quite honestly, I
didn’t know myself. Coming from a background in Chemistry, I knew next to
nothing about the business world so had never come across the title ‘Product
Owner’ before. Five months into the role I have the opposite problem answering
the question: the difficulty now is explaining what I do without going into far
too much detail, so I’ve been refining my answer as I have grown to understand
the role more myself.
What it all boils down to is communication. I help to translate customer (or business) wants and needs into technical requirements so that development teams can deliver the required functionality. I help to define, break down and prioritize the work that needs to be done and ensure that the end result fits with the customer requirement.
This is carried out in different ways over the course of a sprint, and so the role morphs over time. Initially, a need is identified and broken down into small pieces of work (user stories) which need to be completed to get to the final product – much like when revising for exams you break down topics into sections so that the task is more manageable. In order to be effective each user story needs to have a clearly defined goal, and have acceptance criteria which can be used to determine when the work is done.
When preparing user stories I have found it is important to consider the following:
on ‘what’ not ‘how’
Something I struggled with when first coming into the role was that I knew the outcome I wanted, but had no idea how this would be achieved. Over time I came to accept this, as it is not my role to know exactly how the user stories will be completed – this is why I am a product owner, not a developer! That being said, developers aren’t magicians, so it’s useful to meet with tech leads and developers to make sure what I would like to see is possible, and gain a bit of understanding as to how it can be achieved.
When I become engrossed in a task, I often forget that I didn’t always know what I have found out, and so can inadvertently assume everyone is as much in the know as I am. Of course, when bringing a new idea to people they have no knowledge of it, so when writing user stories it is important to make sure you are not assuming prior knowledge. If I make the mistake of not being clear enough, this will generally come up in refinement sessions when developers and testers ask me questions and the stories can be edited so that they make sense to everyone.
A requirement which doesn’t automatically spring to mind is how the new functionality should work when it doesn’t work. For example what shouldn’t happen when the functionality is being used correctly? What should happen when it’s not used correctly? What would you expect to see if the functionality wasn’t working? This requires some thinking outside the box to come up with irregular scenarios that could happen and should be accounted for.
So now that I have successfully discovered what a product owner is and does, I look forward to moving onto my next role in March and finding a new answer to the inevitable “so what is it you do again?”.