As compared to other domains of knowledge, computer science has a very privileged position in the world today. Software has become so pervasive that very few companies can survive without having a software-avid person in an important position.
For most of the soon-to-graduate computer science PhDs, this means that towards the end of their university phase one can start to think -if not dream- of what particular domain one would like to contribute to, and in which role.
The range of domains is very extensive, from A as Aerospace (think SpaceX) to W as Wine (think of those IoT sensors), but that is a matter of another article. The set of possible roles, in contrast, is more limited (in particular without having industry experience).
Still, there are many options: it is common to join a startup and exploit development skills; to take a more specialized role as defined in modern software development methods, like a scrum master or a release manager; or to go for a consultant position.
And so it was that in my case I set off to take a Product Owner (PO) position. In this article I discuss the what’s, why’s and how’s of becoming a PO after a career in academia.
The What
Just to be sure that we’re on the same page: the PO position is a role in the agile world. In a nutshell, the PO is an entrepreneur for his product or service, tasked to maximise the value of the product created. For the specifics, go check out the scrum guide and other articles here.
The Why
An important motivation for pursuing this role is the variety of tasks that you’re confronted with: as a PO, you address business-specific challenges with problem-solving technological building blocks. In some cases, these building blocks are familiar to you because you’ve even taught related concepts in labs or seminars during your PhD.
Furthermore, the PO is a role that requires interfacing the product’s stakeholders (customers and users) with experts in multiple disciplines (design, QA, user assistance, marketing, legal, sales, and of course DevOps!). While not all PhD projects are as rich or varied as this, I was able to observe this in many former colleagues’ projects. For me in particular, while conducting research on sensor networks, it was necessary to approach a multitude of people to discuss research goals and benefits (cf. product value), evaluate alternatives (analyse risks), delegate work, e.g., to students (define the sprint backlog), set up experiments and labs (defining a development environment), publish and present the results (marketing), apply for research grants (request funding), etc. As a result, it felt a natural jump for me to take this position, and I am certain that others will not hesitate there either.
Another reason for the good PO-PhD match is the level of responsibility required for the success of the product. I translate this as being able to do everything it takes in order for the product to thrive in the market. This entrepreneurial spirit is also commonly found in successful PhDs: this “can do” spirit is required to put together the large amount of research work into a final package, submit it, and defend it.
The How
As a fresh PhD, it is common that certain industry experience in the software business will be lacking -at least as compared to other seasoned company employees. When starting a brand new product, it might be acceptable to jump straight into the PO role. In the case of joining a team of an existing product, I would rather advise to first accompany someone in the PO position until the mechanics of the process (Scrum, Kanban, etc.) are understood. I had a good time indeed working initially as a developer and then as Scrum Master for a team prior to switching to a PO role.
While reasoning about the role, it became clear to me that the set of skills necessary for the function are not set on stone or taught in a particular curriculum. There is good training material on the net, or even better classroom training, that describes the mechanics. You can definitely train on-the-job to complete these.
However, I heard once from Jeff Sutherland that “scrum is like the rules of soccer: following them does not make you a good player.” There are a bunch of little skills necessary to carry out the PO task efficiently, which can only be learned through practical experience. The degree to which these (sometimes soft) skills will be in your pocket as PhD can vary depending, e.g., on your interests. These are super important for prospering as PO! If you are in a mid or large enterprise, look for reference idols that drive successful products, chances are that you find some. If not, however, you could consider contributing such profile definition for your organisation yourself. This will help others understand better what your purpose is.
Reflection
A bit more than a year passed by since I formally took the PO position in a team at SAP (we have actually recently launched the first version of our product as an incubation release). These are some thoughts from comparing my day-to-day to the “PhD times”:
- Managing perfectionism. When starting the PhD research, a natural ambition is to imagine that all will be finished with perfect results. However, soon candidates realize that some questions must be left out of the scope of the thesis, and the milestones be negotiated with your advisor or evaluating committee. This not at odds with being a PO — by the contrary, a common ability required, e.g., during the quarterly prioritization, is to align with stakeholders on what can be released within scope or budget and what needs to be considered in the future roadmap for their expectations to be met.
- Building consensus with the team is hard. The quote “a well defined problem is a half-solved problem”, which is critical in research, e.g., when defining the problem statement of a paper, is equally important as a PO: crafting carefully the backlog items that the team incorporates into the sprint backlog helps to build consensus much faster, and thus deliver value much quicker.
- No time to code: as a full-time PO, many things land in your desk which prevent you from coding. A lot of times I get the question of whether I miss coding, and the answer is a definitive yes! In particular, I lack the time to learn new programming languages. For a PhD with a background on software engineering, I can state that it is feasible to lead the product to success without meticulously knowing the inner details of the code. I do invest time in code reviews, though, which most times helps me personally to improve my knowledge, and only in some few cases to improve the quality of the releases :)
The final question of the article is whether this role is right for you. As mentioned at the beginning, as knowledge workers we are in a very privileged situation where we can afford to switch roles to a variety of other positions if desired. In my transition I’ve made a lot of experiences, some in the easier way, some in the more rough way, but I surely enjoyed the journey, and encourage others to try!
Have you also moved to a PO position after your PhD?
Notes:
- I’d like to thank for the feedback and suggestions from the early reviewers of this article, including former colleagues at the TU Darmstadt; Dr. Stephan Aiche from SAP; and also Mike Cohn from Mountain Goat Software.
- I need to amend myself by stating that I have a german engineering doctorate degree (Dr.-Ing.) and not a PhD, but I believe that many of the observations in the article apply to both forms of academic work.
- This article reflects my personal views only, and not necessarily the views of my employer_._