PROJECT TO PRODUCT

Building the Right Thing in the Right Way

By: Anne Steiner

www.cprime.com | learn@cprime.com | 877.753.2760 | © Cprime Inc. All rights reserved.

CONTENTS

03 INTRODUCTION

04 KNOWING THE DIFFERENCE - PROJECT VS. PRODUCT

07 HOW TO FUEL PROFITABLE GROWTH

09 MAKING THE TRANSITION - FIGURING OUT THE

WHAT TO DO VS. THE HOW TO DO

15 WHAT’S IN IT FOR YOU?

Back in the days before agile really took hold in the software development world,
workflow processes were dominated by project management. The process consisted
of loads of research, developing a master plan, assigning projects to developers,
and then, finally, perhaps two years after the initial idea appeared, there would be a
finished product sitting there ready to launch.

Of course, by then the market had often changed, as had the customer’s wants and
needs. Depending on how dramatic the change was, the product may have been
launched to lackluster reception, pulled back in for some massive overhauls, or even
scrapped completely.

That’s why Agile software development was created in the first place: the system was
broken and it needed to be fixed. And, to a large extent, agile development practices
have successfully improved that system.

Even so, the old project management principles that once ruled the industry are still
very much in place in countless organizations. For the most part, they’re well hidden
right beneath the surface of Scrum-colored skin and flashy Kanban makeup. But,
they’re still there. And, as a result, development organizations are still facing some of
the same challenges that the old broken system was known for.

The light at the end of the tunnel is that there’s a post-Agile awakening happening.
These organizations are finding the solution to this pervasive problem, and the
solution is Product Agility.
 KNOWING THE DIFFERENCE - PROJECT VS. PRODUCT
To understand what product agility actually is, we need to take a step back
and consider the meanings of the words project and product in this context:

What is a Project?
According to the Project Management Institute, “a project is a temporary
endeavor undertaken to create a unique product, service, or result.” In a
software development context, although every project is different, they
do tend to share some common attributes:

• The project has a set start time and end time, and a detailed plan with
milestones to be reached.

• Effective management and execution of the project is measured by

how closely the plan is followed. More specifically this means the
adherence to time, budget, and scope.

• The work is assigned to ad hoc teams and sometimes even individuals

based on what’s needed to reach the next milestone.

• The project is finished when the product, service, or result is created.

Any changes based on customer feedback, enhancements, or future
maintenance would constitute a different project.

• A project is considered successful if it was completed on time,

within scope, and under budget while product impact and customer
satisfaction are often overlooked

No doubt, you can see that traditional project management flies directly
in the face of nearly everything the Agile Manifesto declared. You might
think it would be impossible for anything like a project to make its way
into a supposedly agile development organization. But, as we’ll see in the
next section, that’s not true at all.

4
 What is a Product?
A product is anything you build or any service you provide that impacts
people. As we’ll discuss below, this is a pretty significant shift in thinking
about work. However, organizations that have achieved that shift are noticing
these qualities:

• A product has no inherent start and stop points, so it expands to include

all necessary changes or maintenance along the way.

• Instead of a discrete start and stop, products are similar to living

breathing things, like a hypothetical “time horizon” stretching from initial
concept to final “sunsetting.”

• Ideally, the same core group of experts work together throughout the
product’s entire lifespan, allowing for deep expertise and a tight-knit
working environment.

• Success is measured based on the frequent delivery of value to the

customer across the product’s lifespan. In short success is measured
based on the impact the product has in its market.

Clearly, thinking of your development work in terms of products (rather than

projects) falls far more in line with agile principles. Interestingly though, it’s
actually at odds with some common agile practices, including some that have
become so ubiquitous they’re almost considered synonymous with agile.

You may be thinking, “But wait, Scrum gave us the product backlog – a single,
prioritized list of stuff we can do!” Yes, but it also gave us the product owner
– the all-knowing “voice of the customer,” who gets to write epics and stories
and order them. Indeed, the output of a sprint is even a “product increment.”
There is, in fact, a product piece somewhere in there.

Wait again. SAFe® is even more sophisticated. Now, we have stories, features,
capabilities, and epics. We get to break down and plan work into both Program
Increments (PI) and Sprints. There’s even more product in there, right?

And what about Lean Startup? Isn’t it the ultimate in product thinking as we
seek to identify and to release an MVP as soon as possible for the purposes of
validation and learning?

The answer is yes. However, these methodologies all tell us what to do, but
not so much how to do it.

5
 When we break down the two, we can find clear distinctions that help
map out project versus product. Jeff Gothelf and Joshua Seiden give
three ways to shape your mindset around these concepts in an article
from the Sense & Respond Blog1 that was featured by the Project

“
Management Institute.

Projects end. Products are continuous.

Projects are linear. Products are circular.

”
Projects are components. Products are systems.

In these comparisons, we see a common analogy: projects are one

time events whereas products are ever-evolving cycles that don’t have
a defined end. Projects can be checked off as done while products are
continuously learning and adapting to the environment. Product thinking
allows teams the ability to adjust to unpredictable consumer needs and
market demands as each variable occurs.

One scenario to think of is that of a puzzle constantly taking new shape.

Projects represent a puzzle piece. A singular puzzle piece will not hold
much value to a puzzle that is continuously taking various forms. It will
work for maybe one version of the puzzle but not the next. That’s where
product comes in. Product IS the puzzle. Ever changing, ever evolving,
gaining new pieces and solutions as it develops.

1 Gothelf, J., Seiden, J. (2019, October 8). Moving from Project to Product: What Does “Product Think-
ing” Actually Mean?. Project Management Institute. https://www.projectmanagement.com/blog-
6 post/57053/Moving-from-Project-to-Product--What-Does--Product-Thinking--Actually-Mean-
 Product Agility
With the two mindset explained, the meaning of the term “Product Agility”
becomes clear:

Product Agility is not a specific process as much as it is a new way of looking

at work. Its focus is on delivering value to the customer, often through fast,
iterative cycles of discovery and delivery. And, as a result, it’s finally addressing
one of the biggest issues traditional project management never could:

It ensures we’re actually building the right thing, rather than allowing us to build
the wrong thing well.

HOW TO FUEL PROFITABLE GROWTH

There tends to be a common view when discussing Agility, and it’s the
idea that Agility saves money. This stems from companies viewing IT as a
cost center, and believing that if IT becomes more efficient through Agile
practices, then it will cost less. The problem with this mindset is that this can
result in cutting team members for cost savings, translating to short term
profit but long term decrease in revenue growth.

It is important to reframe that way of thinking and to consider “IT spend” as

an investment needed to acquire revenue. Rather than solely viewing Agility
as a way to be more efficient and cost effective, we should also view agility
as a way to steer towards profitable revenue growth. The idea of “steering”
represents the flexibility to adapt to the ever-changing market.

This concept will require taking a product-based approach by building

products and services that delight customers. Rather than viewing IT as
expendable, IT should be the investment. It’s really easy to know how much
people cost, but it’s hard to know how much features will cost. When you
focus on budgeting for people and not features, you allow your team to have
the flexibility to adjust to new demands and ideas without missing a beat.

7
 Moving from Project-Based Funding
With project-based funding, the scope, time, and budget are estimated up
front. After this estimate is created, the next step is to argue for a large sum
of money to support this initiative, based on the estimate. The team receives
this large chunk of money to span however long the project should take until
it is “done.” By the time you reach “done” you are left with a gamble when
considering the variables that could affect delivery.

WHAT IF:
• The market shifts
• Customers’ needs shift
• We guessed wrong
• Users don’t want it
• It doesn’t get built the way we asked
• We go over budget
• We don’t deliver on time… and now we’ve wasted
money, considering this was an all or nothing bet,
thus prompting us to keep spending even more.

Adapting Product-Based Funding

Considering the risks that come with project-based funding listed above, a
new formula was adopted. Product-based funding requires you to allocate an
investment to a product line where you can map investment money to staffing
instead of to unpredictable features. Product teams can progress against
the product roadmap in priority order while blending product discovery with
product delivery in order to fuel continuous product learning.

THE RESULT:
• Build less, validate more
• Effectively adjust to market and customer needs
• Make measured investments
• Business has control and can steer

8
 With the business horizon listed on the previous page, we allocate
investments in smaller increments. The team seeks to deliver a smaller piece
of value to the market and then tests its viability. From that we learn and
adjust. With this practice, companies can learn and adjust their course with
a fraction of the money spent than it took previously. This is why this funding
model leads to enhanced ROI for the organization and better products for the
customer. With this strategy, companies will go beyond making “IT efficient;”
considering you can’t “efficiency” your way to business growth. Instead,
you make your business, which includes IT, maneuverable. Agile gives you
the ability to steer while the product mindset/investment model tells you
which way to steer. When blended effectively, this adds up to sustained,
profitable growth.

MAKING THE TRANSITION - FIGURING OUT THE WHAT TO DO

VS. THE HOW TO DO
If you think about the first decade of the 2000s, the agile movement gave us
tremendous advancements in terms of process maturity. We learned to work
and to deliver in iterations. Then, as we advanced from there, we focused on
progress. How can we turn the crank faster? We became more efficient and
optimized our agile processes to get the most from the machine.

Now that we can consider delivery to be understood, constant, and largely

predictable, it’s time to turn our attention to answering the question, “Are we
building the right thing?” To do that, we need to get past the hand waving and
into the “how.”

There is a better way to understand and tell the product story. There is a
better way to create roadmaps, backlogs, and stories. We won’t necessarily
find that way in the pages of our methodology’s documentation, but we can
certainly fit it into whatever methodology our company has chosen. In the end
our process will be stronger, and more importantly, our product will be too. It
all begins with early discovery.

9
 Project Planning vs. Product Horizons
Project Plans are about the work!

Shifting from thinking about the work to thinking about the impact.

From Project-Based Roadmaps:

WORK
From Outcome-Driven Roadmaps:

10
IMPACT
 Discovery
As opposed to a traditional project planning and strategy period, which could
last weeks or months, the official start of an agile product initiative is a brief
discovery period that usually lasts just one or two days.

During that period, the following four questions are considered:

1. What are we building?

2. Why are we building it?
3. Who are we building it for?
4. How are we building it?

Make sure to answer those questions as a full product team so that everyone
has a common understanding.

Discovery may begin with one or more seeds of ideas that have been collected
over time, or it may start with a fresh brainstorming session. The key test of
which concepts are pursued lies not in who came up with the idea or how long
it’s been floating around, but in how effectively those four questions can be
answered when considering each idea. The concepts that generate productive
answers across the board are worth moving ahead with, while others should
probably be scrapped or, at least, deferred to a later discovery session when
new information may be available.

The end result of early product discovery is a list of prioritized experiments that are
worth investing some time and resources into. That list is our product backlog.

How do you bring ideas to life?

11
 Looking at the Team as a Whole
That initial product backlog may only include a few dozen stories to start
with, but it’s enough to engage a new product team and give them some
productive work to dig into. This product team will include members focused
solely on delivery — such as front-end developers, back-end developers,
and testers — as well as members dedicated to ongoing discovery — such as
product managers, product owners, and analysts.

Most importantly, there will be at least a few team members who are involved
in both aspects of the product development process. Some examples may
include a tech lead, lead QA engineer, or designers. While they’re in the
trenches writing and testing code, they’re also in a prime position to share
information back and forth with the discovery folks to inform the work.

It is important to keep in mind that discovery and delivery are two different
activities, two different cadences, but they’re done by the same product
team. If we get into the mindset of separate discovery and delivery teams,
we’re also separating that handoff between product and engineering or
business and IT. Think one team, formed together and bonded around a product.

Team members may come from different areas with different skills. But
everyone on the team should feel a sense of ownership for the product.
Ultimately, their goal is to solve problems for the customer as a team.

So, as we talk about discovery and delivery, we’re approaching it as two

different activities or two different cadences, within a single product team or
a product line.

12
 As this blended team starts working on the initial product backlog, trying
out the experiments, a feedback loop is immediately established between
delivery and discovery. One team, two cadences.

The delivery side is constantly considering these questions:

• How will we build this?
• How much can we build?
• Are we building it the right way?

The discovery side is constantly considering these questions:

• What problems do customers have?
• What value can we create for them?
• In what order should we create that value?
• Did we build the right thing?

Looking at the Team as a Whole

Now that we’ve laid the initial building blocks for developing our product
backlog, we can start to look ahead and dive into visualization of the product
story and identifying journeys (backlog items larger than a story - you may call
them epics or features), throughout the product story.

Let’s take a look at the whole process:

The discovery group starts by grabbing that next journey off the backlog and
authoring it, meaning to add a description that answers the questions “who,”
“what,” and “why.” Then we add acceptance tests at the journey level. These
are cross cutting tests that describe the behavior we expect the journey to
deliver. They are written in test language so that they can be verified.
13
 With a general understanding of what this journey is and what we hope
to accomplish we can take on some of the cross-cutting concerns as a
discovery team. For example, do we need to create some sketches of the user
experience? Do we need to understand some architectural pieces? Do we
have larger constraints to deal with?

Finally, we go back to our story maps and determine what stories we want
within this journey. It’s likely that we’re just working with titles at this point,
as we need to author all the story’s details.

The rest is a repeat of the above for each story in the journey. Once we have
authored descriptions, defined acceptance tests, and reviewed these stories
with the larger team to assign sizes, they are ready to be worked on within a sprint.

This process is continuous from story to story within a journey, and from
journey to journey within the product backlog. New stories and journeys will
be created, and when product learning happens, you can adjust the product
backlog without having wasted all of your hard work. The product now wholly
encompasses the new features, the technology, the maintenance and the
legacy aspects. That’s all your product.

14
 WHAT’S IN IT FOR YOU?
We want to produce what people need. But we also want to do it in a way
that’s sustainable and doesn’t burn out team members. The move to product
thinking achieves a team or program of people with a shared product vision.
They all have the same information and are going to have the same love for
the product, the customers, and the market. Bonus: they’re going to care a
lot more because they get to be a part of the decisions.

Project thinking means handing things off and building products like a
relay race. With each pass of the baton, a piece of the product story is lost.
The shift to Product thinking enables us to adapt to change, adjust as we
learn, and respond to the market. What does that mean? Better return on
an investment. not because we’re turning the crank faster -- because we’re
building less of the wrong thing and more of the right thing.

15
 ABOUT THE AUTHOR
Anne Steiner is the Vice President of Product
and Technology at Cprime. In her role, she
leads Cprime’s consulting practice that guides
clients in defining, designing, building, and
supporting digital products. Anne and her team
help companies of all shapes and sizes transform
from traditional, project-thinking to being
product-driven organizations that emphasize
technical agility and continuous learning.

Anne has more than 20 years’ experience in tech, working as a developer,

product manager, coach, and executive. She excels at helping people in product
and delivery roles act as a single team, working together for the benefit of the
customer.

Anne also actively promotes building communities of practitioners in the

Minneapolis/St. Paul area and frequently speaks at national and regional events.

ADDITIONAL FREE RESOURCES

WEBINARS WHITEPAPERS
Enroll in a 60-minute web seminar Resources written by our experts
that discusses key management about topics ranging from leadership to
practices, research, and current trends. Agile to DevOps.

BLOGS CASE STUDIES

Featuring real world stories from Read up on transformations and key
our subject matter experts and results from companies across the globe
original research. who have utilized Cprime.

TUTORIALS TEMPLATES
We have a wide variety of tutorials and Improve your processes by using one
how to’s for you to advance your skillset. of our pre-existing templates.

For your free resources, visit cprime.com/resources

16
 CPRIME PRODUCT AGILITY SOLUTIONS

Are You Building the

Right Thing in the
Right Way?
Cprime Product Agility solutions help product
teams get from planning to launch faster.
Learn how you can gain more responsiveness
to market and obtain higher rates of return
from your product investments. Cprime
Product Agility teaching and coaching enables
you to blend product and design thinking with
technical agility and modern engineering
practices to achieve continuous product
learning. Learn More

Chart Your Product's Course

Determine the most strategic things to build, and in which order, by creating a product
horizon that delivers the most measurable value

Bring Ideas to Action Faster

Apply design thinking and Lean UX practices to get from idea to stories without losing the
big picture intent. Create backlogs while at the same time gaining alignment, prioritization,
and clarity to your product strategy.

Build the Right Thing the Right Way

Apply modern engineering practices that allow for better technical health and agility. This
gives your codebase and environments the ability to shift and maneuver as you learn.

Weave Product Learning into Your DNA

Whether it is at the test, story, or feature level, apply practices that promote continuous
validation of value delivered. Measure success in terms of impact versus output.

17
 ABOUT CPRIME
An Alten Company, Cprime is a global consulting firm helping transforming businesses get in
sync. Cprime is the partner of choice for Fortune 100 companies looking to achieve value and
agility. We help visionary business leaders compose solutions, execute implementations, and
exceed against business goals. With our key partnership recognitions, including Atlassian
Platinum, AWS Advanced, and SAFe Gold SPCT partner, our industry-leading software and
services work in synergy to deliver transformations.

Visit us at www.cprime.com or call 877.800.5221

ENTERPRISE TECHNOLOGY PARTNERS

ATLASSIAN MARKETPLACE PARTNERS

METHODOLOGY PARTNERS

TECHNOLOGY PARTNERS

18