Agile Product Management, Agile methodologies and development

What Is Agile Product Management?
Agile Product Management is a flexible and iterative approach to product
development. It embraces change, encourages continuous feedback from users, and
adapts quickly to market shifts. Unlike traditional methods like Waterfall, which follow
a strict sequence of phases, the Agile approach breaks down development into
smaller tasks, with regular evaluations at different stages.
Agile Product Development: What, why, and how
What: In traditional software development, any strategic pivot would often involve
weeks or even months of work. Agile was created as an answer to this problem, as it
introduces new frameworks and methodologies that allow for quick responses to
unforeseen problems vis-a-vis iterative development that costs minimal loss of time
and resources.
Why: It’s not just about saving time and money. It’s also about making better
products. The core tenet of Agile is keeping development user-focused and lean.
With an ever-shifting roadmap, Agile allows teams to repeatedly ask themselves,
‘Are we going in the right direction?’ at many different stages.
Agile is about much more than simply reacting to change. It’s about expecting that
things will inevitably change and embracing it. When a product team is equipped to
adapt, it can build the right product at the right time in the right way.
How: The main way Agile achieves this is by breaking down large tasks into smaller
chunks and intelligently distributing the work among teams that work closely with
each other, rather than having one team working on one thing at a time. A policy of
open communication, collaboration, and transparency ensures that teams aren’t
working in silos and accidentally building in different directions.
Various frameworks and methods that fall under the Agile umbrella can dictate how
this is done, including Scrum, Kanban, and others covered below. In truth, there are
many ways to be Agile and be an Agile Product Manager. Agile is more a mindset
and a set of principles, which come with a toolbox that businesses can use according
to their specific needs. That way, Agile can work for anyone and everyone.
The Agile Manifesto: Principles
The Agile Manifesto was created in 2001 by 17 software developers who sought a
better approach to software development. Frustrated with rigid, slow-moving
traditional methods like Waterfall, they gathered at a ski resort in Utah to discuss
more flexible, collaborative alternatives. They outlined values and principles that
prioritize customer collaboration, adaptability, and delivering working software in
short, iterative cycles. This philosophy aimed to improve efficiency and
responsiveness in development, laying the foundation for modern Agile
methodologies like Scrum and Kanban.

The twelve principles of the Agile Manifesto are still detailed on the original
website from 2001(an excellent time capsule if you want to remember the early-
2000s internet).
In brief, the twelve principles of Agile software development are:
1. Customer satisfaction is the highest priority.
2. Welcoming changing requirements.
3. Delivering work frequently.
4. Business and tech to work together frequently throughout.
5. People-driven development with maximum support for teams.
6. Preference for face-to-face communication.
7. Working software is the primary measure of success.
8. Sustainable development with teams working at a constant pace
throughout.
9. Attention to detail, technical excellence, and good design.
10. Simplicity is essential.
11. Self-organizing teams.
12. Teams reflect at regular intervals on what could be done better.
Agile is designed to be flexible, which is why the principles can be interpreted and
implemented in a variety of ways depending on the needs of the company. It’s a set
of guidelines rather than actual rules.
Pros and Cons of Agile Product Management
The benefits of Agile Product management are many, and many Product Managers
feel they outweigh the challenges if managed effectively.
Pros:
 Flexibility: Agile allows teams to pivot quickly in response to new
data or market shifts.
 Customer-centric: The focus on user stories and continuous testing
keeps development aligned with customer needs.
 Speed: Smaller development cycles (sprints) deliver quicker results,
allowing for faster time-to-market.
 Collaboration: Agile encourages cross-functional teamwork and
regular communication through daily standups and reviews.
 Creativity: The focus on brainstorming, iteration, and coming at a
problem from all sides helps teams create things they would never
have thought of otherwise.
“Creativity is about letting go of bias, letting go of convention, and being
willing to explore and iterate. Failure is part of the process. It’s about creating
an environment where people feel safe to experiment and take risks.”

— Robert Brunner, Chief Designer at Beats by Dr. Dre, on The Product
Podcast: The Designer Behind Apple’s $1.5 Billion Success
Cons:
 Feature creep: Agile’s adaptability can lead to uncontrolled or
continuous addition of new features to a product during development.
 Estimation challenges: Predicting delivery dates or total project
costs can be difficult due to the iterative nature.
 Coordination challenges at scale: While Agile works well with
smaller teams, scaling it across large organizations (without
frameworks like SAFe) can be complex.
Agile vs. Waterfall
The easiest way to understand what Agile brings to the table is to see the difference
between the old ways of working and the new Agile ways of working.
Before Agile, there was Waterfall, which is still popular in some traditional software
companies. The name is derived from the flow of work, which comes from the top
down. Work is broken down into sequences, and development is linear. This means
that each stage of the sequence must be completed before teams can move on to
the next stage.
The main problem with waterfall for digital product development is that it’s very
expensive to go back and make changes. When you’re already at the verification
stage, and you realize that you need some serious design changes, you’re going to
have to repeat a lot of work to get that done.
Another issue with waterfall for digital products is that it’s not particularly customer-
focused. Agile tries to keep the customer involved at every stage. (For example,
smaller projects for the engineers to work on are called ‘user stories,’ and they’re
written from the customer's POV.)
Agile comes with strong project/product documentation, and having product
requirements decided upon upfront makes it much easier to estimate budgets and
timelines.
The Challenges of Transitioning from Waterfall to Agile
Shifting from a Waterfall approach to Agile Product Management can be a
daunting process, especially for organizations accustomed to the structured, linear
flow of Waterfall.
Key challenges include:
1. Cultural resistance: Teams and stakeholders used to detailed
upfront planning may resist the shift to iterative development.

2. Process overhaul: Agile requires restructuring workflows,
emphasizing collaboration and continuous feedback. This can be
difficult for companies accustomed to working in silos.
3. Mindset shift: Agile demands a shift from long-term planning to
shorter, adaptive cycles. Teams need to be comfortable with
ambiguity and evolving priorities.
4. Training: Teams need to be trained on Agile frameworks like Scrum
or Kanban, which takes time and effort.
To transform an organization into an Agile one, start small by piloting Agile with one
team and gradually roll it out across the organization.
Agile Product Planning
Agile Product Management is a dynamic, flexible approach that emphasizes short-
term goals, constant iteration, and regular user feedback. At the heart of the Agile
process are well-defined activities that ensure the product evolves based on real-
world insights rather than rigid long-term plans.
The steps below and their names can vary slightly depending on whether a product
team is using Scrum, Kanban, or another Agile framework (see below for more
detail). However, regardless of the methodology, these phases represent the
backbone of Agile Product Management processes.
1. Backlog Creation and Refinement
The product backlog is a dynamic, prioritized list of features, tasks, bugs, and user
stories. Created by the product owner, it outlines everything that needs to be done.
Continuous backlog refinement ensures that the team is always focused on the most
valuable items at any given time.
Themes, Epics, Stories, and Tasks
In Agile product management, work is organized in a hierarchy to ensure clarity and
alignment across teams. Scrum, SAFe, and other iterative models tend to break
them down by themes, epics, user stories, and tasks:
 Themes: High-level initiatives that align with the strategic goals of the
product. They group related epics and stories under a common goal
(e.g., improving user engagement).
 Epics: Large bodies of work that are broken down into smaller,
manageable pieces. Epics often span multiple sprints and are broken
down into stories (e.g., building a new user onboarding experience).
 User Stories: Short, specific descriptions of a feature or functionality
from the user’s perspective. They capture what the user wants to

achieve and why (e.g., “As a new user, I want to reset my password
easily”).
 Tasks: The smallest unit of work, representing the specific to-dos
that a team needs to complete in order to deliver a user story (e.g.,
adding a ‘forgot password’ button).
2. Sprint Planning
Especially important in Scrum, each sprint begins with sprint planning, where the
team selects a set of items from the backlog to work on during the next sprint
(usually 1-4 weeks). The goal is to ensure everyone understands the priorities and
how to achieve them, breaking down tasks into smaller, actionable steps.
Design Sprint Template
Use design thinking to solve design problems and reduce production risks.
GET THE TEMPLATE
3. Acceptance Criteria
Before development begins, each user story or task in the sprint backlog must have
clear, defined acceptance criteria. These are the conditions that must be met for the
story to be considered complete and acceptable by the product owner or
stakeholders.
4. Daily Standups
Especially important in Kanban and other continuous development frameworks, daily
standups are quick, focused meetings (usually 15 minutes) held to review progress
and address any blockers. They ensure transparency and alignment, keeping the
team on track and aware of potential roadblocks.
5. Sprint Review
At the end of each sprint, teams hold a sprint review to demonstrate completed
work and gather feedback from stakeholders. This is an opportunity to ensure the
team is building the right product and to make course corrections if needed.
6. Retrospective
After each sprint, the team conducts a retrospective to reflect on what went well,
what didn’t, and how to improve. This process ensures continuous learning and
improvement, making future sprints more efficient.
Product Retrospective Template

Experience continuous growth, learn from failure faster, and identify issues
early with our Retrospective template.
GET THE TEMPLATE
7. Release and Incremental Delivery
Rather than waiting for a final, polished product, Agile product management
emphasizes frequent releases. Small, iterative releases allow teams to get
feedback early and often, making adjustments as needed before the next release
cycle.
Agile Product Lifecycle Management
The Agile product lifecycle focuses on how a product evolves from concept to
release and beyond. It’s a holistic view of managing a product through various
stages, ensuring iterative improvement, maintenance, and adaptability in the face of
changing customer needs or market dynamics.
1. Concept and Ideation
The Agile lifecycle starts with a high-level vision during the concept and
ideation phase. The product manager works closely with stakeholders to define
epics, themes, and user stories, creating a flexible roadmap. Unlike traditional
methods, this vision remains fluid, allowing for adaptability as new information arises.
2. Development Iterations
Throughout the lifecycle, the product undergoes several development iterations.
Each sprint produces an increment of the product, allowing teams to add value
incrementally. This approach ensures that teams can react quickly to feedback or
changes rather than being tied to a rigid plan.
3. User Feedback and Validation
User feedback is critical at every stage of the Agile lifecycle. After each iteration, the
product is tested by real users, and feedback is gathered. This continuous validation
ensures that the product evolves in line with user needs and expectations.
4. Release Planning and Delivery
In Agile product lifecycle management, release planning is iterative and flexible.
Each release is built on previous iterations, allowing for regular, small improvements
to be delivered to users. Frequent, smaller releases reduce risk and enable teams to
adapt quickly to real-world demands.
5. Post-Release Maintenance and Growth

Agile doesn’t end with a product release. Post-release maintenance is an essential
part of the product lifecycle, ensuring ongoing improvements and responding to any
issues that arise. Teams continue to monitor the product’s performance, releasing
updates, new features, and fixes regularly to ensure long-term growth and customer
satisfaction.
Roles in Agile Product Teams
Important Roles in Agile Product Management
In Agile Product Management, a well-organized team is key to delivering
successful products. Let’s break down the roles:
1. Product Manager: The owner of the product vision and strategy.
They ensure the product aligns with the company’s goals and
delivers value to the users.
2. Product Owner: Often works within Scrum teams, translating the
Product Manager’s vision into actionable user stories and managing
the product backlog.
3. Scrum Master: Facilitates Scrum processes, ensures teams are
adhering to Scrum principles, and removes obstacles that might slow
down progress.
4. Agile Coach: Similar to a Scrum Master, but for Kanban.
5. Development Team: Cross-functional engineers and developers
who build the product.
6. UX/UI Designers: Focus on creating user-friendly designs based on
user stories and feedback.
These roles work closely together to deliver iterations of the product, with frequent
communication and collaboration.
The Role of the Agile Product Manager
So now you might be asking yourself, “What does a Product Manager do in Agile?”
Firstly, the Product Manager is the owner of the product vision, which is absolutely
key in Agile. When you’ve got teams working concurrently towards the same goal,
the main thing that can derail development is a lack of a strong product vision.
During Agile development, you’re all trying to get from A to B. A being no product at
all, and B being a great product which fulfills the vision. Throughout the journey, you
may take different routes and unexpected detours, but as long as your vision for the
destination remains solid, you’ll all find your way there.
Product Manager vs Product Owner

How does a Product Owner differ from a Product Manager? A Product Owner
(PO) is more specifically found within the Scrum framework. While a typical Product
Manager touches almost all aspects of digital product development, a product owner
has a more defined role, especially within a company that uses Scrum. (We’ll get into
Scrum in a second!)
The role of the Product Owner is clearly defined — managing the product backlog
and ensuring the team delivers value.
The role of a Product Manager, however, is typically found in broader product
management frameworks outside of Scrum. It originated from traditional business
and marketing practices, particularly in companies that developed products for
consumer markets.
Agile Product Roadmaps
Product roadmaps come in many forms, but there are a few key characteristics that
make for the perfect Agile roadmap.
1. Accessible: Agile roadmaps are shared with those who need them
the most, but they are generally accessible to everyone within the
organization. Agile understands that all touchpoints of the business
can benefit from understanding the development process, and
keeping the roadmap available to them is a boon.
2. Collaborative: The Product Manager/product owner owns the
roadmap and is ultimately responsible for it, but roadmaps are
seldom built in a vacuum. Collaboration is absolutely key for a
successful Agile roadmap.
3. Changeable: “Don’t laminate the roadmap!” As we’ve said, Agile
doesn’t just allow for change, it anticipates and embraces it. So
remember that the roadmap is an ever-changing thing. Only the
vision must remain strong and solid. The journey there will be long
and winding, with many unexpected turns.
Product Roadmap Template
Download our easy-to-use template to help you create your Product
Roadmap.
GET THE TEMPLATE
Agile Product Management Frameworks

There are probably more Agile methodology frameworks than there are people who
signed the Agile Manifesto (17, in case you forgot). Here, we will explain some of the
most common ones.
Agile framework theories: Sprint-based vs. continuous
While the difference between a Scrum and Kanban board may appear minimal, they
support two different ways of working. Scrum is sprint-based, and Kanban is
continuous.
A team using the Scrum framework decides what it will do during a sprint and only
pulls new items from the backlog at the beginning of the next sprint. On the other
hand, teams using Kanban work on a task until it is finished, at which point another
task is pulled from the backlog, and so on.
 Sprint-based: Scrum, SAFe
 Continuous: Kanban
 Hybrid (Uses both time-boxed and continuous elements): Spotify
model, Dual-track Agile
Scrum
Scrum is often described as ‘simple to understand, difficult to master.' It takes years
of practice to be considered adept. The core principles behind Scrum are to make
complicated tasks as simple as possible while helping the team to complete work as
efficiently as possible.
The product owner manages and prioritizes the team’s backlog, which consists
of user stories. A self-organizing team will then work concurrently on those stories
during a period of time known as a sprint. Using the notorious stick-notes-and-
whiteboard setup (in physical or digital form), the whole team can see what everyone
is working on and keep track of the product’s progress.
Teams will meet once a day for about 15 minutes, which is known as a scrum. These
team meetings ensure that the team stays in touch throughout their progress, and
scrums are an opportunity to workshop various problems. Keeping the teams in
touch in this way helps to foster understanding and provides a full 360-degree view
of what the product is looking like right now.
The Scrum master organizes the whole process. They’ll manage the whiteboard, call
the scrums, and basically make sure the whole operation stays on track!
Kanban
Some companies use Kanban without realizing it! Its main principles are total
transparency and real-time communication, which help teams always be aware of a
product’s progress. Tasks needed to be completed are visually represented on a
Kanban board, which is continuously updated according to which phase the task is
in. This aids in planning and time estimations.

Basic Kanban flows may be a recognizable three-step process: To Do—In Progress
—Done. But in the software development world, they’re often more complicated.
Kanban is particularly popular with software development teams as it’s lean and very
easy to understand. Teams can also run it themselves without needing too much
interference from higher up.
Cycle time is used to track how long tasks take to be completed, allowing for more
accurate predictions of completion times for the overall product. Beloved by teams
for how well it reduces bottlenecks and encourages cross-functional collaboration,
kanban will often be the first Agile framework a company implements in its Agile
transformation.
SAFe: Scaling Agile
While Agile is often associated with nimble startups, scaling Agile across large
organizations presents unique challenges. That’s where SAFe (Scaled Agile
Framework) comes in, designed to bring Agile principles to enterprises while
maintaining alignment and coordination across multiple teams and departments.
SAFe enables large organizations to adopt Agile by structuring work at different
levels: Team, Program, Large Solution, and Portfolio. This hierarchical structure
ensures that teams operate autonomously while still aligning with broader
organizational goals.
Key Components of SAFe:

1. Agile Release Train (ART): A key SAFe concept, the ART
comprises multiple Agile teams (usually 5-12) that work together to
deliver value incrementally in Program Increments (PIs), which are
usually 8-12 weeks long.
2. Program Increments (PIs): PIs are the equivalent of larger sprints in
SAFe. They are composed of multiple iterations and culminate in a
release or major feature delivery. Each PI includes planning,
execution, and a review to ensure alignment across teams.
3. Lean-Agile Leadership: SAFe emphasizes strong leadership to
drive cultural change and support Agile adoption at scale. Leaders
must model Lean-Agile principles and help remove obstacles for
teams.
4. Built-in Quality and Continuous Delivery: Quality is a key tenet of
SAFe. Each feature or product increment must meet defined
standards of quality, ensuring that value is delivered consistently.
SAFe provides the structure and flexibility that large organizations need to scale
Agile while maintaining alignment, transparency, and efficient execution across the
entire enterprise.
The Spotify Model
Another model for scaling products using Agile methodologies is the Spotify Model,
which attracted people’s interest almost as quickly as the streaming service itself.
In 2012, Henrik Kniberg and Anders Ivarsson released a whitepaper, Scaling Agile
@ Spotify. The paper sets out Spotify’s approach to Agile product development:
Teams, known as Squads, each select their own framework (Kanban, Scrum, etc)
and work within a group of teams known as a Tribe. Tribes are then organized into
Chapters and Guilds.
It’s a system that looks complicated on paper but has helped Spotify reach millions
of users. The main goal of the Spotify Model is to promote collaboration and
autonomy within and across teams and reduce bureaucracy.
Dual-track
The Dual-track Agile framework combines continuous discovery and delivery into
parallel tracks, enhancing Agile's capacity for efficient, responsive, and customer-
centric product development. One of the most lauded benefits of dual-track agile is
that it brings developers into the product discovery process by placing an emphasis
on product outcomes.
Instead of developers considering their job done as soon as they deliver the product,
they respond in real time to user feedback and new pain points as they surface.

Teams never stop learning, which means Discovery never stops, nor does
Development when the Dual-Track Agile process weaves together both aspects.
Cycle 0:
Plan and gather customer data. You’ll notice that this first step isn’t assigned to
either track. Dual-track agile includes everyone in the initial discovery phase.
Cycle 1:
 Developers get started in the foundational coding that requires little
input from design
 Designers get to work designing for Cycle 2
 Product managers gather data for Cycle 3
Cycle 2:
 Developers implement 1st round of designs
 Designers work on Cycle 3 designs based on 3rd data set
 QA testers review Cycle 1 code
 PMs gather data for Cycle 4
Cycle 3:
 Developers implement 2nd round of designs
 Designers work on Cycle 4 designs based on 3rd set of data
set
 QA testers review Cycle 2 code
 PMs gather data for Cycle 5
Notice that there is no “done column.” The cycles continue until the desired
outcomes are reached.
“To understand design, you need to get beyond the basic schedule and really
understand what happens at each phase—research, concept development,
and how design is maintained through engineering. It's about building bridges
between different cultures and organizations.”
— Robert Brunner, Chief Designer at Beats by Dr. Dre in The Product Podcast: The
Designer Behind Apple’s $1.5 Billion Success
Prioritization Frameworks Used in Agile Product
Management
Prioritization of tasks and features is crucial in Agile Product Management, as
teams are often balancing competing needs, tight deadlines, and limited resources.

Prioritization frameworks make it possible to put order to and refine the backlog.
Without proper prioritization, teams risk wasting time on low-impact features.
Some prioritization methods that Agile teams love include:
1. MoSCoW: Prioritize features as Must have, Should have, Could
have, and Won’t have.
2. RICE: Rank features based on Reach, Impact, Confidence, and
Effort.
3. Kano: Classify features based on how they meet user expectations,
from basic needs to delighting them.
4. WJSF: Optimize the product backlog for value by dividing Cost of
Delay by job duration.
MoSCoW
Building a list of features and categorizing them by whether they’re ‘Must Have,’
‘Should Have,’ ‘Could Have,’ or ‘Won’t Have.’ It’s a simple method that helps to
communicate the priorities to stakeholders.
Kano
The Kano model, created by Dr. Noriaki Kano in Tokyo in 1984, plots a feature on a
graph depending on how it satisfies users, and how it meets their needs.
RICE

A RICE Score is calculated by combining the Reach, Impact, and Confidence in a
feature and dividing by the effort (usually denoted in hours of work needed) to give a
numerical score.
WSFJ
Applying the Weighted Shortest Job First framework is a great way to optimize the
product backlog for value. The WSJF formula is the ratio of the "Cost of Delay"
(CoD) to the job duration. The idea behind WSJF is simple: do the easiest and most
impactful features first and the lowest impact initiatives that take a long time last.

Agile Product Management Tools
The right Agile Product Management software can make all the difference in keeping
your team aligned, efficient, and on track.
1. Jira: A popular tool for managing sprints, backlogs, and user stories
in Scrum and Kanban.
2. Trello: Ideal for smaller teams, it offers a Kanban-style board for
tracking progress.
3. Airfocus: Allows teams to build strategic and lean roadmaps,
prioritize, and collaborate.
4. Monday.com: Offers customizable workflows that can support Agile
practices.
5. Lucid: Used for team collaboration, documentation, and knowledge
sharing, Lucid virtual whiteboards help teams ideate, plan, design,
and build.
Choosing Tools for Agile
Before you even begin work, you need to choose the right Agile tools. There are
plenty of shiny new tools out there that are brilliantly suited for Agile product
development. Unfortunately, that means there can be too many to choose from.
When you’ve got ten feasible roadmapping tools, how do you choose the right one?
There are a few things you can look at:
1. Price. Obviously, a huge corporation won’t need to base its tool
choices on the price tag as much as a smaller startup, but it’s often
the first consideration for all companies.

2. Functionality. Does it do everything you need it to do? Can you make
life easier by having one tool that does three things rather than three
separate tools?
3. Customer support. If there’s a tool that you would rely on fairly
heavily (as in, everybody takes the morning off if this thing goes
down), you’ll want something that comes with excellent customer
service to get you back up and running again.
4. Accessibility. Is this something that all of your teams who need it will
be able to use? Eg, if you have product marketers who need access
to data, but they’re not data scientists, maybe a tool that’s more user-
friendly would be a better fit than one that’s pure SQL.
Agile Transformation: Best Practices
Agile is a long-term investment and may involve a complete restructuring of how a
company operates. Nowadays, almost every tech company uses Agile principles, at
least somewhere in the business. However, that doesn’t mean that they are getting
as much as they could out of the Agile philosophy.
Successfully pulling off an Agile transformation takes grit, determination, and a lot of
trial and error. According to McKinsey, a transformation touches every facet of an
organization.
New startups or companies looking to make a bigger commitment to Agile
development principles can begin implementing in the following ways:
1. Define your end state
Before you even begin taking the steps towards a complete Agile transformation, you
need to decide on what Agile looks like to you – and get everyone on board. Start
from the top down, until everyone understands what the vision of your new Agile
organization is going to look like, in the ideal endgame.
2. Build your roadmap
This is something you should feel very familiar with! A good PM never dives into
anything without a plan, which is why you need to build your plan to get from where
you are to where you want to be.
3. Establish lines of communication
When you’re disrupting the way your company operates, the first thing that can go
wrong is for communications to break down. Communication within Agile is
transparent and regular and comes with clear systems. Implementing that as early
as possible will help your teams adopt the right mindset for Agile and make the
overall transformation process much smoother.

4. Iterate
Check in with all teams affected by the transformation at regular intervals, and don’t
be afraid to adapt and adjust your plan. After all, that’s what Agile is all about.
5. Predict and measure impact on business objectives
Don’t wait until you’ve ‘completed’ your digital transformation to measure the impact
on your business objectives. You can adjust these predictions as you move along
your roadmap and see the real-time impact.
Sprint to the Finish!
So, there you have it—your crash course in all things Agile! Whether you’re sprinting
like a pro in Scrum, flowing continuously with Kanban, or scaling like a boss with
SAFe, the key takeaway is this: Agile is all about flexibility, collaboration, and
delivering value. It's not just a framework or a methodology—it's a mindset that helps
you adapt, iterate, and keep your customers at the heart of everything.
Sure, there might be a few bumps on the road, like feature creep or the occasional
sprint headache, but what are the rewards? Oh, they’re worth it. Faster releases,
more engaged teams, and products that actually solve user problems. And
remember, whether you’re navigating themes, epics, stories, or tasks, just keep
asking: Are we delivering the right value right now?

Agile Product Management, Agile methodologies and development

More Related Content

Similar to Agile Product Management, Agile methodologies and development (20)

More from Pabitha Chidambaram (15)

Recently uploaded (20)

Agile Product Management, Agile methodologies and development