Project Management

Moving from Project to Product: What Does “Product Thinking” Actually Mean?

From the Sense & Respond Blog
by ,
Jeff Gothelf and Josh Seiden, leading tech experts and founders of the global Lean UX movement, share their insights into how organizations can grow and thrive based on their ability to sense and respond instantly to customer and employee behaviors.

About this Blog

RSS

View Posts By:

Jeff Gothelf
Joshua Seiden

Recent Posts

Your next agile project: your career

Good Agile Teams Are Diverse Teams: How Diverse Teams Allow You To Solve Problems Early and Often

Moving from Project to Product: What Does “Product Thinking” Actually Mean?

Is Your Organization "Sort of" Agile?

Three Obstacles That Leaders of Cross-Functional Teams Face, and What To Do About Them



Product management has become one of the hottest job titles in most organizations. Is it really that different than project management? In short, it is. And the difference is fundamental because the nature of projects and products couldn’t be more different. The more an organization can embrace a product mindset, the more agility that organization exhibits, the better they can sense and respond. Let’s take a deeper look.
 

Project vs Product -- 3 ways to reframe your mindset


Projects end. Products are continuous. 

In traditional project management we usually work towards a fixed scope. There’s a clear deliverable at the end of the project and once it is handed over to the client or customer, the project is over. The team celebrates and moves on to the next initiative. Their responsibilities are effectively over for this project. The measure of success in this instance is the successful delivery of the project in a way that works as it was designed.
 

Is that the optimal solution? Does it provide real value to the users of that solution? Does it achieve the goals of the business that sponsored it? Generally speaking, this is not the responsibility of the team that built that project nor the project manager who drove it to its successful launch.
 

In contrast, products are continuous systems. Defined explicitly: products are the way an organization delivers and captures value. They don’t have an end. Products are never done. For example, when is Amazon done? When is a bank done? When is your hair stylist done delivering their service? When we view our work as a product we realize that delivering the components of that product are not the measures of its success. They are the continuous evolution (and hopefully improvement) of that product. Our goal when we approach our work with a product mindset is not to celebrate the incremental and iterative deliveries of features, functionalities and improvements but rather their outcomes -- the measurable changes in the behavior of the people who consume those products.
 

Delivering an output is designed to be an ongoing, uneventful part of building continuous products. Instead of celebrating each output, we focus on the outcomes we seek to generate to tell us whether this product is worth any more investment or effort.
 

Projects are linear. Products are circular. 

Because projects end, they have a linear planning process. We work from one phase to the next, handing off our work to the next discipline in the production chain. We ask each discipline to estimate their levels of effort and we put together a linear project plan or roadmap. Our goal is predictability and consistency. We often don’t account for variability or new discoveries because we want to provide a confident answer to the question, “When will it be done?”
 

Products continuously evolve and, as mentioned above, don’t have a specific “end” when they’re conceived. They’re designed to deliver value on an ongoing basis. As new feedback comes in from the use of the product, the team must respond to that feedback and adjust their plans based on this new information. The entire basis for Agile as the new way of working is based on this idea. As an organization learns new things (senses) about its product it adjusts how it responds to those things. The plan changes. The organization and therefore the product exhibit agility. This is critical to success in today’s rapid change environment. Product thinking ensures that our plans stay as agile as our products.
 

Projects are components. Products are systems. 

The continuous delivery of new ideas to market is where projects shine. But these deliveries are simply components of the overall system, the product. Each component may or may not deliver real value to the consumer and the business. Product teams optimize their ways of working to sense as quickly as possible whether this value is being delivered and realized and, if not, to adjust the planning and the system accordingly.
 

Why is this important? Because the consumers of our products are inevitably going to be other people. And these other people, we’re sorry to say, are almost always unpredictable. They don’t use the products as we imagined. They struggle to complete tasks we thought were simple. They abandon our products for seemingly more difficult or “older” tools because of familiarity. Our responsibility as product thinkers is to connect with our customers, understand these pain points and challenges and adjust our product planning to reflect the insights we gain from these conversations.
 

This insight is what allows us to plan the next set of components (mini projects) we want to introduce into the system (the product) remembering that our goal isn’t the deployment of these new components but rather the successful alleviation of the challenges the humans who use our products told us they were having with it.
 

Project managers looking to increase the agility of their teams and to build more of a product mindset in the way they work need to consider these 3 elements of product thinking. In addition, they need to carefully adjust the tools they’ve been using to match this new reality. The tools and methods we use for planning need to embrace agility and reflect that in the work project managers produce. Agile roadmaps provide guidance and direction but can’t commit to fixed time and scope, since it is unknown in a continuous system. The needs of the people we serve are continuously changing which requires today’s project managers to learn how to assess these evolving needs on a regular basis through regular customer interviews. Finally, the needs of the product teams will evolve as well. The tools, data, insight and feedback they require will morph as the product system evolves. As a project manager, it’s your responsibility to empathize with the evolving needs of your team so they can do their best work as well.
 

We have many more articles coming up on how to do these new activities and they are all part of the online course we’re building and launching soon right here with PMI. Learn more and sign up here.

Posted by Jeff Gothelf on: October 18, 2019 12:20 PM | Permalink

Comments (21)

Page: 1 2 next>

Please login or join to subscribe to this item
Dear Jeff
Interesting prospect your
Thanks for sharing
I promise to reflect on your approach and then give you my feedback
However, I would like to ask you some questions.
1. Is a bank an organization or a product?
In my perspective it is an organization that offers its market (customer) several products (service = product), some of them tailored to the customer's wishes.
2. When setting up a production line to manufacture a new product (can it be reorganized to deliver a service) is it a product or project?
3. What is the result of a project called?
4. Getting back to basics: how do we define project?

Hi Luis,

Thanks for your questions. I've replied here:
1. Is a bank an organization or a product?
In my perspective it is an organization that offers its market (customer) several products (service = product), some of them tailored to the customer's wishes.

I agree with you. A bank isn't a product. The services it delivers to its customers are the product.

2. When setting up a production line to manufacture a new product (can it be reorganized to deliver a service) is it a product or project?

The production line itself can be treated as a product in that it delivers a service and it has "customers" (i.e., the people involved in the production line) but I don't believe that the line itself is a product of the organization.

3. What is the result of a project called?

An output.

4. Getting back to basics: how do we define project?
A project is the finite delivery of a component in a larger system.

What do you think?

The project team is dissolved after completion so I do not think "The needs of the people we serve are continuously changing which requires today’s project managers to learn how to assess these evolving needs on a regular basis through regular customer interviews" is the right way of doing. Depended on project types, some require solution evaluation and the solution evaluation approach should be discussed with business owner and time should be scheduled in advance. I do think what you mentioned above is suitable to projects that executed following DevOps model that have been applying in some tech companies where their major services provided to customers through IT products, that need to be changed frequently to meet customer needs and company business model.

Thanks for your thoughts Nguyen. Why is the team dissolved after the project is delivered? When is a project "done"? I guess that's my main point is that products are never done and product thinking means we also rethink how we staff and how long teams stay together on an initiative. The shared understanding they build working together is critical to their future and ongoing success.

Very interesting., thanks for sharing

@Jeff

Each project has a time constrain; after dissolving, team members will be assigned to different projects or they all move on to the next project. Project life cycle is shorter than product life cycle, you know that. If project exists along with product then may be it is existed in the organizations with functional organization structure style. I totally agree with you that product mindset will benefit customer but project is time bound so all should be done in project phases. Thank you for your sharing!

DANK YOU!

I disagree on number 3.
I believe that projects are systems and products are components, because projects contain products among others. Project is the whole, product is a part of the whole.

This article articulates what I've been trying to communicate to my fellow colleagues. I'm employed managing a small project management team at an internal IT department where we build 'product' on top of an existing platform that houses the source of truth data for the majority of our 'products' we offer. We use the term 'projects' for all of our work, but I keep insisting a 'project' is never done once you offer that product (outcome) on the web. Customers and product owners always want more. We take the current stance of the 'project' is done. if you, the product owner, wants more, submit a new 'project' request and wait in line until IT can gather the resources to start the new 'project'. We need to change our mindset - we manage the implementation of 'products' not 'projects'. I will be sharing this article with our management team here. Maybe the light bulb will go on. Thanks for this concise pointedly driven summary that definitely lite up the light bulb hanging over my head.

Great overview. I believe the move to products and it’s impact on project managers is a discussion that needs more exposure. For many knowledge workers it will be their future. Nice work.

@Jeff -

I like the distinctions drawn and offer for consideration that
"projects exist within products". I think the idea of Projects as components and Products as systems can be misused in some firms simply based on their internal language.

The idea that projects exist within products was helpful in overcoming internal discussions/terminology. We found universal agreement that project to add a new feature to a product was obvious, and helped distinguish between project managers (defined scope, schedule and resources) with Product Manager who own customer satisfaction, defining new feature needs (projects), and profitability.

thanks for the sharing of your point, jeff.
I do think your concept has the same essence of the continuous improvement in quality management. the original PDCA concept and also the LEAN approach.
My point of view they are two things
one is the improvement of product, that's more a version update. we know the iphone 1 to iphone 11 as an improvement. but this still happened discretely -- iphone 1 and iphone 11 are different project, different team.
another is the improvement of process, this is the way for example how the iphone is designed. this to me is an OPA and will be improvement all the way as the organization exist.
I do think your point of "Product thinking" is about improving this

thank you for the insight

When project team understands product mindset.
There behavior towards change request during product development will be more open.

Here is my view of how these project-world entities work together:

Projects aim to create capabilities via their deliverables. These capabilities are interlinked in a synergistic way through programs to create outcomes in the form of products or services. These products or services need to be delivered via Sales or the Operations to create benefits for the organization. The business (such as Amazon, etc.) creates wealth through managing multiple programs and projects using portfolio management techniques.
Products are not at the top of the hierarchy, but are certainly an essential component. In a similar way to the operations service, they provide ongoing benefits well beyond the creation lifecycle. They can be changed either incrementally for small changes or by applying project techniques for major upgrades.

Well said!

thanks to the article. I can understand the correlation if you consider the waterfall project approach vs Product. I would be interested to see your input on an agile project vs Product, specially once moving based on the Product has been more closed linked with the Agile methodology than the waterfall.

Interesting article! Thanks for sharing. My point is that a project lifecycle could be different with a product lifecycle... However, if it is necessary, projects can be "systematically" organized to make a "circle" product lifecycle...

Thanks for sharing.

Great post, there is a real gain of shifting to product mindset by seeking regular product consumers feedback than just releasing new product features and functionalities that consumers may least care about..

Page: 1 2 next>

Please Login/Register to leave a comment.

ADVERTISEMENTS

"It is better to have a permanent income than to be fascinating."

- Oscar Wilde