The Product Roadmap as a Driver for Innovation and Engagement

A product roadmap links organization strategy to tactical actions. It drives us where we are going, asks us why we are going there and reminds us of what questions we are trying to answer, all within a specified timeframe. According to Mike Cohn, "a product is something (physical or not) created through a process that provides benefits to a market.” In this post, I’ll give you a quick and pragmatic view of how to build a product roadmap and what to avoid in the process.

Translate Business Goals Into Concrete Actions

You can use the Business Model Canvas, which captures your organization’s market and business model assumptions in order to state and validate your ideas. With this tool in hand, you will have three of the most important answers that drives the creation of the product roadmap:

Who are the personas, markets and market segments that you are aiming to target? What is the proposed value and solution in terms of capabilities to deliver? What are the business value and key metrics we are going to address? When should we expect to deliver to our customers? How often? Focus on Features and Business Value, Not Timelines

A product roadmap is not a project chart/Gantt chart, thus there is no need to depict it as many deliverables and tasks representing a detailed schedule and exact dates. It’s well known that it affects the creative imagination and it can easily lead to a “do what I told you to do in following the plan” mindset. As product owners, know that planning something in advance is not feasible, because our work depends on constant feedback, learning and adaptation. In other words, KISS (keep it simple, stupid!).

Get All Involved and Buy-In

A product roadmap cannot be built by just one person, including the product owner. The inputs should come from engineering, marketing, operations, security, risk, sales and so on. All are invited to contribute and generate ideas. Without buy-in, it would be extremely challenging to execute and deliver, especially in medium to large companies.

A roadmap is broken down from strategic opportunities to distill a problem or purpose to a tactical level, where it can be finally materialized. It acts as a glue between strategy and tactics, and it also clearly communicates what is being delivered and is updated very often. Essentially, it is a live product communication that maps to all stakeholders.

A Release Plan is Tactical, While a Roadmap is Strategical

A product roadmap is not a release plan: The former is linked to the strategy (longer term), while the latter is linked to the tactics (shorter term). A release plan can contain several releases, with each one divided into a few sprints, covering the next 3 to 6 months. A product roadmap, on the other hand, generally covers one year. A release plan consists of user stories and product backlog items, while the roadmap incorporates high-level features, goals and product capabilities. 

Imagine With a Different Perspective

What’s the real definition of innovation? A new idea, method or equipment--something fresh. But, is that all? Is it just about creativity and invention? The answer, in short, is no. In fact, it can also introduce something new to an existing product or method. Innovation creates value for people.

For instance, the first computer was an invention, the first laptop either an invention or an innovation and the first touchscreen computer an innovation. In technological terms, the real value of applying innovation is to solve a problem to serve a group of people. If you want to attract a large amount of people to use your product, you will need an open mindset consisting of multiple different cultures.

So, what does this mean? A good product roadmap is one that gathers the best and most innovative ideas that fit to the company strategy. For inspiration, check out the photo below, where Slack invites people to collaborate with the product development platform.

Never Set in Stone

A product roadmap in agile is often revisited and updated, not only because it relies on user inputs and experimentation, but also because it can change as the market evolves. To start, you can open the product roadmap in three simple columns to gather insights from a group of people of different areas of expertise.

Pragmatic Roadmap Adds Benefits

Product roadmaps come with plenty of advantages. They:

Engage people to collaborate and think creatively and differently. Connect to stakeholders and influence them to make the product successful. Align the expectations of shareholders, sponsors and high-level executives. Cultivate a melting pot of cultures, races, genres and people for a combined and common value of experience. Communicate and set a purpose for the upcoming months. Help to plan the team size required for the product, as well as assist the coordination with the other teams that might be a dependency. Support budget planning and forecasting along with ROI, if possible. Drive prioritization efforts.

Do you agree with my assessment of the value of product roadmaps, or have any tips for ensuring their success? Let me know in the comments section below.

Don’t Limit the Role of the Scrum Master

I’ve heard quite a few questions about the necessity and value of having a Scrum Master in an organization. Sometimes, the role of the Scrum Master is combined into the engineering manager role or any other technical role which would create a conflict of interest. These questions are born either from a poor knowledge of Scrum or a misunderstanding of the principles and values behind it.

However, there are some people who limit the role of the Scrum Master and follow exactly what is written in relevant literature. That’s another problem that affects the community of Scrum Masters in general: the Scrum Guide tells you what to do in overall terms, and it’s your responsibility as a Scrum Master to go beyond that and bring value to both the company and the team. There is never a one-size-fits-all recipe; every team and company has different missions, people, values and cultures.

In this post, I’m going to share some tips and practices to help other Scrum Masters excel in their role and add real value to their organization.

Challenge the Process

As an enthusiastic Scrum Master, challenge the process of the entire company and lead the organization to embrace the agile mindset, principles and values (such as commitment, focus, openness, respect and courage).

Push not only toward continuous improvement, but also toward continuous adaptation. The Scrum Master is accountable for adapting the process in respect of the business strategy and mission.

In certain occasions, perhaps for operations/infrastructure/maintenance teams when it makes sense and is appropriate, the Scrum Master can streamline the process and turn it into a Kanban method. The Scrum Master will benefit from other agile methods, tools and practices as well. Continuous learning is essential.

Coach the Engineering Practices

If you are a Scrum Master who has a good technical background in software engineering, or if you develop some code in your free time, try to foster and coach technical practices within the team, such as continuous integration, continuous delivery, pair programming, test-driven development (TDD), automated acceptance testing and refactoring.

For instance, continuous delivery is a very valuable practice that will allow the team to deliver features into production more often and get better feedback from the stakeholders. Your team code will obtain both quality and performance with the introduction of these engineering practices.

Communicate With Stakeholders

Be the conduit among business and technical stakeholders, make sure the communication is fluid and well understood and spread the knowledge of Scrum. Engaging the stakeholders and making sure they are all on the same page is important for the health of the product. Teach them how to maximize return on investment (ROI) and meet their objectives.

Peer With the Engineering Managers

Help the engineering managers with the team’s performance reviews as necessary.

Encourage them to empower the team and provide any type of support needed. The Scrum Master can also help to expedite the hiring process by finding candidates who would be a great fit for the team.

Educate new engineering managers, product owners and team members on-boarded in the company. Whenever a new person is hired, the team will need to be restructured again to be balanced and continue working efficiently. The Scrum Master is needed to provide training and coaching during that restructuring period.

Scale Scrum and Agile

Scale up large products into multiple agile teams, integrate the pieces all together and promote training to spread the knowledge of Scrum and agile. Help business people to understand the framework. Get them involved and obtain feedback frequently, listen closely and take immediate action. 

Create and foster communities of practice for product owners, Scrum Masters, engineering managers and development teams. Agile is all about collaborating with other teams and people, sharing good practices and learning lessons.

Learn new practices continuously and experiment with them with the teams. There is always a new technique to apply from the Scrum experts, so don’t hesitate to be curious. 

Promote hackathons and dojos to drive innovation and excellence. Both the company and the teams will gain significant benefits from hackathons. People will have an open time to expose their ideas, and the company will have the opportunity to hear those ideas and possibly implement them.

On the other hand, a dojo is a powerful technique to improve your skills, grow up and be more efficient. For example, you can facilitate a coding dojo for new hires and bring experienced software engineers to hook up with them. The newbies will get to see how coding is done in the company while simultaneously bonding with senior-level engineers. It also enables the transfer of knowledge.    

Nurture Scrum structures with high-level managers and executives. Show the benefits of Scrum to them and speak up. Don’t be intimidated by them; if you are seriously passionate about Scrum, you can influence and lead the entire organization to the next level.

Work Closely With Product Owners

While helping the product owner to enhance the product backlog, why not contribute to the backlog and innovate with some new insights and ideas? A great Scrum Master takes an opportunity to understand the business context and drive every decision based on it. Each team and each product require different strategies and, again, no one recipe is a good fit for every team.

Moreover, a great Scrum Master focuses on improving the agile approach the product owner is taking, thereby providing templates and tools for the product roadmap, business-driven development (BDD), Business Model Canvas and mockups/drawings.

Streamline the Scrum Ceremonies

Improve the way retrospectives are held depending on the situation and phase of the product/project. There are several different types of retrospectives that can be conducted to extract the right pain points and identify action items to be tackled.

Call each ceremony a “conversation,” since development teams typically prefer conversations rather than meetings. Remove waste in each conversation and invite people with an effective purpose and clear agenda. If possible, take the team to demonstrate the user stories as soon as they are done by the team. Coordinate with the product owner on what is proposed to be brought during the sprint planning and do your best to make it efficient. 

Assist the Development Team

To remove waste, bureaucracy and unnecessary work assigned to the team, take ownership. In some cases, they need someone to take accountability of the change management control due to compliance regulations or something similar. I once faced a situation in which a company needed to create some documents and present the changes planned to be released into production. It was not rocket science, but it took time and focus from the team.

Run team-building exercises to connect with each other in a positive atmosphere, cultivate happiness across the team members, celebrate each milestone reached and resolve conflicts in a collaborative way.

Collaborate With Other Areas and Departments

There are some companies that have a PMO (project management office), and the Scrum Master can help turn it into an Agile PMO with KPIs and metrics that make sense in terms of deliverables.

Moreover, the Scrum Master can conduct process improvements on the business side and influence them to implement Scrum as well. Scrum is not only for software; it can also be applied in marketing, finance, accounting, HR and many other places. Spread it across the organization.


We used to limit the Scrum Master role according to the parameters provided by literature. However, this is not enough: the world is evolving and demands flexible frameworks adapted to the circumstances of the company and the market in general. One particular method might fit very well with one team, but may not work for another team, it really depends on several factors, such as product, people, technology, company and market. The basis is taught, then from there, you will adapt, experiment, learn and evolve. 

From the topics depicted above, there is a common sense that the Scrum Master role is a long-term assignment and will never end. The success of the Scrum Master relates to the value that it brings to the organization as a whole, as well as the level of happiness the team is experiencing: they are learning, delivering, feeling safe and awesome, working at a sustainable pace and not disturbing their personal lives. Even the best high-performance team can benefit from the Scrum Master role.

After reading all these tips, do you still feel that the role of Scrum Master can be replaced or discontinued? Do you believe that the success of a Scrum Master occurs when the team doesn't need him/her anymore? There are tons of different ideas to be accomplished by a Scrum Master. This post listed only a few, and I guarantee that the work will never be done. As always, be passionate about serving others and delivering value.

If you have any doubts, questions or contributions related to the role of the Scrum Master, feel free to let me know in the comments section below.

Business Model Canvas: Step by Step

The Business Model Canvas (BMC) is a strategic tool for the product owner that helps to build a faster and more visual representation of new products and services. It consists of a panel divided into nine blocks, such as those displayed in the picture below, which represent the basic elements (building blocks) that compound a business model.

The main goal of this panel is to generate value proposition that meets and potentiates the desired objectives before actually implementing the product or service. Below, I depict the dynamics of how to build a BMC, created by Alexander Osterwalder.

Building the Canvas

In order to apply the Canvas as shown in the picture above, you can either use a printed version (using this pdf) in A0 size to facilitate the collaboration, draw on a whiteboard (simple layout to replicate) or create it online (Lucidchart has a helpful template).

Lucidchart is a good option for distributed teams because it can be built online in a collaborative way. There is also a web-app available created by the makers of BMC.

The Canvas already filled in below can be split into two dimensions: the dimension located on the right contains more subjective and “emotional” elements, while the dimension on the left contains structural and logical elements. It is recommended that you fill out the Canvas from right to left. This way, the wishes and aspirations of the stakeholders can be addressed before you start defining in a more factual method.

Dimensions and Basic Elements

The illustration below shows how the nine elements of the Canvas are integrated with each other. As mentioned before, we will begin to explore the right dimension of the Canvas first.

We start by putting the block “Customer Segments” in place, which maps who we are targeting to provide value and who are the potential customers to our desired objectives. For instance: customers over the age of 50, women, customers from California and so on.

In the block “Value Proposition,” ideas are generated to fulfill the needs of the potential customers, while always keeping in mind the business objectives that are driving this product or service. Examples of value propositions include cost reduction, agility, convenience, customization and decision support. The Customer Segments and Value Propositions blocks are the main elements that will lead the remaining components of the Canvas.    

Once we determine the potential customers and value propositions, it’s necessary to think about how we can link these two fundamental components. This is the purpose of the “Channels” or “Distribution Channels” block, which includes items such as the delivery, blog, newsletter, customer service and webinar. These are the channels that distribute and deliver the value propositions to the customers.

Next, we should understand  the “Customer Relationships” block. In other words, we should figure out how to strengthen customer involvement with the business. To give a few examples: business development partnership, customer retention, customer support, online chat and feedback.

The last right block is the “Revenue Stream,” which translates to the path to generate revenue based on the recommended value proposition. Examples include a monthly subscription, direct sale, paid ads and license.

The image below depicts the fundamental elements of the right dimension from the Canvas.

In the left dimension of the Canvas, we can find more direct and objective definitions that sustain the components mapped in the right dimension.

The “Key Resources” refer to the resources directly associated with the business model operation, such as teams, machines, investments and technology platforms.

The “Key Activities” are all activities needed to meet the value proposition, build channels and keep relationships. We might consider managing the social networks (a powerful mechanism to strengthen the customer relationship) or building a web store.

“Key Partners” are people who contribute to both key activities and key resources. Some partners (outsourcing companies, for example) can provide machines to drive towards any key resource. Other types of partnerships can supply contractors or execute some of the key activities, such as monitoring the social networks.

Representing the required costs to maintain and build the proposed solution is performed by the  “Costs Structure” block, which indicates, for example, the amount of money necessary to pay the machines’ maintenance, contractors, OPEX, infrastructure and resources.

The picture below illustrates the basic elements of the left dimension from the Canvas.


The Business Model Canvas is useful for driving the conception of new products and services through its nine basic elements from both rational and emotional perspectives. It also allows the teams to brainstorm insights, ideas and opinions around the product, enabling a common understanding among the stakeholders as well as generating strong performance indicators towards a strategic innovation.

It’s another helpful tool for the product owner to conceive a new product, service, website, e-commerce or game.

Have you used the BMC before? Do you plan on using it in the future? Let me know in the comments section below.


Behavior-Driven Development for Product Owners

A product owner should always be looking for opportunities to bring value to the customer while simultaneously boosting their team’s efficiency. Acceptance criteria is a vitally important part of the user story, and yet it is sometimes ignored, incomprehensible or overly detailed. The key question to ask is: is the team reading, designing and implementing the code according to the acceptance criteria as well as the product owner’s expectations?

If the answer to that question is “no,” I wouldn’t assume it’s the team’s fault, since there are often better ways for the product owner to drive, clarify and define the acceptance criteria. One of those ways is the 3 “C”s Theory by Ron Jeffries. Another is behavior-driven development, which I’ll be exploring in this post.

The Benefits of BDD

The 3 “C”s Theory is an approach which doesn’t depict the acceptance criteria in too many sentences or words. In a nutshell, the first “C” refers to the card where the user story is written. The second “C” refers to the conversation that takes place when the team begins to collaborate with the product owner and understand how the deliverable will work. Finally, after the user story is implemented and tested, the team passes through the third “C,” which refers to the confirmation of the final result of the user story.

Another method that product owners can use to work with the team to define the acceptance criteria is known as behavior-driven development (BDD). BDD builds upon test-driven development (TDD) by going beyond the development team. In other words, BDD is a technique used to write the acceptance criteria in a way that anyone can read and comprehend. In addition to facilitating communication between a team, their company and its technical stakeholders, this approach has several other benefits:

Allows the product owner to clearly define what is expected from the user story itself. Creates fewer communication gaps. Opens communication between the business and the development team by having multiple hands on the deliverable of each user story. Builds a strong sense of collaboration between the product owner and the development team by removing ambiguous language. Increases agility and efficiency by turning the outcome of BDD into automated test cases which can be integrated into the continuous delivery pipeline and tool. More executable documentation and less waste.

BDD was designed by Dan North, author of the book “The RSpec Book: Behavior-Driven Development with RSpec, Cucumber, and Friends” as an evolutionary practice of TDD.

Applying Behavior-Driven Design

In order to apply BDD, I would recommend following this five-step flow:

Identify and define the user stories. Refine the acceptance criteria. Implement the code using TDD. Demonstrate the user story. Automate the acceptance tests through the continuous integration pipeline.

I will be focusing on the acceptance criteria where BDD is initially applied, but the five-step flow can give you an idea of how it can be applied to the entire life cycle.

Define User Stories

The user stories are first created by the product owner and then refined in either a workshop or a product backlog grooming session before the sprint planning. In both cases, a multifunctional team, product owner and technical stakeholder are required.

Some preliminary questions should be asked in order to form examples of utilization or business case scenarios which can help the team to better understand what has been discussed.

Suppose that a potential buyer goes to an e-commerce website and, after searching for a product, he or she receives a message that the product is currently unavailable. How can the  website retain that customer? To find out, let’s go ahead and write a user story, then ask a few questions that might come up during the subsequent meeting.

User story:

“As a customer, I want to be notified via email whenever the product is available again.”

Some questions that might be raised are:

Does the user have to own a site account in order to be notified? If so, what happens when the user is not logged in? What happens if the user already created an alert for the same product?

After answering those questions, the team will have a better understanding of what the product owner is expecting from the user story. Next, the team can collaborate with the product owner to write the acceptance criteria with as little ambiguity as possible. For example:

User has to own a site account; otherwise, redirect the user to the registration page. User has to be signed in; otherwise, redirect the user to the login page. Users who are registered and signed in must confirm their email address. Refine the Acceptance Criteria

The next step is organizing the acceptance criteria in the format required by the BDD framework. There are several BDD frameworks, including FIT, FitNesse, Cucumber, Concordian, Robot Framework, RSpec, Jnario and more. For our example, I’ll be using Cucumber: 

In this case, I used Gherkin, which is the language that Cucumber understands. It is a business readable, domain specific language that lets us describe software behavior without detailing how that behavior is implemented. Gherkin is primarily used for two purposes: documentation and automated tests. The product owner should write the acceptance criteria in Gherkin for each user story.

In summary, every scenario contains the following keywords: Given, When, Then, But and And. Another useful keyword is Examples where you can outline rows with different values for each attribute. You can also use Data Tables to pass a list of values. Learn more from the reference guide for Gherkin. 

Implement the Code Using TDD

Next, the development team comes into the picture to start implementing the code while applying TDD in order to pass all acceptance tests.

Demonstrate the Acceptance Tests Results

After all successful tests, the user story is validated by the product owner and is often shown in a sprint review or showcase.

This phase shouldn’t be a major concern for the team, due to the fact that the development team will have followed the acceptance criteria written in BDD by the product owner.

Automate the Acceptance Tests Through the Continuous Integration Pipeline

Finally, it’s time to include the acceptance tests in the continuous integration tool and make them run automatically for each commit and build. That’s where the fun starts, and there is no need to validate the test cases manually.

BDD in Summary

Behavior-driven development is a very pragmatic approach which offers a number of advantages, the most significant of which is the ability to share a clear understanding of each new user story and what will be delivered.

When used properly, it creates less rework and waste, more agility, a higher level of collaboration, common understanding and more productive teams. In fact, the product owner can use BDD to produce executable documentation that will be reused all over the development code, thereby bringing more value to the team and delivery pipeline.

If something is not clear or you would like to learn more about BDD, please feel free to ask a question or share your thoughts in the comments section below.

From Scrum Master to Product Owner: A Journey

Many of us have transitioned from either a sofware engineer role or a QA engineer role to a Scrum Master. This is a natural path for those who want to become a servant leader, working with the teams/stakeholders, coaching people and leveraging agile/Scrum across the organization. Furthermore, it requires a different mindset with more focus on soft skills.

It’s also common to see software engineers and QA engineers turning to a product owner role.

Therefore, how difficult is it to be a product owner when you are a Scrum Master? Well, there are a lot of challenges, due to the fact that these two roles have different perspectives and skill sets.

Scrum Master: Abandoned and Chosen

Once upon a time, a company I worked for as a Scrum Master decided to get rid of all Scrum Masters for various reasons—the most critical being budget.

Consequently, the role of the Scrum Master merged with the engineering manager, and the engineering manager took over the Scrum Master’s responsibilities. As usual, some of the engineering managers weren’t prepared to assume this new role because either they were toxic to the teams or hadn’t been trained enough in Scrum.

At the same time, all Scrum Masters were laid off by the company due to major cuts on the budget, my boss asked me if I would like to become a product owner once the team I was acting as a Scrum Master for didn’t have a full-time product owner.

I was already doing part of the product owner duties: working with the stakeholders to gather the requirements, writing and prioritizing the user stories, digging into the product and envisioning its growth, working close with the teams, and being the voice of the customer.

The team’s product owner was so busy with another priorities that she didn’t have enough time to focus on that particular team. I took the initiative and action on behalf of her.

A desire to deliver a delightful product to my customers was always on my mind. With a lot of excitement and anxiety, I finally accepted the challenge of officially taking on the role of the product owner.

New Journey: Ups and Downs

Several Scrum Masters like me have faced many challenges with their product owners and sometimes they become the impediments for the team. As a Scrum Master, we should address and remove them.

As the first time as a product owner, I didn’t want to be the impediment and cause of the difficulties for the team. As a product owner, I wanted to create the user stories using the INVEST model, write good acceptance criteria, groom the user stories with the team, prioritize the backlog, be available to the team, define a goal for every sprint, and so on.

I was doing my part, however how about the Scrum Master (in fact, the engineering manager) for the team and product? Well, she became the impediment, because she was not doing her part.

I was frustrated due to the fact Scrum was not being implemented as it should be and the whole benefits were being lost. The team was still looking to me, waiting for me to remove this impediment, but I wasn’t supposed to take action anymore, only concentrating on the product.

On the other hand, I was the Scrum Master before, so I still had the ability to coach the new Scrum Master, no excuses. However, the engineering manager didn’t want to follow coaching and I was reprimanded when I was told I was on the product side and couldn’t influence the engineering process anymore.

This is the hardest part of converting from a Scrum Master to a product owner role: your brain has to do a mind-shifting and move away from the old habits and responsibilities.

For several months, I continued facilitating the sprint planning and review, because the Scrum Master didn’t want to do that or didn’t know how to do it, but the product had to be delivered anyway.

Resilience and Working Hard for the Team and the Customer: Reward

It might take time, but you can adapt yourself to the new norm from Scrum Master to product owner. In the beginning, the path seems long: our focus is different, more on the business side, staying closer to our customers, and understanding their pain points.

If you’re faced with this challenge, don’t give up, make all your efforts to switch gears and mindset, and the reward will come.

What did I learn? Make the team feel part of the product, and they can help you to drive the results and goals of the company. The team will support you in the process for a while if you are open, transparent and trust them.

Be present in every retrospective and ask how you can improve in a very honest conversation.

Be humble and listen. Change your attitude, demonstrate that you’re working hard not only for the success of the product, but for their success as well.

As a new product owner, learn every piece of the business rules, talk to the stakeholders, create effective roadmaps and be the “CEO of the product.”

Last, but not least, go to conferences, training, read books about product management, be involved in the agile community. It’s now time to focus your knowledge and strengths in the product ownership.

New Hope: Continuing the Journey

New challenges appear every day and this is a good sign because the world keeps evolving and each challenge is an opportunity to grow in your career and as an individual.

Improve the method of creating the user stories, leverage the product, streamline the process of delivering the features continuously, go outside of the building and listen to your customers, experiment new things and finally delight your stakeholders with innovative products.

The path and the migration from a Scrum Master to a product owner can be complicated; however, it’s rewarding and valuable for several reasons: business model understanding, value proposition creation, industry standards and terminologies in practice, customers and partners relationship, channels and segments applied, generating revenue by different methods, applying innovation and open new markets, and the list goes on.

Are you also transitioning to a product owner role and need some help? Feel free to leave your comments or questions and I’ll be glad to help you out.

A Pragmatic View of a Great Product Owner

As the Scrum Guide clearly states, the product owner is responsible for maximizing the value of the product and the work of the development team. However, this statement represents an extensive list of duties and responsibilities—even an entire mindset that drives different dimensions: technical, business and design.

We often find a good variety of articles that cover the differences between a product manager and a product owner, but does it really have such distinction? In a Scrum team, there are only three roles: product owner, Scrum Master and the development team. Hence, there shouldn’t be any difference at all.

On the other hand, why do we try to make two separate roles? Well, perhaps the product owner is not great enough and a gap exists.

A team and a product owner has the right autonomy to decide upon each feature prioritized to the product. A product owner has a clear and unique message of the strategy and tactics around the product. He/she is not only envisioning the product, but also strategizing it within the company and making decisions collaboratively with the team.

Pragmatically, a great product owner is different from a good product owner in certain varieties of attributes, from a vision and strategic perspectives to a more tactical level:

Accountable Agile leader Business-centric Designer Innovative Omnipresent Organized Product oriented Strategic Technical

Do you want to become a great product owner instead of just a good product owner? Let’s dissect these attributes.


The product owner is primarily accountable for the product the development team is building and leveraging the most valuable backlog with user stories ready for the team.

A great product owner envisions the product in order to be in alignment with the mission and goals of the company. He/she develops an MVP (Minimum Viable Product), gathers the feedback with the customer, reflects and learns from it, then revaluates and adds more valuable features each time.

Agile Leader

A great product owner attends (or at least, tries) the daily standups 100 percent of the time; he/she also answers the three basic questions and is available to clarify any question from the team because he/she knows that a question is an impediment that needs to be addressed.

In sprint planning, the product owner shows an ordered set of user stories to be delivered by the team, declaring a real purpose for that particular sprint and answers as many questions as the team would like to ask.

The sprint review is when the product owner confirms and accepts the user stories accomplished in the sprint. The product owner may also take this opportunity to find gaps or take insights to leverage the product continuously. During the retrospectives, he/she listens to the team, contributes and then makes an action plan.

A great product owner doesn’t push the team beyond their limits, he/she makes a room for the team to innovate and collaborate with the growth of the product. He/she makes the Scrum Master and development team awesome. His/her attitude makes the team feeling engaged with the product and part of it.

In addition to this, he/she clearly defines a purpose for any new resolution, feature, etc. An action without a purpose doesn’t mean anything. He/she fosters the continuous improvement, finds ways for each individual to learn new things, new technologies, new frameworks, new practices and coaxes them to master their knowledge.


Maybe, this is the most complex topic for some product owners. A great product owner is capable of capturing terminologies, concepts, operations, and so forth, regarding the type of industry he/she is involved in.

Companies in the retail and payments space, just to give an example, have different business systems, hence the product owner should get the knowledge of these systems, rules, regulations, compliance and so on.  

He/she drives and guides to deliver business value continuously to the customers based on a business model plan. It depends on each product, a business value can be related to the number of customers retention, new customers, the number of registered users, revenue generated, costs reduction, public/free services available, etc.


A great design delights the eyes of the customers, thereby a great product owner keeps the eyes open in any small piece that requires enhancements or adjustments. He/she is a perfectionist, satisfaction is something that remains all the time on his/her head.

A great product owner works with the SEO, UX & UI specialists to drive a friendly user experience in order to attract and retain the users. It’s an ongoing process that requires experimentation, receiving feedback and collecting metrics to analyze the data, learn quickly and validate the hypothesis.


A great product owner thinks differently, “out of the box,” imagines a world that doesn’t exist, experiments with new ideas and insights with the team, accepts failures, envisions the impossible, and gathers feedback from the customers, Scrum Master and development team.


A great product owner has to be available to the team, communicate openly with each team member, understand their concerns, listen to them and guide them day by day according to the product vision and goals.

A product owner is easily accessible. The product owner job is all about communication, he/she ensures the team understands the vision and the “real” expectations are aligned with the team and stakeholders.


A great product owner inherits a certain amount of characteristics from the project manager role. In fact, his/her responsibilities also include controlling the budget and being organized with the roadmaps, set of features / epics, prioritized list of user stories, presentations, customer questionnaires, wireframes, designs and so on.

A backlog is built by the product owner and it consists of a set of elements:

Who are the personas and target audience? Who are the market segments? What sort of features and benefits will the audience above pay for? When am I releasing each feature? Is there any event will drive it? How will the software architecture evolve? Are there any external dependencies to resolve? Product Oriented

A great product owner understands that the word PRIORITY in practical terms doesn’t have plural, because if you have, there isn’t any priority. One of the most important words for the product owner is “no.” Saying “yes” to a new feature request is easy.

The most important job for the product owner is deciding what not to build and own the consequences for that decision. A great product owner prioritizes what needs to be done by evaluating the business value and the amount of time required for building a feature.


A good product owner knows how to gather requirements and translate into epics and user stories. Most of the time, he/she is on the tactical side.

A great product owner knows exactly how the business works, has open and frequent communication with the VPs, directors, managers, stakeholders and maybe even with the CEO. He/she strategizes the product with the sales managers, marketing people, legal department, security, compliance and so on.

He/she circulates the building to gather not only the requirements, but also the strategy and goals of the company to translate into a feasible roadmap that clearly identifies the targeted customer, primary goal and works with the team to set an expected delivery date.  


A great product owner differentiates from a good product owner in terms of a very good technical knowledge in the field he/she is acting on. Is it feasible to have a product owner who is driving a cloud-based product without a deeper understanding of how a cloud architecture works and how to implement and release in a cloud environment?

Probably yes; however, a great one knows that every aspect of the product can benefit from different configurations from the cloud space.

Next Steps

Would you like to grow and succeed as a product owner, and take it to the next level? The key is to learn more and more and get in-depth knowledge on different topics. There are a lot of great resources available on the internet; I want to bring a few of them that I find really useful:

Podcasts are a good alternative for those who are always busy (at least, you can listen while driving or working out).

Agile Amped Podcast Agile Toolkit Podcast Global Product Management Talk Steve Blank Podcast This is Product Management

Below is a list of books to start your journey as a great product owner:

“Agile Product Management with Scrum: Creating Products that Customers Love” by Roman Pichler “Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers” by Alexander Osterwalder “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” by Jez Humble & David Farley “Innovation Games: Creating Breakthrough Products Through Collaborative Play” by Luke Hohmann “Inspired: How to Create Products Customers Love” by Marty Cagan “Managing for Happiness: Games, Tools, and Practices to Motivate Any Team” by Jurgen Appelo “Strategize: Product Strategy and Product Roadmap Practices for the Digital Age” by Roman Pichler “User Stories Applied: For Agile Software Development” by Mike Cohn

Additionally, be involved in the Scrum community, participate in Scrum Gatherings, agile conferences, meet-ups close to you, free webinars or perhaps establish a community of practices at your workplace.

I really want to know your thoughts on being a great product owner. Let me know in the comments below and we can start the conversation!