This FAQ page grows as I discover the most important questions faced by Product Owners today.
Why do I care about this?
The methods and tools of product ownership help us transform our product vision into a reality by enabling us to work well with the teams that can help us get there. Check out my article What is a Product Owner to learn more.
My job title isn’t “Product Owner,” am I a Product Owner?
We’re seeing more and more companies adopt “Product Owner” as a role, particularly those interested in a project management framework called Scrum. Whether it is your official title or not, though, understanding the philosophy and toolkit of the Product Owner is necessary if you want to use a team to turn a vision into a reality.
If you’re looking to affirm and advertise your skills, you can get certified as a product owner by taking an exam. The two most popular certification organizations are Scrum Alliance and Scrum.org. (I have my Professional Scrum Product Owner certification through Scrum.org)
How do I get Certified as a Product Owner?
Product Owner is a term introduced to the agile software development community through a framework called “Scrum.” Two organizations offer classes and certification as a product owner.
- Based on the principles of Scrum and the Agile Manifesto, Scrum.org provides comprehensive training, assessments and certifications to improve the profession of software development.
- Scrum.org offers the PSPO I and PSPO II certifications as a product owner. It also has a list of organizations that have training, I did my own PSPO I training at Improving in Dallas.
- Scrum Alliance
- Founded in 2001, Scrum Alliance® is the largest, most established and influential professional membership and certification organization in the Agile community. We are a nonprofit association with more than 450,000 certified practitioners worldwide.
Is Product Owner Certification important?
That depends on what you want. Generally speaking, certification isn’t that important unless you’re looking for a job. That said, signing up for certification training and interacting with the communities online can be quite rewarding – I learned a lot from the class that I took, and the forum threads that I’ve read.
A LOT more people are certified as Scrum Masters than product owners. This is probably because the Scrum Master owns the process, so it a more important role when an organization is undergoing change. The best product owners don’t usually come from a technical background, so they may be given the role without really understanding the inner workings of Scrum as a practice. This is just personal speculation, though.
Is Product Owner a full-time role?
Well, yes and no.
Since it is the product owner’s responsibility is to make decisions about what we’re building, product owners are probably working full-time in some capacity within the organization – probably in strategy, marketing, or another area that gives them market insights. In small companies, the product owner might also be the CEO.
Product owners, therefore, do not have a full-time commitment to the development team – they need to be available to the team to answer questions, and play a key role in some important meetings. Sometimes, a product owner will work with more then one development team on different aspects of the same product. This gives the product continuity since the product owner holds the vision of what the product needs to be.
Should the Product Owner have a technical background?
The answer is no.
The product owner is responsible for what is built, not how it is built. For this reason, a product owner will often have a background in a more customer-focused field like marketing, sales, or design. Technical people can be Product Owners, but to be effective, it is important to really focus learning on (and, probably, have a natural curiosity about) business strategy and customer research.
This doesn’t mean that POs get to shut our ears when the development team is talking tech. The more we learn about how products are built, the more we’re able to have meaningful and efficient communication with the dev team. Ask lots of questions, be a sponge, but remember that having a different background is a strength, not a weakness.
The exception to this rule, of course, is when we’re developing technical products for technical people. A friend of mine is building a product that enables technical teams to better structure and organize their databases. Because his customers are all software developers, his technical background makes it easy for him to understand their needs.