A product owner is a specific role in an Agile process. This person keeps careful track of the parts of the app that need to be built (called the backlog) and helps determine which tasks need to be performed, which developers will work on them, and how long they will take (typically, teams engage in two-week “sprints”). They also provide updates to the product stakeholders.
Perhaps the most important role of the product owner is to represent the customer or end user for the team and the company as a whole. This will ensure the team builds a product that the end users need—one that is intuitive, friendly, and does only what the end user needs and no more.
A product owner isn’t the same thing as a product manager. The latter oversees the schedule and who is working on what, but doesn’t usually provide that vital end-user perspective.
But in reality, many organizations (especially the smaller shops) simply don’t have the budget to hire separate product managers and product owners. Instead, one person will fill both roles. Bear that in mind when you’re applying for positions. Look closely at the job descriptions, as sometimes the job titles “product owner” and “project manager” are used interchangeably, even though there is a technical difference.
Learn Agile and Scrum
First, learn Agile. Agile is really more a philosophy of how to build software, as put forth in the original Agile Manifesto. Agile itself doesn’t provide any specific rules or processes on how to build software. For that, people have developed methodologies based on Agile, a current popular one being Scrum.
Scrum is a specific set of processes a team uses as they build a software package from the beginning until the first release, then the next release, and so on. It uses Agile concepts whereby a large task (building a complete first version) is broken up into a logical sequence of much smaller tasks.
Learning Scrum is no small task. You will want to take an online course on it, and perhaps even pick up a book about it. Just make sure any book you buy is relatively new, written within the past four or five years.
Learn How Sprints Work
The sprint is the fundamental “chunk” of software development that takes place over a small time frame, typically two weeks. This is where developers work on individual features or parts of code, with an eye toward completion within the two-week timespan. Usually (but not always) each developer is tasked with a separate feature to work on.
Organizations can choose the length of their sprints, but two weeks is by far the most common, as it provides enough time for developers to work on small features, test them, and integrate them into the application. It also forces the team to break apart the needed features into small, detailed, highly-specific elements.
What about a feature that can’t fit into two weeks? Then most likely it needs to be broken down into smaller pieces that can fit into that time span. There will still be cases, however, where a feature isn’t completed in two weeks, in which case it will continue for a second sprint. But in general, you want your tasks with fine enough granularity that they fit into a “standard” two week sprint.
Know Your Boundaries: Learn About Scrum Roles
As part of this process, you’ll need to learn the different roles of Scrum so you’re aware of the boundaries of your position. One other such position is Scrum Master, a person you would work alongside.
Learn Kanban
Kanban is a method of managing projects, similar to Scrum, but with a heavy focus on visual ways of plotting out projects. Kanban can be used for virtually any project, not just software.
The visual aspect of Kanban is known as a Kanban Board. Imagine a physical whiteboard with Post-it notes on it. You would use a dry-erase marker and draw columns with header names such as ‘backlog,’ ‘in progress,’ ‘completed,’ ‘not doing.’ You would write each small task on a Post-it note. Once a task is started (at the beginning of a two-week sprint), you would place that task’s Post-it under ‘in progress.’ After the developers finish that task, you would move it to ‘complete.’ (Then imagine software that accomplishes this; we talk about that in the next section.)
Although Kanban is more than just a board showing tasks, that’s perhaps the most important part. Scrum has its own way of organizing tasks visually, but many Scrum teams prefer the Kanban approach, resulting in a Scrum-Kanban hybrid process.
Tip: First learn Kanban boards, as they’re used more often. Then learn Scrum boards just in case you’re hired on a team that uses them.
Learn Agile Software
Essentially, this is a virtual version of the whiteboard we mentioned above. There are several software packages Agile teams use for managing their projects, and most use Kanban-style visual representations; most also run in the browser. Trello and Jira are two of the most popular and they both offer free plans. If you’re going to start with one, however, we recommend Trello, as it’s somewhat easier to learn. But you’ll want to learn both for your resume.
Should You Learn Coding?
You definitely do not need to know coding to be a product owner. Across the industry, most product owners don’t know coding and have no desire to learn it. If you do choose to learn coding, you’ll want to make sure you recognize that the reason isn’t to help the developers write code, but simply so you can understand some of the “tech talk” that takes place in meetings. But this is by no means a job requirement.
Learn the Tech Fundamentals
Although not technically required, you’ll want to make sure you have at least some knowledge of the different technologies incorporated into the project. For example, the database is where data is stored, and often databases use SQL. As for details beyond that, you really don’t need to learn much more.
(And if you’re interested in extensive learning, take a moment to ask yourself why. Are you hoping to move into a different career path? You won’t need the skills for the product owner position, and technical positions such as software developer or data engineer are generally not upward career paths from product owner.)
That said, a few technologies to understand in a top-level way include:
- Different types of databases, such as SQL and NoSQL, and the different brand names (such as MySQL, Oracle, SQLServer, and MongoDB).
- Programming languages such as Java, C# (pronounced see-sharp), JavaScript (which has no relation to Java), Python, HTML, and CSS.
- The cloud and its components, such as server instances (essentially just a computer running in a data center), cloud databases, and so on. You might also learn about the big cloud providers, such as AWS and Azure, and what services they offer.
Again, just familiarize yourself with these. There’s no reason to download and install the tools and learn them… unless perhaps product owner isn’t the job you really want.
But DO Learn the End User
One of the product owner’s most important roles is to help put together what are called “stories,” which are descriptions of product features from the perspective of the human that will be using the software. We cannot emphasize that last part enough. For example, one way to describe a feature might be, “Retrieve user profile data from a SQL database and present it to the user after they log in.”
But that’s not the perspective of the user, who will have no view into the database itself. Instead, present it from strictly the user’s perspective: “After the user logs in, they will see their profile information such as username, address, and phone number.”
The reason this step is so vital is because the software industry has a long, unfortunate history of being difficult and even mean towards the end users. If you build something that end users like, they’re more likely to stay your customers for a very long time.
Conclusion
Product owner is not a simple job title. It’s an entire career that takes a good amount of time to learn. Always keep in mind that the most important aspect of the role is to make sure the team builds what the user wants and needs.
Related Product Owner Jobs Resources:
