Web Development

What skills are required to be a great product manager?

By September 7, 2017 No Comments

First things first, who is a Product Manager ?

“A product manager is a professional who is in charge of evaluating and making recommendations on all aspects of a company’s products through the entire product life cycle. The product manager helps an enterprise to benefit from more knowledge about its products and how they are made, managed and sold.”

It starts with setting a vision for the product, which requires you to research, research and research some more your market, your customer and the problem they have that you’re trying to solve.

Once you have a vision, you have to spread the word in your business. Get dogmatic, evangelical even, about the utopia that is your product. And if you can’t get passionate about it – you’re in the wrong job or you didn’t come up with a very good vision. Your success, and that of your product, relies on every team member – from sales to developer – understanding that vision and being at least a little bit passionate about it as well.

And then you switch gears again and start building an actionable plan to reach that vision. A roadmap of incremental improvements and iterative development that take you step by faltering step closer to that final vision.

There are some of the qualities that a proficient Product Manager must have:


The product manager sees customers, markets, and teams for what they are. The best ones can spot opportunities where others may see nothing more than a wasteland. This requires a keen ability to observe without judgment and listen deeply without speaking — no easy thing. Product managers do this so they can use their observations to assemble a holistic picture of where the product is currently, what customers think of it, and where it needs to go in the future.


The product manager sets the vision for where the product is headed based on seeing the truth through deep observation, as described above. Meaningful products that solve real customer problems require profound insight and unabashed confidence to see, then build. And while customers often know that they have pain, it is rare to find a customer that knows exactly how to solve it. The prophetic product manager knows how the team should enhance the product next, even though everyone is uncertain as to what to do next.


The product manager sets the product’s goals and key initiatives to realize the higher-level vision. They start with a strategy that is market and customer driven and thoughtfully consider the capability and potential of the organization. Then they establish what they want to achieve and how they will get there so the product team can work on what matters. The strategic product manager tracks the goals and makes changes to the plan accordingly.


The product manager has a responsibility to own the performance of their product and that strategy. Sure, the product manager carefully sets quantifiable goals and establishes clear metrics to determine success. But it is not enough just to set goals and initiatives. Strategic product managers know that they cannot improve what they do not measure. So they keep a dashboard of performance metrics that matter to the health of the product and the business. Product managers live by those metrics and take account on an ongoing basis.


The most respected product managers work at two levels simultaneously — driving strategic alignment within the product and product team, while making sure everyone is in sync. They also commit to making sure the strategy is deeply linked to the day-to-day work. This high-level and task-oriented work must be aligned — by the product manager. At the most tactical level, product managers ensure feature prioritization is aligned to the strategy, build detailed cross-functional plans, and lead (maybe even cajole) the team to deliver results.


The product manager drives action. No one pushes the team harder to get meaningful work done. They know the importance of urgency across the team and respond to requests for information and problems quickly because they cannot afford to have the team slow down. Time is not something a product manager can get more of, so every day they work to ensure the product is more loved by customers than it was the day before. The work of a driven product manager is never done, and that is why they are eager to make an impact every day.


The product manager fights to make the truth about customers and the product known and refuses to get distracted from their strategy. They are the first to get excited (really, really excited) when a new idea shows the potential to truly improve the product for customers. But they are also the first to say no when the shiny new idea is not aligned with the goals and initiatives. They will fight for the customer and for the team — because they know the two are inexorably intertwined.


The successful product manager is also the greatest marketer of the product — both internally and externally. No matter the size of the company, an internal product champion is key. But it is even more critical in larger companies where many product managers are often competing for shared resources. Externally, the product manager is the product’s biggest fan because they are inherently tied to its success and know the value it can deliver more so than anyone else. The product manager is a natural evangelist who cannot help but share their enthusiasm for the today and the tomorrow of their product.


The product manager fixes everything. They tune the product strategy based on meaningful analysis of what is happening. They are also the first person called upon to solve complex problems — the on-boarding experience is not driving the expected customer engagement, sales has misrepresented when a new feature will be delivered, or a partner is demanding changes to the API. Knowing which problems to pay attention to matters because it determines when to fix an issue, when to leave it alone, or when to allow the organization to self-correct. The best product managers know when they need to dig in and when not to meddle. And the fixer product manager relies on all the other skillsets (observer, prophet, strategist, accountant, aligner, driver, fighter, and evangelist) to prioritize when to do what.

As a product manager, it is important to understand that you are a central hub within your company for a lot of critical information about your products, market, competitors, customers, prospects, key industry analysts, and many other constituencies.

To succeed, you will need to continually gather and analyse data and business intelligence from all of these sources (as well as your internal sources like sales and customer service) — and use this data to inform the evolution of your product roadmaps.

Because you play a central role in your organisation — always gathering valuable intelligence from various customers and your market — you are in a unique position to define the success of your product. Your role as the product’s strategist and evangelist will be central to your success and the success of your products.

A product strategy is the foundation of a product life cycle and the execution plan for further development. The product strategy allows the business to zero in on specific target audiences and focus on the product and consumer attributes.

Introduction to Product Strategy

Product strategy is often called the roadmap of a product and outlines the end-to-end vision of the product and what the product will become. Companies utilize the product strategy in strategic planning and marketing to identify the direction of the company’s activities.

The product strategy is composed of a variety of sequential processes to effectively achieve the vision. The company must know where they would like the product to take them in order to identify and plan for the necessary activities to reach that destination. This is similar in nature to a strategic vision of how a company wants to achieve its goals.

All great products start with a clear strategy that is customer and market-driven. Strategy not only ensures that you work on what matters. It is also essential so that you can communicate what matters to your team and organization.

How many times have you heard whispers from folks who question your work because they don’t understand the “why”? Consider your strategy and plan the “why.”

The main purpose of a strategy is to provide the product manager with direction so they can guide their product team and manage the business over the planning period. Strategies also help product managers communicate the products’ value to cross-functional teams and key stakeholders, who want to know how products will achieve high-level business objectives.

A product strategy is the foundation of a product lifecycle, and its execution plan for further development. As they develop their product strategy, product leaders zero in on target audiences and define key product and customer attributes.

Strategy is comprised of three parts: VisionGoals, and Initiatives.


A good vision describes who the customers are, what customers need, and how you plan to deliver a unique offering. The vision includes details on the market opportunity, target customers, positioning, a competitive analysis, and the go-to-market plan.


Goals define what you want to achieve in the next quarter, year, or 18 months. Here are a few examples:

  • Increase revenue by 30{0de7ec389855b9d7aef2e05c970773ef7994d079bf720baa24bf65e014cc7b5b}
  • Expand into 5 new countries
  • Increase mobile adoption by 100{0de7ec389855b9d7aef2e05c970773ef7994d079bf720baa24bf65e014cc7b5b}
  • Reduce the number of support tickets by 15{0de7ec389855b9d7aef2e05c970773ef7994d079bf720baa24bf65e014cc7b5b}


Initiatives are the high-level efforts that will help you achieve your goals. Here are some examples:

  • Performance improvements
  • UI improvements
  • Better reporting
  • Expand into China

You can confirm your strategy as you plan your roadmap, define your features, and prioritize your work. To visualize strategy using your roadmap, it helps if you link releases and features to initiatives and goals. At Aha! we call this the “red thread of strategy” — and believe that it’s essential to the roadmapping process.

Is your strategy already laid out on your roadmap? If so, analyze your roadmap at a high level to discover gaps. You should see relationships between product lines, products, goals, initiatives, and releases all on one screen. This process helps you find “orphan” goals or initiatives.

A great strategy starts with a clear product plan, a vision and a canvas that explains how customer and market forces shape the product’s direction. That’s why you must visualize your strategy and relationships — but the first step is to have a north star that tells where your product is headed.

Introduction to Creating a Product Roadmap

A roadmap communicates the why and what behind what you’re building. It’s a guiding strategic document as well as a plan for executing the strategy. A roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time.

The purpose of a product roadmap is to communicate direction and progress to internal teams and external stakeholders. It shows the high-level initiatives and the planned steps to get there. It should not include every feature in the product backlog, or a list of specific engineering bugs. The roadmap is a product management document and should live separately.

Creating a product roadmap should be a continuous process throughout the lifecycle of a product. Requirements and features should be generated by lots of folks including: customers, partners, sales, support, management, engineering, operations, and product management.

It is up to the product management team to determine the priorities and make sure the roadmap is aligned against the business goals.

The roadmap has several ultimate goals:

  • Describe the vision and strategy
  • Provide a guiding document for executing the strategy
  • Get internal stakeholders in alignment
  • Facilitate discussion of options and scenario planning
  • Help communicate to external stakeholders, including customers

Clearly articulating the product vision and strategy can make it easier to secure executive buy-in and to ensure everyone is working toward a common goal.

An example of a product roadmap

A product roadmap is a plan that matches short-term and long-term business goals with specific technology solutions to help meet those goals. Roadmapping is the exercise of building a product roadmap. Roadmaps can apply to new products or services or existing offerings.

Roadmaps can be created in different ways and to showcase different information including:

  • High level strategic initiatives
  • Releases by quarter
  • Detailed features
  • Maintenance and bug fixes

Product Roadmap Example

Building a product roadmap

To build a product roadmap you must know what your key business goals are and the initiatives that you are going to invest in to get there. Then you can decide which features are best aligned against your goals. This means you need an objective methodology to do this.

Here are some steps to determine which features to add to your roadmap based on what will have the biggest impact to the business:

Define your strategy
Product managers must establish a “goal first” approach and a true north for where their product is headed. This vision defines your outlook for the product, where it is headed, and what your team will build. And all amazing visions have their customers in mind.

A strong product vision is supported by details of who its customers are, what customers need, and your go-to-market plan. It captures the essence of what you want to achieve — the crucial information your team must understand to develop and maintain a winning product.

Customize releases
Select which features to highlight and choose whether to present internal or external data on each release. The external release date can be different than your internal release dates. It can also be rounded to a broader timeframe to be less precise (e.g. show releases by quarter).

For customer views, you can show the theme of the release and key features in which they will be interested. Internal stakeholders will want to understand the strategic importance, conveyed through goals and initiatives. You can also create views for specific customers, allowing your audience to see roadmaps that are relevant to their specific business objectives.

Prioritize features
As a product manager you have likely attended many meetings where everyone argued over which customer requests should get prioritized. Customer requests should always be ranked against your strategy. Scoring ideas takes subjectivity out of customer requests.

Each product can have a unique scorecard comprised of metrics that reflect your strategy, but make sense at a feature level. You can fully customize the metrics, scale, weighting, and complexity used to add quantification to your features. Build your scorecard in relation to your goal-first product vision. This ensures that your scorecard reflects what matters most to your product line and business. Once you create and implement your Scorecard, you have a more objective way to prioritize features on your roadmap.

The best way to consider customer requests is to design a goal-first roadmap that ranks these requests against your goals. All ideas should be considered against your strategy and those that will have the biggest impact should be prioritized.

Share your roadmap
Communication and transparency are essential to building great products. They’re also a must for keeping entire organizations aligned with your strategy. When you have the view you want, save it and/or share it with key stakeholders. Some software allows you to take nearly any view and publish it via a PDF or secure web page. Now you can proudly share your product plans and roadmap, easily keeping everyone up to date.

Everyone wants to see the same data—but each team wants to see it their own way. Product managers benefit from a focused approach that includes plenty of collaboration and planning to keep everyone on the same page.

Now it’s time to build the perfect roadmap, share your plans with the team and build what matters.

Introduction to Release Management

What is a release?

A product release is the launch of a new product or a combination of features that will provide value to customers or users. Digging deeper, a release is much more to both your customers and internal teams. For your customers, it’s a promise of new value they can look forward to embedding in their everyday work and activities. For your internal teams, a release helps them plan their work and when they’ll be needed to launch great products.

When we talk about releases, teams often confuse the roll-out of new features (a deployment) with the total customer experience. A release is not just the act of providing access to new technical functionality. Instead, think of a release as the date when the company is ready to deliver a new customer experience and support every customer interaction point associated with it.

Releases should take into account all the additional work that must be accomplished, such as updating the public website and training the customer support team. While the supporting teams (like development) may define a release through their lens of deploying code into production through a series of sprints, the product owner incorporates this perspective (and those of teams and customers) into a complete delivery.

Why plan releases anymore?

In agile development, you may feel that there is no need to plan actual releases — and some may consider the term “release planning” obsolete in an agile world. But the value of releases is methodology-agnostic. Releases define your themed product journey, and represent major launch milestones for that overall journey.

You may choose to call it a “launch,” an increment, or some other name. Regardless, it is still a new offering your customers will anticipate and ultimately expect. In addition, your internal supporting teams must accommodate the plan in their schedule if they are to assist your efforts.

A release — and the plan to get there — provide your customers a vision into the journey they’ll be taking with your product. The release and its place in the journey also provide your teams valuable information on when they may need to engage on a dependency or market a new innovation (as just a few examples). In an agile world, the actual dates of engagement may have less precision as far as committed targets. However, a general delivery plan – even in an agile framework – will continue to establish trust and expectation in your product with your customers and teams.

Feature roadmap with external dates.7343117bad2de886a07c7800588fa39d

Standardizing a release management process

A release management process may likely mean different things to a product management team and a development team. Both perspectives are strongly incorporated into a dependable release management process. A release management process incorporates all of the following:


An initial release plan takes into account the team’s velocity on the previous release (or general capacity to deliver) and the feature prioritization to create a general scope, sequencing, and timeline for the release. During release planning, a general expectation on the number of sprints or iterations to deliver the scope is achieved. The accuracy of this expectation and plan depends on whether the team’s capacity is well-known as well as the level of detail (or grooming) the scope has been through during estimation. This general plan will also provide expectations of major product changes (or dependencies) for products that may depend on your roadmap or platform.

Plans will be revisited after each iteration. For this reason, a tracking of an external release target (with quarterly, monthly, or other precision) can be helpful. It will still set the expectation and trust with your customers, but can be refined by you as the plan progresses.

Phased communication and supporting team engagement

Product managers know best how to deliver their product successfully — and that includes a series of non-development tasks of engagement with supporting teams to complete items like documentation, sales training, or marketing campaigns. As a product manager, establishing a launch or release template will enable you to create a “gold standard” for major delivery. Use this template to engage your greater team, who may be supporting multiple products in the portfolio only when needed. A standard for launch also sets expectation for when these teams will be needed internally.

Repeatable stages to readiness

Establish standardized status at both the release and feature level to indicate overall health of the plan. Status provides an “Are we good?” pulse point that can be key to seeing around corners and proactive risk mitigation. A release status will enable communication to your internal stakeholders, while feature status workflows enable granular visibility into the readiness of the feature and its current status with respect to development, staging, or QA environments.

Forward adjustment on plan

Regardless of whether your release plan is executed in sprints or via more waterfall methodologies, regular check-ins and adjustments to plan are necessary. Use your sprint closure to adjust plans as needed, or schedule regular reviews to ensure plans are on track.

Introduction to Idea Management

Idea management is the ability to capture feedback or insights from internal and external stakeholders for the purpose of adding this feedback into future products or product releases.

Every organization wants better ideas. But it is often too tough to capture them in a manageable way. And product teams need a way to quickly capture, categorize, and prioritize ideas. The best solution is to practice ideation — the creative process of generating, developing, and curating new ideas.

Better ideas lead to innovation, and innovation leads to market leadership. Ideation software provides an integrated means to capture and respond to customer feedback, recommendations, and questions within the context of submitted ideas. Ideation software also allows product teams to quickly answer ideas submitters once those ideas are prioritized and scheduled for future releases.

The most effective ideation software allows you to create as many ideas portals as you need. This means you can have one private portal to collect internal ideas, a separate public portal to collect customers ideas, and more. Here are some tips to consider while vetting your portals to practice ideation:

Ensure that information is complete
Idea management can be approved in several ways. To save time, start with a quick review of new ideas to determine if more information is needed. If so, email the idea submitter directly.

Merge duplicate ideas
Ideas that already exist should be merged. This reduces your list to unique ideas without losing the details and nuance of each request. When you merge two ideas, the one to which you merge becomes the “master” idea. All ideas merged from that point on should become part of that master group.

Prioritize ideas
Sometimes, you review an idea and know right away that it will be promoted to a feature. In other situations, the value of an idea is not as clear. These latter ideas should be prioritized based on projected benefits to the customer and business. You should have a process to score submitted ideas so that you can sort them effectively.

Promote ideas to features
When you promote an idea to a feature, a link is established between the original idea and the new feature. This ensures that a feature’s origin is always accessible. It also allows users who submit and subscribe to ideas to be automatically notified when an idea is implemented as a shipped feature.

Respond to those who provide feedback
Responding quickly to ideas with, “Yay”, “Nay”, or “Soon” has clear benefits for the person who submitted the idea — and anyone who has visibility. But this process helps the product team as well. It clearly communicates and reinforces product positioning and direction. Quick responses also encourage quality discussion and additional ideas.

Introduction to Requirements Management

Requirements management is the process of collecting, analyzing, refining, and prioritizing product requirements and then planning for their delivery. The purpose of requirements management is to ensure that the organization validates and meets the needs of its customers and external and internal stakeholders.

Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical.

Requirements management does not end with product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Thus the process begins again.

What is requirements management?

A requirement is a defined capability to which the results of certain work (in this case software development) should meet. It is a continuous process throughout the lifecycle of a product and requirements can be generated by many stakeholders including: customers, partners, sales, support, management, engineering, operations, and of course product management. When requirements are being properly curated and managed there is clear and consistent communication between the product team and engineering members and any needed changes are broadly shared with all stakeholders.

Introduction to Agile Development

Agile software development (Agile) is a collection of software development methodologies that promote adaptive planning, evolutionary development and delivery, continuous improvement, and a time-boxed period of time to complete a body of work. Software development is dynamic by nature, and Agile encourages rapid and flexible response to change. Because adaptability is central to its conceptual framework, teams using this approach are well-equipped to respond to changes throughout the development cycle.

In addition to being a collection of methodologies, Agile software development also promotes a different way of thinking or mindset about how to build things and evolve processes to deliver continuous improvement. Agile facilitates information-sharing amongst teammates, where everyone has a say on processes and practices and decisions are made together as a team.


Concepts of incremental and adaptive software development processes date back as early as the 1950s, with growth and progress from a small vocal minority through the 1980s. It was not until the 1990s, when an assortment of similar lightweight software development methods emerged in reaction to waterfall-oriented methods, that Agile started to gain some traction. The real watershed moment for the Agile movement was the publication of The Manifesto for Agile Software Development in 2001 by a group of 17 software developers, who met to discuss the collection of lightweight development methods, which is now referred to as Agile methods.


Emerging from the Agile Manifesto were the following set of core values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan


The authors of the Agile Manifesto also agreed upon the following 12 principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within the development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Popular Methods

The most popular Agile methodologies used by practitioners today consists of the following: Scrum, XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), ASD (Adaptive Software Development), Crystal, and LSD (Lean Software Development). Also, while Kanban is not considered an Agile development method, it is commonly used in conjunction with Agile methods as a means for increasing efficiency.

When it comes to comparing and choosing which method is best for a team, the idiom “different horses for different courses” comes to mind. The Agile PrepCast has compiled a helpful methods comparison table based on the following characteristics: project size, team size, iteration length, roles and responsibilities, virtual team support, risk mitigation level, customer interaction, pros, and cons.

The most popular Agile methods are Scrum and XP, and they are very much aligned in their practices. The notable differences between the two are as follows:

  1. Scrum team iterations, which are called sprints, tend to be two weeks to one month in duration. XP teams work in iterations that are one to two weeks long.
  2. Scrum teams do not allow changes into their sprints, whereas XP teams are much more open to making changes within their iterations.
  3. XP teams work in a strict priority order as determined by who is serving in the ‘customer’ role, whereas a Product Owner prioritizes the backlog items for a sprint. However, the team has the freedom to determine the sequence in which they are developed.
  4. Scrum is much more focused on management practices and less defined when it comes to engineering practices. XP incorporates common technical practices such as test-driven development, automated testing, pair programming, and more. Scrum teams have more freedom to define the engineering practices they wish to follow, but they often use many of the same practices defined as part of XP.

In the end, many teams ultimately settle into a hybrid Agile methodology that is a combination of Scrum and XP.

Lean software development (LSD), more commonly referred to as “Lean,” is based on the principles of lean manufacturing which originated from the Toyota Production System. Lean is based on a set of principles aimed at achieving quality, speed, and customer alignment. This method is commonly adopted by startups.

A key tenet of Lean is to work only on those things that absolutely must be done and to eliminate waste in the form of unnecessary meetings, tasks, and documentation. There are different camps as to whether Lean should be considered an Agile method in and of itself, or viewed as a complementary mindset that helps with the achievement of Agile goals.

Kanban is a model for introducing change through incremental improvements and is complementary to Agile methods. Work is organized on a Kanban board, where work is tracked through various workflow states flowing from left to right. The only management or process criteria introduced by Kanban is “Work in Progress (WIP),” which defines WIP limits for the various workflow states.

If a certain state or status hits the limit, the whole team needs to help clear the filled-up state first before beginning any other work. The Kanban board is ultimately intended to help teams identify bottlenecks and work toward eliminating them in the future.

Agile Product Management

Agile Tools and Terminology

The following are common tools used by Agile practitioners as identified by Chris Sims and Hillary Louis Johnson, authors of “The Elements of Scrum.” The tools are most often associated with Scrum, the most popular of the Agile methods, but are commonly used for other methods as well.

The product backlog is a list of desired deliverables, or to-dos, for the product. This encompasses features, documentation requirements, bugs and anything else of value that must be done as part of delivering a new product or product updates. A best practice for backlog items, commonly referred to as user stories, is to focus on the product capability or the “what” that is required instead of the “how,” and to sort backlog items in their order of prioritization.

The sprint, or iteration backlog, represents the team’s work tasks for a planned sprint or iteration. A sprint has a finite timeframe usually spanning two weeks to a month, and represents a commitment as to what the team can deliver during that time. Work tasks are commonly broken down into user stories representing the “what” that is being delivered and tasks representing the work required to deliver the user stories.

Burn charts represent the relationship between time and scope. They are a common method for tracking progress on an individual sprint or iteration or across an Agile project that is planned to take a number of iterations. Some teams use burn-up charts to show how much work has been completed over a period of time.

The more common use is the burn-down chart, which shows work that remains. When work or scope is added or removed, the vertical line on the chart moves up or down accordingly to reflect the amount of work added or removed. Aside from scope changes, the burn-down chart will show work being completed and work that remains.

Example burn-down chart:

Agile Product Development

Agile teams will use some form of task board to represent work that is to be done during an iteration. The visual board is used to facilitate Agile planning meetings, reflects the prioritization of tasks, and aids with brainstorming how tasks will best be executed. The board clarifies the work that needs done as part of the iteration backlog, helps with managing team capacity and assignments, and prevents tasks that must be completed from being lost or overlooked. This is where Agile teams often opt to use a Kanban board: to manage tasks through the different workflow states.

Software for Agile Development

Agile Roles

Agile teams often have different roles with different names, depending on the methodology used. The common Agile roles include the following:

Team lead, scrum master (Scrum), team coach or project lead
Acts as the coach responsible for facilitating and guiding the team, obtaining resources when required, and removing impediments that keep the team from doing their work.

This role often encompasses the soft skills of project management more than planning and technical skills, which are often left to the team as a whole. It is important to note that this person is not necessarily the manager of the team; rather, this role should reflect knowledge and responsibilities over rank.

Team member
Responsible for the creation and delivery of the project. The team members will normally be comprised of developers, QA, and documentation. They are responsible for planning, design, development, testing, and project delivery.
Product Owner (Scrum), on-site customer (XP), active stakeholder
Represents the voice of the customer and is responsible for the prioritized backlog and maximizing the return on investment (ROI). Part of the responsibility of this role includes documenting user stories or requirements for the project.
Represents a broad category of people who can be users, managers of users, operations, support, portfolio managers, other Agile teams with dependencies, executive team, investors, and more.

In addition to these common roles, Agile teams will sometimes have extended cast members, who are called upon to provide technical or domain expertise for certain specialized skills that may not be present amongst the team members.

Likewise, it is not always reasonable or fair to expect product owners to be so-called experts on every facet of a product or domain. This is when they call in domain experts to assist the team with certain requirements.

Improving how teams innovate is a continuous journey, and new methodologies will certainly emerge over time, as well as best practices for software development. Teams will find that different approaches are available and work better for them. But the impact of Agile on product development cannot be understated, with its focus on the customer and the art of collaboration.