You need a Product Owner who can do their best to secure the success of your product. A Product Owner does it by defining the right features for development and prioritising them. This way they minimise the time and cost of development. You need a Product Owner not because Scrum framework requires it, but in order to save money. That’s why it is paramount to know how to choose the right Product Owner.
Maximising the value of the product
Being a Product Owner (PO for short) requires taking the ownership of a product and sometimes even possessing some entrepreneurial spirit. That’s why a PO is often called a product-CEO (like CEO but only for the product). A PO has to know, with a little help from their Scrum Master, what to build and be able to communicate effectively with the people who buy, use and create the product.
The most important responsibility of a Product Owner is maximising the value of the product created by the Development Team, i.e. everyone who directly contributes to the product with their work.
But what does “maximizing the value” really mean? In short, making sure that the money was well spent on software development each Sprint (iteration), and there’s a strategy and purpose set in place. Besides that, there’s a lot of activities behind this phrase, and by the end of this post, this will be crystal clear.
Being a Product Owner is not easy. Just look above: the role starts as an “analyst” but after some time becomes a “product-CEO” in your organization.
Domain knowledge is essential
The Product Owner has to know the domain of the product and business. Here are the most important questions:
- How does your business work?
- How will the product be monetised?
- Who are the customers and users?
- What are the users’ pains and desires?
- What do we assume could relieve or satisfy them?
They can learn everything else quickly with the help of a Scrum Master and the Development Team.
A great Product Owner is always near the users and customers and can communicate with them using the “domain language”. For example, a doctor, a nurse or a physiotherapist could be a good PO for a medical product. A financial analyst or an accountant could be a PO for a financial product. The same as the supply chain or distribution manager for a logistic product.
Besides that, being a Product Owner for one product requires time commitment very similar to a full-time job. But I have good news for you. Even without strong domain knowledge, but with an open mind, eagerness to get the “hands dirty” and some help from the Scrum Master and the Development Team – almost anyone could get started on the path of Product Ownership. There’s really no need for sophisticated business analysis knowledge.
After some time your Product Owner should be able to answer the questions above and have a good understanding of the domain.
Struggling with your product development?
Contact us for a free consultation.
Sole decision-maker about what exactly ‘to do’ next
A Product Owner is one person, not a committee, who understands and represents the desires of users, customers, and stakeholders. Only a PO can tell the Dev Team what they should do next. PO has to be empowered by the organisation, which means being able to make decisions about the product.
Stakeholders and even the company CEO have to run the requests through the PO if there is a need for a priority change. The organization needs to respect the Product Owner’s decisions, which are visible mostly through the content and structure of the list which contains all work to do, called the Product Backlog.
Don’t get me wrong, it’s not that the Product Owner can demand whatever they want and say “I want you to deliver these 50 User Stories in the next two weeks. Period.” Instead, the PO informs the Dev Team which stories are of the highest priority, e.g. “These 6 User Stories from the top are most important right now, and they have a mutual goal ‘X’. Is it possible to achieve this small goal within the next two weeks and show this to the users? Please advise how we could reach the goal.”. That’s when the most fruitful discussion starts.
Your Product Owner needs to have the courage to do the right thing (and learn from mistakes) and you should respect your Product Owner’s knowledge, experience and decisions.
Responsible for cultivating the Product Backlog
Product Backlog is one and the only list that contains every piece of work the team needs to do eventually at some point. It’s represented in the form of multiple small chunks of work. It can be called Product Backlog items, User Stories, or just items, like on the image above.
What exactly this cultivation process means? In short, it means clearly expressing and ordering the items to get goals and priorities, ensuring that the Development Team understand items, making sure that the Product Backlog is visible, understandable, transparent and that everyone can see what work is next in line. A PO doesn’t have to do all of the above on their own. However, they’re still one single person accountable for the Product Backlog.
Your Product Owner should be focused on cultivating the Product Backlog regularly.
Responsiveness and availability for the Development Team
The Product Owner should try their best to spread the domain knowledge within the Development Team. Everyone needs to be on the same page. The easiest way to achieve this is by not excluding anyone from the conversations about the domain and the product. This approach is called “shared understanding”.
All this happens mostly when a PO clarifies the Product Backlog items, explains what the business is and who the users are. And also participates in necessary meetings, makes decisions on trade-offs, and answers questions from the Development Team
Gather feedback and involve users in the process
The Product Owner should talk to users as early as possible. PO shouldn’t be afraid of judgment or shouldn’t postpone it until the product is finished. Even at the very beginning the potential users and customer should be asked for feedback about the idea of your product. Then, after two weeks or a month, the PO can present the results to them – inspect and adapt continuously.
A Product Owner has to regularly gather feedback from users, customers, stakeholders and most importantly – engage them in determining “what” we could do next. They will tell you.
People often don’t know what they want until they see it, or even until they try it or interact with it. That’s why you need “baby steps” approach here (iterative and incremental). That’s the only way not to invest too much time in the ideas that your users wouldn’t find useful after playing with.
Your Product Owner should be committed to the process of gathering feedback from users and customers.
Be honest, transparent and let your team help you
The best solutions emerge when “business people” and “technical people” work together throughout the days within the environment where both can be co-creators of the solutions, like the Scrum Team on the image above. Mediocre products are made when “business people” pass “requirements” to “technical people” – don’t let it happen.
And it’s not only about the features, but also in general Product Owner shouldn’t have the answer for everything. In fact, they have an army of people – Development Team, Scrum Master, users, customers, and stakeholders who could have some answers or could help to find them.
There is one more detail. A great Product Owner knows that we build software to learn about the product’s assumptions. (Spoiler alert – every feature is an assumption). They know how to minimize the risk of building something that nobody would use. At the end of the day, it’s not really about delivering the project on time, under budget and within the original scope. Focus more on delivering the right product with a sufficient set of features for your users. Even if this could take more time, money and a completely different scope, this will pays off.
Your Product Owner should be characterised by openness and transparency in communication with you, Development Team, Scrum Master and any other stakeholders.
But where is the Project Manager or the Product Manager or the Business Analyst?
The short answer is: you probably don’t need them. A more detailed answer: a classic Project Manager role is smartly divided between the Product Owner, the Development Team and the Scrum Master.
In Extreme Programming, Product Manager is basically another name for Product Owner. On the other hand, the classic Product Manager role is more common in really big companies with multiple products. However, this varies depending on the organization.
In a proper agile environment, a business analysis should be more a skill which team members acquired than a separate role. If there’s a Business Analyst in the organization, they should focus mostly on being a servant-leader (like Scrum Master). They should educate teams about business analysis skills and help them to be better as a team. Simple solutions for complex problems are the best.
First, start with the vision of the product
It’s crucial to have a coherent vision before the development starts, the simpler the better. Product Owner should drive and define the vision for the future, which is a few Sprints away and also a more distant one. Any one-page business canvas will be enough – Product Vision Canvas, or Business Model Canvas, or Lean Canvas.
The vision shouldn’t be about dreams to become the next Facebook, it should be a testable assumption that we can validate. For example, “Can we be a leader with our ‘Uber for horses’ app in Germany?”.
Also, the vision is not written in stone, it should evolve over time – always inspect and adapt. As the popular quote from Yogi Berra says “If you don’t know where you are going, you’ll end up someplace else.”.
I’m ready now to find my Product Owner
As a startup owner, you probably wouldn’t have enough time to be a Product Owner. But you’ve got high hopes about the success of your product. Taking into account all of the above, consider hiring or designating someone from your organization who could be a full-time Product Owner. Take care of the success of your product, like the Product Owners from the Game of Thrones.
If you’d like to hire the best Product Owner possible, you should look for people with Professional Scrum Product Owner (PSPO) certification. Try to find someone with this certification and some general experience within the domain related to your product or startup.
This particular approach, a Product Owner inside your startup and a Development Team with a Scrum Master from an external software house, could give you a good ROI faster than setting up an in-house team from scratch.