Strategic Project

Alignment in
an Agile World
Managing projects that quickly deliver value
to customers while achieving strategic goals
and objectives
Table of Contents
Why we wrote this ebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Project management—what’s the point? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Waterfall vs. Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Agile in practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Agile roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Events and artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Roadmaps and project plans in an Agile world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Agile and strategic planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 2

Why we wrote this ebook
Agile has been around for decades, but it is still a bit amorphous and
mysterious to the uninitiated. At its core, Agile removes the shackles from
product development. Instead of prescribing and specifying every last detail
before work commences, engineers partner with the product team to deliver
functionality in quick, iterative bursts.
Forward-thinking senior managers obsess over Agile, which drives its use
in software development and engineering. As a result, those not directly
involved in writing code and shipping software can feel like outsiders.
Agile and strategic planning might seem at odds to the uninitiated since
engineering autonomy and building software in two-week chunks can lead to
unexpected implementation decisions. Yet, with all the talk of rapid iteration,
learning on the fly, and “self-organizing teams” operating independently,
where is the space for long-range planning for complex initiatives?
These two worlds shouldn’t be mutually exclusive and are, in many cases,
entirely complimentary. The ebook aims to demystify Agile and explain how
those in its orbit can extract maximum value from the Agile methodology
while still staying true to company leadership’s overall vision and strategic
goals. Engineers, CTOs, and developers might spearhead Agile adherence
within the organization, but its benefits range far beyond the nuts and bolts
of how software gets built. Project managers and product leaders can all
reap the benefits of Agile when they understand what it has to offer and how
to structure projects and programs to get the desired results.
Agile works to everyone’s benefit due to its strategic alignment—ensuring
that the goals and objectives are agreed upon and mutually understood
from the C-suite to entry-level QA staff. When everyone has the same,
shared purpose, Agile can supercharge the team and dramatically shorten
the time between ideation and delivery, giving the business more time to
learn and grow throughout the product’s lifecycle.
Agile can dramatically shorten the
time between ideation and delivery.
The ebook will explain the practical elements of Agile and how those new
to the methodology can prepare for and engage with the process. The
goal isn’t to win over more passionate adherents but rather to point out the
critical need-to-know aspects of the methodology and the best position for
organizations to thrive and succeed.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 3
Project management—what’s the point?­
Planning out and managing complex projects is nothing new. Humans have
done this type of work for millennia. Whether on a smaller scale, such as
building a shelter or on massive undertakings like the pyramids of Egypt.
Almost any initiative requiring
multiple steps, collaboration,
resource planning, or a blueprint
needs project management.
Almost any initiative requiring multiple steps, collaboration, resource
planning, or a blueprint needs project management. Project managers
provide oversight to ensure the result meets the expectations and
requirements while (ideally) being completed on time and under budget.
Steps must be broken down, completed in the correct order, supplies
acquired and ready when needed. Construction sites, factories, and
kitchens are all modern-day examples where project management skills are
employed every day.
When planning, designing, building, selling, delivering and supporting
products, project management is the only way those things all happen
on time. Communication, assigning tasks, coordination, and monitoring
progress are essential parts of any successful delivery, and as products
become more complex, that need only grows greater.
While there are many ways to approach this, most product development
organizations tend to use methods and processes that fall into one of two
camps: Waterfall or Agile.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 4
 WATERFALL AGILE

Deliver results only at the end Deliver results early and

of project often, continuously

Perfect for long-term projects like Perfect for IT and software

construction or manufacturing projects, and marketing, too

Waterfall vs. Agile Change has to be managed

and controlled, lest it impacts
Enables change more easily
on projects
project negatively

The end product is defined and

Supports changing reqs, either in
fixed, regardless of changing
the market or technologies
market or technological needs

Delivering by tasks in succession

Delivering in sprints, supports
creates task and team
nimble product teams
dependencies, more fixed teams

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 5

Waterfall method

Product professionals think of Waterfall as the “original” methodology for
building software. It’s been around since the 1970s, although it didn’t get
its official name until 1976. It was the only way anyone would try to build
software for decades, unchallenged in its utility and cemented in place due
to its seemingly inarguable logical approach.
In a nutshell, waterfall product development is all about the order of
operations. Finish step one before starting step two, which always comes
3. The user experience team creates design specifications and mock-
ups to show the development team how things will work from an
end-user perspective.
4. The product development team creates a functional specification that
specifies exactly how everything will be built and operated.
5. The product development team may also create an architectural

before step three, and so on. overview of how different systems will communicate and the data flow.

6. The quality assurance team creates a test plan that expressly

confirms each requirement in the PRD works as specified in the
IN PRACTICE, IT TENDS TO LOOK SOMETHING LIKE THIS: functional specification.

1. Product marketing creates a Market Requirements Document

7. Product development team members are assigned explicit tasks to
(MRD) or Business Requirements Document (BRD), outlining the
build out the needs for each requirement.
opportunity and essential functions present to offer a viable solution to
the target market.
8. The product is tested by QA using the test plan.

2. Product management authors a Product Requirements Document

9. Operations prepare for the product launch and then deploy the
(PRD), spelling out precisely what functionality should be in the finished
finished product.
product, likely containing user cases and ranked priorities if there’s a
crunch for time or shortage of resources.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 6

A collaboration-friendly approach
REQUIREMENTS
Because everything is spelled out in advance, it’s easy to anticipate when
other teams will get involved in a waterfall process. Marketing prepares
for the launch by creating a launch marketing plan and then executing
PLAN
it. The sales team receives new or updated materials and training on the
product and its selling points. Customer service gets trained to support the
product when customers have issues or questions. And details like updating DESIGN
accounting systems, working out supply chain issues, engaging distribution
channels, and other essential tasks get handled by the appropriate teams.
DEVELOP

Even at a high level, there are still

a lot of steps and dependencies. TEST

This is where the project manager

RELEASE

comes in. Waterfall project management method

Even at a high level, there are still a lot of steps and dependencies. This is
where the project manager comes in.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 7

The project manager’s role in waterfall
Project managers create a schedule based on level of effort estimates and
business-driven deadlines, often in the form of a Gantt chart. They’ll also
make a project plan breaking tasks down to granular levels and assigning
them along with each one’s specific timeline. And, of course, they’ll keep
track of how everything’s going, holding meetings, adjusting schedules and
assignments as needed to try and deliver the project on time.
Waterfall was—and still is in some cases—a popular and loved way
to build products. However, numerous gates and checkpoints
may stall the process.
Transparency and visibility
Waterfall allows for crystal clear visibility into who’s doing what, when
it’s happening, and what comes next. A highly detailed schedule and
extensively documented plan imbue a sense of control and clarity.
Stakeholders and contributors know what to expect, the responsible parties
for each step, and a specific ETA early on in the project’s life.
Continual updates comparing the current status to the project plan give
stakeholders a sense of what’s on time, late, or early. Gantt charts and
similar tools provide visibility down to the individual task level to drive
resourcing decisions and spot potential schedule slips and delays. While it’s
not quite 100% certainty, it’s as close as you can get, which makes anxious
stakeholders uninterested in surprises sleep better and focus on other
things. These detailed project plans also highlight how much time and
person-hours are spent on each item, so priorities get reshuffled if the ROI
isn’t there.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 8
The challenges with waterfall project management
Big, carefully specific projects with inflexible schedules, complex
dependencies, and pervasive oversight sound like a great way to guarantee
success. But those same attributes make many push back against the
waterfall approach and prefer less linear and more flexible methods.
While a product-led strategy
incorporates new feedback...
waterfall essentially locks the
product development team into
plans that may last months or years
before a strategic review or reset.
Waterfall made sure you’ve dotted your I’s and crossed your T’s, but that’s
all keyed off of rigid requirements authored weeks, months, or even years
beforehand. Specific resources mapped out months or even years in
advance, informing headcount and staffing decisions for the leadership
team. It all sounds great when the market or technological landscape hasn’t
changed at all since the original plans.
Waterfall creates a detailed playbook that thinks through all the details but
leaves almost no room for adjustments without change requests, schedule
adjustments, and other accounting for downstream impacts. Because
the dynamic is structured to prevent deviation from the plans, many
organizations and concerned individuals won’t even try shaking things up.
Waterfall presumes the strategy’s assumptions are accurate, and the only
challenge is execution.
While a product-led strategy incorporates new feedback and sees which
directions users want to take the product and how to achieve those positive
outcomes, waterfall essentially locks the product development team into
plans that may last months or even years before a strategic review or reset. If
conditions change or new information comes to light, the team faces limited
opportunities to ensure the work will have the maximum impact and benefit.
The team has less room for course corrections and pivots, nor is there much
freedom for innovation and inventiveness on the individuals building the
actual product. The predetermined nature of waterfall stifles creativity and
creates barriers to incorporate new learnings into projects already underway.
So instead, it’s a top-down, follow-your-orders approach that ensures
everyone is on the same page—even if it’s the wrong one.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 9
Waterfall has maintained its hold on many product development activities THE WATERFALL PROCESS
for so long because it’s predictable and transparent. Things may slip, “This project has gotten so big, I’m not sure I’ ll be able to deliver it!”
problems may arise, and changes happen, but even those modifications are
tightly controlled and subject to approval. For the risk-averse stakeholder,
it’s tough to beat.

The project manager’s role in Agile

Waterfall does everything in order, which often leads to derailed and

delayed projects because of holdups or slowdowns in just one particular part
THE AGILE PROCESS
of the overall project. But, unfortunately, those same processes that make
waterfall so attractive are also its biggest weakness. “It’s so much better delivering this project in bite-sized sections.”

The Agile methodology and framework evolved in direct response to the

frustrations of product development experience in waterfall environments.
It requires a more nimble approach to project management, with
communication more critical than ever. Stakeholders need continual
alignment, and adjusting plans becomes a regular occurrence.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 10

A brief history of Agile AGILE VALUES

In 2000 and 2001, a group of software professionals assembled, with

the lofty ambition of creating something better. The Agile Manifesto Individuals and interactions
was developed with 4 values and 12 principles. The basic theme running over processes and tools
throughout these fundamental declarations boils down to a few main ideas:

• Things will change, so building out plans and sticking to them no matter
what is counterproductive. Working software over
comprehensive documentation
• Getting products into customers’ hands as quickly as possible is ideal
for delivering value sooner and learning directly from customers for the
future. Rapid iteration is superior to giant, spaced-out releases.
Customer collaboration over
• Developers and engineers know what they’re doing and don’t need to contract negotiation
be spoon-fed instructions. Just tell them the goal and let them figure it
out by themselves.

• Processes and tools are only helpful when they aid and assist versus Responding to change over
hinder and slow things down. Documentation and artifacts are following a plan
acceptable, but face-to-face interactions are superior.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 11

Agile principles

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

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 12

For Agile’s practitioners—ideally, dynamic problem-solvers driven by
customer delight and comfortable with a bit of ambiguity—it is freeing while
also creating enough structure that it’s not too chaotic. Its benefits seem so
obvious and plentiful that any other approach seems ludicrous, with those
clinging to the old ways simply because they fear change and losing control.
When done right, Agile inevitably
results in software getting shipped
faster and more frequently.
When done right, Agile inevitably results in software getting shipped
faster and more frequently than before. The condensed feedback loop,
frequent and plentiful iterations, and efficiently handled changes enable
the team to keep putting themselves in the customer’s shoes and optimizing
the experience.
It also distributes decision-making more widely across the organization.
Unlike in a waterfall setting, empowered small teams and even individual
developers can make judgment calls and implementation choices
independently, with less concern for how something gets done as long as it
happens and works.
But handing over the reins isn’t always that easy. It requires a level of
trust and delegation that may feel foreign or uncomfortable for some
stakeholders. The lack of visibility and documentation may also be unsettling
for those used to exactitudes and command-and-control management
styles. Plus, some may not ever warm up to placing that much power in the
hands of technical staff.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 13
Clearing up some commonly-held Agile falsehoods FALSE
Agile doesn’t scale.
Agile shares much in common with other major change management
TRUE
initiatives. Lots of socialization, education, and meetings can help, and it may
Agile scales just fine with proper high-level oversight.
take multiple go-rounds to build enough critical mass to win everyone over.

Agile is undoubtedly more manageable in smaller organizations with

One way to get some hesitant parties more onboard with Agile is to confront
less legacy, fewer stakeholders to manage, and a narrower focus, but its
its more suspect attributes and reputation head-on. CIOs, in particular, may
merits aren’t limited to startups and MVPs. Large enterprise organizations
need some extra convincing about why Agile’s benefits are worth it, as the
use Agile, including the likes of Microsoft, Procter & Gamble, and Apple.
fluidity and unpredictability of Agile doesn’t at face value mesh well with
However, being successful in larger companies and projects typically
senior leaders accustomed to lots of processes, documentation, and control.
requires a more standardized process and documentation to ensure
complete alignment and consistency.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 14

FALSE
Agile doesn’t care about quality.
TRUE
Software built using Agile is tested more frequently than in
waterfall settings.
The focus is on adding incremental value through more minor, more
frequent releases. In practice, this means doling out new features and
functionality in smaller pieces versus one giant finished product. Still, each
incremental addition or change must work before getting exposed to end-
users and typically goes through a round of QA before each release.
FALSE
Agile means you don’t need to spend time on planning.
TRUE
Sprint planning sessions happen regularly, and there are daily
check-ins to check status.
Less time and energy get spent planning in an Agile environment than
a waterfall one, and Agile doesn’t mean anything goes. The process
still needs agreed-upon long-range goals and objectives, prioritization
exercises, and planning sprints out in advance. The scope is more limited,
and the process can be more efficient, but planning is still a thing in Agile.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 15
FALSE
Agile is all or nothing.
TRUE
Organizations can use whichever aspects of Agile they’d like.
Individual teams, business units, or product groups can transition to
Agile without forcing the entire organization to do the same. How one
team works shouldn’t dramatically impact the approach others take.
However, there may be an increased need for communication and strategic
alignment, mainly when one team’s work depends on the other’s, and there
may be scheduling impacts.
FALSE
You don’t need product managers when you use Agile.
TRUE
You really need product managers when you use Agile.
Product managers play an essential role in an Agile organization. They
must help define and communicate the vision and strategy, orchestrate
prioritization, and represent businesses and customers’ needs. Without
product management, the Agile teams wouldn’t know what they’re trying
to accomplish, why it matters, or when it needs to get done.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 16
FALSE
Agile only works when Scrum teams are colocated and sit in
the same room.
TRUE
Agile works for distributed/remote teams.
While Agile does require more frequent communication with colleagues,
standups and other rituals can work just fine virtually, although the time
of day may vary with team members spread across multiple time zones. A
distributed team will, however, lean even more heavily on their tools and
asynchronous communication platforms.
FALSE
There’s no real strategy in Agile.
TRUE
Agile only works because there’s a solid strategy understood
by the whole team.
Because Agile organizations can much better pivot, course correct, or
otherwise react to changing circumstances, some mistakenly view Agile
as 100% reactive. Agile is more reliant on strategy than waterfall. When
a team uses waterfall, no one asks “why” once you get past the MRD/
PRD phases of the project; the strategic part is over, and now it’s just
execution. For Agile to work well, there must be a comprehensive strategy,
established goals, and—ideally—measurable objectives. It has a great
strategy that enables the Agile team to build, deploy, and iterate so quickly
because they understand the point of everything.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 17
FALSE
You don’t need project or program managers when you
use Agile.
TRUE
Project and program managers don’t need to manage as
many details.
Although Agile teams won’t need project plans with as much detail and
specificity, coordination and scheduling don’t go out the window. Unless
the organization is so small, it only has one Scrum team for everything;
there’s still essential for project and program management. Doling out
assignments, building out release plans, and coordinating with the rest
of the organization are responsibilities that don’t disappear when you
go Agile.
FALSE
There’s no documentation in Agile.
TRUE
There’s not as much documentation in Agile.
Note that “not as much” doesn’t mean “zero.” Development teams need
to document what they’re building so others can help maintain it. Testers
need scripts to run through when verifying that the software works as
intended. End-users need help with documents, tutorials, and FAQs, as
does customer support. These things aren’t optional, but lengthy, detailed
product specs create a lighter-weight, more dynamic process.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 18

Agile in practice
While the Agile Manifesto represents an ideal approach to
product development, executing things on a repeatable,
ongoing basis generally requires a little bit more
scaffolding and structure. Practitioners have several more
robust frameworks and processes available to them, such
as Scrum, eXtreme Programming, and Kanban, discussed
further below.
What is Scrum?
The word itself (“scrum”) comes from rugby, describing a sequence of play
where the entire team comes together and works interdependently on
securing possession of the ball. Coordination and joint effort are the only
options during a rugby scrum as teammates interlock their bodies and push
ahead toward their goals.
Product development using scrum doesn’t require close physical contact
or a shower afterward, but the metaphor holds up. Scrum enables quicker
software delivery by spreading out the responsibilities across the team and
letting contributors work independently.
This decentralized resourcing model varies from the typical, top-down,
approach seen in many project plans in a waterfall setting. By huddling in a
“scrum” daily, everyone still knows their place, working together precisely to
move things in the same direction and achieve a shared goal.
Scrum’s primary purpose is efficiency. Any wasted effort means that less
value gets delivered during each sprint, so if the team can get it right the first
time, they provide value faster, freeing up resources to take on the next thing
in the queue.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 19
And when looking back at any project that ran late or had disappointing
outcomes, poor communication is almost always one of the culprits.
However, if everyone has frequently been providing fully transparent
updates, the team can mitigate problems if not altogether avoid them.
Scrum Masters are the ringleaders in this framework, facilitating
communication ranks at the top of their to-do list. It begins by ensuring
the implementation team understands the sprint goals and overarching
strategy, which empowers them to build toward the desired objective and
not just follow instructions in a vacuum. However, like product managers, no
one reports to scrum masters, and they must gain authority through trust
and overall accountability.
The communication continues with daily check-ins, so everyone knows
how things are coming. There’s an open forum to share, ask for clarification,
or triage and troubleshoot when things go awry. The frequency of these
sessions keeps people from spending too long heading down the wrong
path or waiting around for answers. When speed and efficiency are the
goals, these brief, regular pauses in activity pay significant dividends.
Scrum Masters are the ringleaders
in this framework, facilitating
communication ranks at the top of
their to-do list.
Because sprints are relatively short, only so much work can happen during
each one. The goals for each sprint need to be manageable and doable in
short order, and there’s rapid confirmation that the desired functionality
and approach to delivering it are working. “Chunking up” larger projects into
smaller pieces for each sprint enables major initiatives to proceed without
cutting off the flow of additional value, making it to customers regularly.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 20
eXtreme Programming

eXtreme Programming (XP), another Agile framework, isn’t wildly different Practices intended to pump out software quickly like automated testing, pair
from Scrum, but it is an even more intense and dynamic version of the Agile programming, simple design specs, continuous integrations still work every
methodology in practice. XP takes the flexibility and rapid-release tenets of time. However, XP code is known to be a little rougher around the edges,
Scrum and slams on the accelerator. given the pace. To work well, XP usually requires smaller, colocated teams
that stay in near-constant communication to keep pace.
XP iterations are usually closer to a week in length versus the two-to-four-
week sprints seen in Scrum. Everything is worked on based on priority, with
no wiggle room to skip something at the top of the list for something easier
further down the line, which does occur within Scrum.

XP is also more flexible during an iteration. While sprints are “locked” once
they get underway, XP is more welcoming to changes or wholesale swaps
if requirements change or priorities shift. This customer-friendliness is one
of its key selling points, especially when customers aren’t exactly sure what
they want.

The process also differentiates Scrum from XP. Scrum has no set rules for
the actual engineering practices and procedures used during a sprint.
However, in XP, those elements are defined and adhered to because that’s
the only way the team can keep up with the rapid cadence and still deliver
meaningful value throughout every iteration. EXTREME PROGRAMMING

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 21

Kanban

Kanban evolved from Japanese manufacturers’ “just-in-time” method for Moreover, many organization and planning tools use the Kanban model—
managing inventory and is a highly visual approach to managing product such as Trello, Asana, and Monday—but Kanban boards often feature in
development. It centers on the Kanban board, which indicates where in the more specialized tools. For example, ProductPlan includes a Kanban board
process each item stands—done, still in progress, or waiting in the queue. option for organizing and presenting which stage various initiatives reside.

Each card on the board represents a single work item, such as a user story.
The card’s location on the board indicates where in the process it stands.
Cards progress through the different stages, providing excellent visibility
into where everything stands.

Managing this flow of cards is key to Kanban, including limiting how many
cards can be in each stage of the Kanban flow. By restricting how many
items are being actively worked on and waiting on standby, those items
get finished faster, and the team can narrow its focus, which improves the
throughput and efficiency of the whole operation.

Kanban is exceedingly transparent because everything is on that Kanban

board. Anyone can see where a particular item stands, and bottlenecks
can be spotted and addressed quickly. Kanban also helps the product
development team avoid any downtime since when an engineer finishes
one card, they can grab the next one at the top of the queue.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 22

Scaled Agile Framework

For larger enterprises implementing Agile, the Scaled Agile Framework
(SAFe) is one way to manage the complexity and scope of the operation
while still enjoying the benefits of Agile. Although some in the broader Agile
community disparage SAFe due to its top-down management culture and
upfront processes, it does remove some of the risks inherently associated
with implementing Agile in a larger setting.
SAFe adds layers of oversight and standardization to ensure these teams
can communicate and work together so that each piece of the puzzle fits
together. Much like railroad tracks produced simultaneously by multiple
teams must be the same width and meet up at the correct location, Agile
for enterprise requires an extra layer of coherence and oversight, which
SAFe offers.

Because a single Scrum team cannot always handle big projects, they need
to be subdivided and spread across multiple teams. Additionally, in larger
organizations, those teams may be located in different parts of the company
and report to various managers, requiring coordination and collaboration
across teams.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 23

Agile roles and responsibilities For example

PetTree is a software company that allows pet owners to create family trees
for their four-legged loved ones. Their goal is “making family connections
Figuring out who does what remains a fundamental requirement for any
for pets.” Pet owners input information about their pets, and then PetTree’s
working arrangement, and Agile is no different. And while Agile does
big data/AI engine creates a living family tree for their pets. The data can
prize autonomy, that doesn’t mean everyone runs on the field and claims
identify siblings, grandparents, cousins, and other connections based on
whichever position they feel like playing today.
the combined knowledge they’ve accumulated through registries and

Agile organizations are structured and staffed for optimal efficiency. The user-provided data. They generate revenue through a subscription model

objective is to do more, do it faster, and then do something else. That to create and maintain the pet family tree and by using their information to

requires clearly defined ownership and boundaries, so there’s less time provide highly targeted marketing for select brands.

spent sorting out conflicts and more opportunities to build and ship value
to customers.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 24

Organizational structure
An Agile organization’s org chart won’t look dramatically different. Likewise,
the overall management structure doesn’t change, nor will departments
such as sales or marketing. The primary differences will be on the product
development side of the house.
It’s here that some less familiar job titles may be found (such as scrum
masters and product owners). Another variation may be that the
development group has split up into scrum teams consisting of a handful
of developers and assigned or shared scrum masters and product owners.
Those smaller development teams will still roll up under a CTO or VP of
Engineering or similar role, with the primary differences occurring down at
the execution level.
Groups that interact closely with product development may align
themselves similarly, such as assigning someone from quality assurance
or user experience to work with one or more scrum teams on a semi-
permanent basis.
At PetTree, product development has three Agile teams:
Mapping Team
The Mapping Team handles the “big data” work of automated pet family
tree build-outs and augmenting the breed traits and histories database by
integrating multiple data feeds.
Community Team
The Community Team works on the parts of the product that help long-
lost pets connect with their relatives and builds breed-based communities
where users can share photos and discuss pet-related topics and events.
Commerce Team
The Commerce Team builds out revenue-generating features and
handles all user account and settings functionality. This team also
manages the website and mobile apps while supporting the marketing
team’s growth activities.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 25
 The various roles within an Agile ecosystem map against
these exact six words:

WHO
Which teams (and, later down the line, which individual members of those
teams) are doing the work.

WHAT
What to build to achieve the stated goal.

Who does what? WHERE

Admittedly a bit of a stretch, but very relevant for large organizations with

A good news story answers who, what, where, when, why, and how. multiple sites in different locations, especially when different geographies

But these “Five Ws and an H” extend beyond what you read in have varying areas of expertise and labor costs.

your news feed or watch on CNN. Product development must also

WHEN
answer these questions.
This relates to both major milestones and deadlines and more specific
schedules and resource allocation.

WHY
Defining the goals and objectives for the work to be done and the rationale
behind that.

HOW
This covers both the execution plan and the details of the particular
implementation.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 26

 The table below indicates which role is at the helm for each area, although
others may have some input beyond this breakdown of responsibilities.

Who What Where When Why How

PROGRAM MANAGER

PROJECT MANAGER

SCRUM MASTER

TECH LEAD

PRODUCT MANAGER

PRODUCT OWNER

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 27

PROGRAM MANAGER
Program management involves identifying and coordinating the
interdependencies among projects, products, and other critical strategic
initiatives across an organization. Program managers identify all of these
interdependencies across various departments, working with the relevant
stakeholders in each of these departments, and coordinating their efforts to
make sure everything that needs to get done to support the “program”—in
this case, the launch of a product—is on track.
PROJECT MANAGER
The project manager is responsible for breaking down strategic plans into
actionable, task-oriented initiatives. This process involves coordination,
delegation, and leadership, as the project manager must navigate
interdependencies, team dynamics, and one-off challenges, all while
meeting a deadline with limited resources.
SCRUM MASTER
A scrum master is a facilitator for an agile team working under the scrum
methodology. The scrum master serves as a point person responsible for
understanding the big development picture of each sprint. In addition, they
are responsible for delegating tasks appropriately and ensuring the team
is working on the right tasks at the right time. They also want to ensure the
team is fully deployed and not idle.
TECH LEAD
Tech leads are the player-coaches of the development team. While most still
get their hands dirty and write code, they also decide who should do what
within their team based on their competencies, available bandwidth, and
preferences. In addition, they estimate the level of effort and map out how
various technical components mesh and integrate to achieve the overall
goal of a project, release, or sprint.
PRODUCT MANAGER
The two primary responsibilities of product managers are to set the long-
term vision and strategy for the company’s products and then communicate
this strategy to all relevant participants and stakeholders. Product managers
must build consensus, break down (or at least work across) organizational
silos, and win over stakeholders to get their job done. Product managers
typically own the product roadmap and are intimately involved in
prioritization.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 28
PRODUCT OWNER
Primarily a bridge between the strategic and the tactical, this role varies Here’s what the Agile staffing looks like at PetTree:
depending on the organization. Product owners liaise between the product
The program manager oversees all three teams from a PMO perspective.
manager’s vision and the development team charged with executing that
They have two project managers, one for the commerce team and another
vision. Their role is to ensure that there is always a user advocate involved in
for the mapping and community teams.
development meetings. Accessible to the development team if they need
help or have questions, product owners attend daily Scrum meetings and The director of product oversees product management, but there is a
prioritize the backlog, ensuring the developers are working efficiently and technical product manager dedicated to the mapping team. Each team has
on the right items. a product owner that also reports to the director of product.

Each team has a dedicated scrum master and tech lead. The community
team has three other engineers, the commerce team has five other

An important caveat is that while the roles above can and often exist in an engineers and a user experience specialist. In comparison, the mapping

Agile organization, not every successful team has all of them. For example, team has eight other engineers and a dedicated architect. The team

smaller companies may not have a program management office or may members report to their respective tech leads.

do without a product owner, or sometimes the roles are combined. Not all
teams have the luxury of both a product owner and a product manager, so
one person may be tasked with strategic product management work while
also attending standups and working directly with developers.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 29

What’s the story with “self-organizing teams”?
To the uninitiated, this tenet of the Agile methodology may sound like a free-
for-all environment where everyone works with the people they like and on
whichever projects capture their fancy. There are some elements of truth in
that preconception, but it is slightly more nuanced.
Self-organizing teams are not rogue outfits doing whatever they please.
They take the initiative to select items to work on from the queue since
they’re empowered to do so and work collaboratively within the team
to maximize output without a higher-up handing down specific
marching orders.
The key to self-organizing teams is increased autonomy for all team
members. In its perfect state, a self-organizing team has a balance of
technical talent that, in aggregate, can handle any project that lands on its
plate. The project goals are known and understood by the entire team, and
they, as a team, break things down into smaller tasks and take them on as
they see fit.
That means no one is telling an individual team member what specific task
they should work on or how many they should accomplish in a given period.
Instead, the collective peer pressure to perform well and meet expectations
for each sprint serves as the motivation not to slack off and take on a smaller
workload than their colleagues.
This independence and sense of ownership imbue the team with creativity,
flexibility, and freedom while creating urgency and obligation. No one
wants to let the team down, and their aggregate effort keys individual
performance. That shared ownership and openness to collaboration
benefits the entire product development process, because the team invests
in meeting goals and overall success.
It’s important to remember that
teams must grow into their self-
organized self.
It’s important to remember that teams must grow into their self-organized
self. When team members or the entire organization are still new to scrum,
scrum masters still break down and assign tasks in coordination with the
tech lead. But over time, they can take on more and more self-management
and independence.
And, while self-organizing teams accomplish great things working amongst
themselves, that doesn’t mean it’s a total free-for-all. Agile does rely on
meetings, ceremonies, and a little bit of documentation to keep things on
track and aligned across teams.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 30

Events and artifacts
Although Agile prides itself on shipping software versus
process, some structure and documentation are required
to make it all happen. These are some of the crucial
elements of a functional Agile framework.
Events
Regular events and rituals are core to doing Agile work because clear,
honest, and frequent communication is the only way to quickly move
without making mistakes or missing crucial pieces of the puzzle.
Stakeholders and contributors all benefit from these opportunities for
sharing updates, asking and answering questions, and taking time to get
aligned on priorities, responsibilities, and timelines, enabling them to focus
on work when they’re heads-down designing and coding.
Sprints
Instead of time-boxing a development effort around the full completion
of a software release, Agile instead frames work effort in sprints. Typically
measured in weeks versus months, most teams settle on a cadence of one
sprint every two to four weeks.
The objective is to get new and improved functionality into customers’ hands
as quickly as possible, thus the short duration. This high-frequency pace
also enables the organization to measure and observe the performance of
previous releases and factor those learnings into upcoming sprints to iterate
on the product continually.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 31
Sprint planning sessions
These meetings determine what will be in the scope of a given sprint. Each
sprint gets a goal before setting the sprint backlog. The sprint backlog
contains the individual items the team agreed to work on during this sprint.
Sprint planning sessions allow the team to assess its capacity for the
upcoming sprint, determine the level of effort for each item, and then assign
tasks to team members (or allow them to claim them for themselves in a
self-organized setting). Each item in the sprint backlog gets an agreed-upon
definition done while addressing any open issues or questions.
The scrum master, product manager, product owner, and development
team usually attend these meetings. They tend to run for two or three
hours to cover everything and prepare the team for the upcoming weeks of
development activity.
Daily standups/scrums
Daily standup is a quick session where each team member shares what
they accomplished yesterday, what they’ll try to accomplish today, and what
is blocking work from progressing. Standups are a critical element of the
agile development framework, as they promote frequent and high-touch
team communication.
Sprint reviews
Sprint reviews are working sessions held after each sprint, covering the
previous sprint’s deliverables and updating the product backlog accordingly.
While these meetings may touch on how things went during the previous
sprint, it’s not intended to be a full post-mortem (that’s what the spring
retrospectives are for). Instead, the primary goal is to understand what’s
complete and begin queuing up items for the next sprint.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 32
Sprint retrospectives

The team holds sessions after a sprint gets completed and the release of the
latest version of the product. These meetings force the entire team to take
Sprint retrospectives allow the team to iterate how it works with
a moment and reflect on how the previous sprint went, determining what
external stakeholders to achieve sprint goals with an open and
worked well and what was problematic.
honest exchange. The meeting should be considered a safe
space for bringing up contentious issues and contrarian views to
Product managers often lead these retrospectives as they have the most
be as productive and insightful as possible.
cross-functional role, but an impartial third party can also moderate for
maximum transparency and fairness. The key to ongoing success is to let
people vent and identify and address problem areas for smoother sailing
in the future.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 33

Artifacts

Agile prioritizes shipping software over documentation, but that doesn’t

PRODUCT BACKLOG
mean there aren’t any artifacts for reference and tracking. These tools and
documents help the team stay aligned while moving at a rapid pace.
Task-level: user stories
and defects
Product backlog

A product backlog lists and prioritizes the task-level details required to

execute the strategic plan outlined in the roadmap. In addition, the backlog
should communicate what’s next on the development team’s to-do list as Primarily for product and

they execute on the roadmap’s big-picture vision. Typical items in a product development teams

backlog include user stories, bug fixes, and other tasks.

This giant to-do list is a living collection of potential development items and
Conveys tactical steps
requires regular maintenance, often referred to as backlog refinement. By
in execution of plan
periodically reviewing the backlog, the product owner can determine what’s
left in the queue and adjust prioritization based on new developments, such
as customer requests, competitor activity, or revised strategic goals.

Not everything in the product backlog will necessarily ever get built, 1 or 2 sprints
but it’s good to have a deep backlog full of every potential item under
consideration. Only those likely to be worked on soon require enough detail
that a developer can run with it independently.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 34

Sprint goals
Set jointly by the product owner and the development team before a sprint
begins, these goals lay out clear objectives for each sprint. They should
be narrow in focus, specific, measurable, and tie back to the larger product
goals and themes the organization has prioritized.
While sprint goals may seem redundant if the team has already defined a
sprint backlog, they serve two essential purposes. First, they often provide
the underlying context for why particular backlog items have been selected
for a given sprint and tie them together. The second is that if and when
things change during the sprint, the goals can continue to be the North Star
for that period..
User stories
A user story is a small, self-contained unit of development work designed
to accomplish a specific goal within a product. A user story is usually written
from the user’s perspective and follows the format: “As [a user persona], I
want [to perform this action] so that [I can accomplish this goal].”
The smallest unit of work within the Agile framework, each sprint usually
addresses multiple user stories. They allow meaningful progress in every
sprint and give the developers the proper context and motivation to solve a
specific problem or use case.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 35
Epics
An epic represents a series of user stories that share a broader strategic
objective. When several epics share a common goal, they are together
under a still-broader business objective, called a theme.
This “interim” container of user stories helps break the theme down into
more manageable chunks. The audience for epics isn’t so much the product
development team itself as the other stakeholders who don’t need to deal
with the level of detail of individual user stories.
Themes
Themes are the most significant “bucket” within Agile, aggregating
multiple user stories and epics to accomplish a broad-yet-defined business
goal. Themes rise above the day-to-day (and even the week-to-week)
iterations and improvements on the product and comprise major new
additions or modifications.
Product roadmaps in an Agile environment are also typically based around
themes. Epics and user stories are too granular for this level of planning and
shift the focus to specific dates and deliverables versus the high-level goals.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 36
Personas
Personas are profiles of a product’s typical customers. They help the product
management team understand different users’ traits, behaviors, goals,
responsibilities, and needs.
They serve multiple practical purposes for product organizations. First,
personas provide specificity and a connection with the end-user versus
a poorly defined, generic “customer.” Because there are often multiple
personas to contend with during the customer journey—since often those
making the purchase decisions about a product aren’t the folks using it—and
because there are sometimes totally different kinds of users.
For example, in a two-sided marketplace, you have buyers and sellers who
each have different goals and tasks they want to complete. With personas in
place, user stories can indicate which persona goes to each use case.
The supporting information arms the Agile teams with enough data and
understanding of the objectives to work relatively independently on
value-adding tasks. But to know which epics, user stories, and themes
come first, Agile teams also rely on roadmaps and project plans to structure
their execution.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 37
Roadmaps and project plans in
an Agile world
Roadmaps and project plans lay out the future, explaining what’s going to
happen, who’s going to do it, and when. Agile is worried about the next few
weeks. Yet, they all can—and should—coexist.

The key is understanding everything’s purpose and “why” concerning the

other artifacts and processes the company uses. Then, when structured
appropriately and clearly explained to stakeholders, they should all
compliment each other nicely.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 38

Roadmaps
Product roadmaps are a visual encapsulation of strategic priorities.
Roadmaps tell a story about the product goals and the steps to
achieve them.
To be valuable and accurate, roadmaps in an Agile setting must stay high
level, which is why the best roadmaps use themes as their foundation. These
describe the key initiatives the company has prioritized based on aligning
with the product’s strategic goals.
The roadmap itself isn’t dictating the contents of a given sprint, nor should
it include anything as detailed as an individual user story (unless someone
drills down into the details). Instead, agile roadmaps are directional and
inspirational, connecting the dots between all the minor tactical and
incremental improvements and additions the team makes every couple
of weeks.
They are the big picture, the broad vision, and remain light on the details.
Using a theme-based, visual roadmap also influences what the audience
remembers and processes since humans remember visuals far better than
what we hear.
Roadmaps are also essential for securing stakeholder alignment, letting the
higher-ups approve the product direction, and giving sales, marketing,
and other teams enough of a preview of what’s to come so they can plan
accordingly. Roadmaps that include a message for each target audience
help them feel like participants in the process, and their concerns are valued.
Even if they don’t get every item on their wish list, acknowledging what’s in
and out and why goes a long way.
For product managers, roadmaps play an essential role in
an Agile setting. Since there’s less day-to-day oversight and
precise specifications for individual elements of the product, the
roadmap serves as the primary tool for conveying the purpose
and context for each item product development builds. Ignoring
this opportunity to shape the overarching mindset with a
roadmap emphasizing the goals and desired outcomes can lead
to confusion and missed opportunities.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 39
Project plans
Agile project plans will look a little different than their waterfall peers.
Traditionally, project plans map out every step to deliver each item.
Resource assignment, level-of-effort estimates, and deadlines for key
milestones inform the process. Project managers then weave everything
together so that at the end of that months-long slog, the finished product
includes all the bells and whistles promised upfront.
As the team completes the sprints,
the project plan gets fleshed out for
the next ones.
That level of specificity and detail clearly won’t work in an Agile setting,
but it doesn’t mean project plans shouldn’t get scrapped. While a plan for
the entire project may be far too challenging to construct in detail at the
outset, it can still encapsulate a longer horizon than the next sprint. The main
difference between waterfall and Agile in this context is that project plans
become more and more vague the further into the future they go.
This ambiguity flies in the face of a primary goal of most project plans, which
is to choreograph everything down to the tiniest detail, so it all merges in
harmony with a fully-formed deliverable. Instead, the first sprint or two
might have a ton of detail while things get blurrier and blurrier farther ahead.
As the team completes the sprints, the project plan gets fleshed out for the
next ones.
The other significant difference is that while usually a project plan gets
relatively locked down with variations requiring change requests and the
like, that’s not the case in Agile. The project plan will change based on how
sprints unfold, the strategy evolves, and what the product team learns from
prior releases and experiments.
With a product roadmap setting the agenda while offering a shared vision
for the product’s direction along with a project plan that explains how
the team will get there, Agile teams have the background and context to
connect the dots between their projects and actions and the overall purpose
of their work. With stakeholder alignment around these two essential tools,
Agile practices can quickly turn that strategic vision into a reality.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 40
Agile and strategic planning
The final fallacy that often stymies Agile implementation at some
organizations is the belief that strategic planning and Agile can’t coexist
and that one will always drive product development’s direction. Naysayers
believe that the developer autonomy and rapid iterations based on learnings
shift the emphasis toward knee-jerk reactions and quick wins instead of
longer-term, larger objectives, which couldn’t be further than the truth.
Product-led growth and prioritizing work based on maximum impact doesn’t
derail product strategy, it supercharges it. Agile needs strategic alignment,
so people build the right things, and so the strategy benefits from rapid
execution and accelerated learnings and feedback, which streamline the
opportunities for optimization.
Agile practitioners desperately want thoughtful, comprehensive strategies
in place. They recognize that a solid strategy is essential to creating products
that customers want. The caveat is that engineers want a strategy versus a
prescribed specific implementation, where conflict can sometimes arise.
Strategic plans need to stay strategic. Things get messy when that strategy
also tries to dictate the details of the implementation, be it specific delivery
dates, UX choices, or technological tactics.
Agile works best when the business tells the product
development team what’s important and what the goals for the
project are. They then need to get out of the way and let the
team build how they see fit.
It’s not always easy to take that step back. It takes trust and confidence
that the requirements have been communicated and understood and that
the team is diligent and capable of turning that into working software that
does the jobs it’s supposed to do. It can be scary, take a while, and there are
almost always some growing pains.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 41
Maintaining alignment with communication
Ongoing, open, honest communication makes Agile work. In its absence,
opportunities arise for disconnects, false assumptions, and wasted work that
detracts from the product strategy’s ongoing pursuit.
They keep up the pace and maintain the autonomy that Agile demands
without excellent rapport and frequent interactions. It’s not so much about
the volume of information exchanged—Agile prizes succinctness above
almost all else—but rather the frequency and transparency of it all.
Silos and secrets don’t mesh with the recurrent and open conversations
that Agile organizations require. Unlike in waterfall, everyone needs to fully
comprehend the “why” behind every item in the queue to then apply their
judgment as to whether they’re meeting the desired need. Vagaries lead
to wasted work, and there’s nothing less appealing to Agile practitioners
than that.
To make it all work, Agile calls for both verbal and electronic interactions
from everyone involved. Some will happen during in-person or virtual
meetings—such as daily standups—but just as crucial is how the team uses
asynchronous communication tools such as Slack and Microsoft Teams and
tools in the product stack such as Jira and ProductPlan.
People will have questions, and they need those questions answered quickly
to keep up the pace. In that same vein, since formal documentation often
takes a backseat in Agile, the conversations on asynchronous chat platforms
and the comments left in tools are essential tidbits of information that must
be shared and referenced to make it all work.
Teams should set expectations and standards for communicating critical
information. Assuming others are in the know when things are moving so
quickly is dangerous, and consistent use of tools and stakeholders that must
stay informed lets people do things on autopilot instead of having to pick and
choose who to tell what every time.
Most importantly, the extended team must all embrace open communication
and not take questions personally. Peoples’ need for information must trump
anyone’s feelings or desire to keep things to themselves.
STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 42
Reality is a continuum and your mileage may vary

Agile doesn’t look the same everywhere, despite all the books, gurus, blog
posts, and consultants offering guidance and prescriptions for success. Agile
is in many ways an ongoing aspiration, and there are always opportunities to
work toward the ideal. But being 100% Agile won’t necessarily generate more
revenue or reduce the number of bugs compared to another company that is
more selective in which aspects of Agile they choose to adopt.

Like any new tool, technique, or process, it should always be adapted to fit
the current situation and the desired goal, with tweaks and changes along the
way. Sometimes the boss wants what they want, or a key customer makes an
ultimatum, which trumps prioritization and scheduling.

While this might irritate Agile absolutists to no end, companies are in

business to ship products, not to embody an ideal. But with a flexible
mindset, Agile can be a powerful, transformative method for getting the most
out of the available resources and expediting a product’s path to success.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 43

What we’ve learned

As we conclude, there are a few critical takeaways from this book as readers
go off and implement, adjust, or avoid Agile in their workplace:

AGILE AND STRATEGY CAN COEXIST DO WHAT WORKS FOR YOU

Agile without a solid strategy is a recipe for chaos and confusion. Product No Agile Inspectors are policing how any organization decides to implement
development teams desperately want to understand the context, goals, or borrow from Agile (although you can certainly pay a consultant to do that).
desirable outcomes, and measurable objectives the business has set for At the end of the day, every methodology, framework, and philosophy is only
the product. helpful if it helps the business get where it wants to go.

AGILE NEEDS STRATEGIC ALIGNMENT COMMUNICATION CREATES TRUST

If stakeholders aren’t on the same page about what they want and can Transparency and honesty combined with a track record of successful
expect from the product, all those rapid iterations will produce work that delivery increase everyone’s comfort level. From building consensus around
doesn’t meet important goals and may frustrate misinformed stakeholders. prioritization, roadmaps, and project plans to tell it straight during daily
standups, the more people know, the fewer questions and doubts they’ll have.
TRUST BEGETS BUY-IN FOR AGILE
Stakeholders’ comfort level with Agile’s lighter documentation and
increased autonomy grows when there’s confidence the team is building the
right things for the right reasons.

STRATEGIC PROJECT ALIGNMENT IN AN AGILE WORLD 44

About ProductPlan
ProductPlan makes it easy for teams of all sizes to build beautiful
roadmaps. Thousands of product managers worldwide–including teams
from Nike, Microsoft, and Spotify–trust ProductPlan to help them visualize
and share their strategies across their entire organization. With our
intuitive features, product managers spend less time building roadmaps
and more time shipping products.

Start Your Free Trial