Product Thinking vs.

Project Thinking
Kyle Evans Following
Oct 22, 2018 · 8 min read

One of the biggest challenges a product manager will face (or an

organization for that matter) is trying to elevate thinking and culture
from a project level to a product level.

Project Thinking

Project thinking is fairly pervasive. Many folks, especially in software

development, have spent a lot of their careers focused on projects and
project management. Large organizations often have PMO
departments, focused exclusively on project management. It’s not
surprising, because project management has been around a very long
time. And we as humans tend to think in terms of projects: things we
need to get done.

So what is project thinking?

The focus of project thinking is delivery. This could be the delivery of

specific features or software, or really the delivery of anything. From
aircraft to houses. And because the focus is delivery, the primary
measurement is on the timeline and schedule. Project management is
specifically focused on the output, and is measured by how accurately
we were able to estimate the timeline beforehand and then deliver the
specified output on that schedule. Success is largely defined as taking
the specs of something beforehand, setting up a schedule with
milestones all along the way, and then hitting those dates.
Product Thinking

Product thinking takes a fundamentally different approach. Rather

than focusing on the output, product thinking is focused on the
outcome.

This is a significant shift from the mindset of project thinking. Rather

than focusing on timelines and dates, we focus on the goal we want to
achieve or the job to be done. Because we’re focused on the outcome
rather than the output, it is much more difficult to put time constraints
around the delivery, at least up front. Primarily because we don’t
necessarily know how we’re going to accomplish the goal up front.

This kind of thinking can be quite the shift, especially for folks who
have spent a lot of time focused on projects and project management.
Many people are uncomfortable with the uncertainty of not having
structured timelines and schedules that they can monitor on a regular
basis.

The Benefits

So what are the benefits of letting go of project timelines in favor of

focusing on outcomes?

First of all, it is ultimately the outcome that we are driving toward,

regardless of how we try and get there. The main benefit of a product
mindset is that we ensure that we get to the outcome more efficiently.

With a project mindset, we assume at the beginning that we already

know how to achieve the desired outcome. Working from that
assumption, we create a project plan and timeline full of the
requirements and milestones, and then begin execution on that plan. If
we’re right, and what we assumed initially turns out to be the right
solution, then we’re in great shape. We just execute the plan and
achieve the outcome.

But what if we were wrong initially? What if the solution we identified

isn’t going to achieve the outcome we had hoped?

That is where project thinking gets us into all sorts of trouble. Once we
set a plan in motion, it can be very difficult, especially in larger
organizations, to pivot and change. Once dates have been put in place
and everyone has agreed on a plan, that is usually what sticks in
everyone’s minds, despite our best efforts to learn and adapt. And if we
end up missing a date, it can cause incredible issues for teams and
businesses.

But with a product mindset, we are able to learn and adapt as we go. We
aren’t set on dates and milestones, but rather are focused on learning
and achieving the outcome. If something doesn’t work out or customers
don’t respond well to one thing, we can take that into account, adapt,
and still work toward the outcome we had intended without blowing
up a beautiful plan that is everyone’s focus.

Crucially, when problems arise (and don’t kid yourself, they always will
arise), product thinking allows us to learn and adapt, and stay focused
on the outcome we’re trying to achieve. In contrast, when problems
arise and we’re stuck in project thinking with its focus on the timeline,
we will often get sucked into endless meetings trying to determine why
our initial guesses were wrong and how do we get back on schedule.
This ultimately leads to sacrifices in quality, work-life balance, and the
outcome since we need to stay focused on delivering the output we
initially agreed on (regardless if that is still the right thing to do).

A Project Example

We’ve been talking about a lot of concepts, so let’s take a look at some
examples to better illustrate these points.

A great example of a project is the construction of a house. My wife and

I built our house last year. We went through the whole process of
selecting the floor plan, choosing all the finishes and details in the
house, and then paying large amounts of money to get it going.

When we started, our construction manager (who was absolutely

excellent), gave us the estimated finish date. It was about 6 months in
the future. Obviously there are many things that go into these
estimates, and things often come up that throw the dates off, but since
the construction of a house is a very repeatable process with defined
inputs, a good construction manager can look at the plan week by week
and determine when they expect to complete the work.

Our house was off by about a week, which feels like a bulls-eye in my
opinion. One of the trades was delayed in getting their work done, so
that set things back a few days, which had some ripple effects. But that
is fine. It’s expected.

When it comes to these types of construction projects, they are very

much geared toward project management. Everyone knows what needs
to be done and keeping people on schedule is a real key, especially since
it wasn’t just our house being worked on, but the whole development.

A Product Example

But does this kind of project management work everywhere?

No, it doesn’t.

As much as we’d like to think of software development as construction,

it isn’t. The clearly defined plans and work don’t translate to product
development no matter how hard we try. While there is great comfort
in well-defined timelines, that’s not how we should do product
development.

In a product I’ve been working on, there is a key problem I identified

and knew we needed to solve in order to continue to broaden our
audience and reach additional users. The traditional approach to this
would be gather the requirements, scope out the work, and then build
the features. But much to the consternation of many folks at my
organization, I don’t take that type of typical approach.

Once I understood the problem, I dove into researching solutions, from

building the features to integrating third-party software. As I did this, it
became apparent to me that the solution was, in fact, not to build
anything. Rather than build new features or integrate someone else’s
software (in this case, it was a portfolio for students), the solution was
to change what we were asking students to do. Rather than focus on
the portfolio tool, we could simply ask them to create the portfolio
pieces and then utilize whatever software solution they wanted to in
order to showcase their work. The benefits to everyone would be
significant. Students would be in control of their portfolio, and we
wouldn’t be tied to building software or using any specific vendor.

We would have never come to this solution with project thinking. This
solution came about because I was focused on the problem and the
outcome (getting additional users on our application) rather than
building the next feature.

This type of result is typically the outcome of product thinking. And it

can come at any point along the way. In my example above, we avoided
doing any development work. But often it may take several design
prototypes to figure out what will work. Or we may do small amounts
of development work in learning what features will truly drive the
outcome we want. No matter where in the process we learn, the key is
that we are learning along the way rather than deciding on the course
up-front and following a project plan.

The Right Way

So how do we do that? How do keep a product focus?

All products and product management involve some level of project

management. We have to keep things moving along and it is
(unfortunately) unrealistic to assume that we can work in environment
where our stakeholders and partners won’t expect some dates or
commitments.

The key is to make commitments and project plans only at a point when
we can do it with a high degree of confidence. So rather than
committing to a specific path beforehand, we commit once we’ve
validated what we’re doing and have had a chance to really understand
what it will take. Often that is a sprint or two into the work. That may
feel really late in the process, but it is at the point when estimates and
plans can actually mean something. Marty Cagan, in his book Inspired:
How to Create Tech Products People Love, calls this type of commitment a
“high-integrity commitment.” We allow teams time to do proper
discovery and research before asking for commitments.

And we also need to help others realize the benefit of product thinking.
There is a reason many folks ask for dates and timelines. Part of it is
because of old habits. But there are times when it is necessary for
business and budgets. So we need to understand what the job of the
timeline is in those cases. If it is to help sell the product, we should turn
the focus from specific features to the higher level story. If it is to
manage risk, maybe we need to help folks understand that the real risk
isn’t missing a date, it’s missing the mark completely on what value
we’re trying to deliver.

. . .

At the end of the day, the whole purpose of product development is to

deliver value to users and customers. Most of the time we don’t know
exactly what is going to deliver that value though. To think that we can
come up with the right solutions up-front, sometimes a year in advance
if you do annual planning and budgeting, is pretty unrealistic.

While project thinking focuses on coming up with solutions up-front

and then delivering against a schedule, product thinking keeps the
focus on the outcome. That involves some level of comfort with
uncertainty and learning, which can be pretty hard. But if we want to
get to the right outcome, and not just an on-time output, it is really the
only way to work.