From Project to Product Mindset: How to Make The Change

It’s cold and wet outside, so it’s time to have a more in-depth discussion while snuggled up to an over-sized cup of something hot and energizing. So let’s buckle up and dive into the intriguing prospect of what it takes to shift from a project mindset to a product mindset!

Imagine you’re in a team that’s all about projects. Your day is packed with churning out deliverables, ticking off boxes on a never-ending to-do list. It’s like being in a race with blinders on, charging forward heedlessly to meet output-focused goals, often dictated by other business needs.

This could be anything from sales-driven urgencies to an assortment of tasks scattered across the company. The project mindset essentially transforms your team into a delivery machine, where the motto is “Make it, and make it fast!” But is it always the right thing to make? That’s the question often left unanswered.

Now, let’s flip that coin. Enter the product mindset. Here, the game changes. It’s not about the business telling you what to build; it’s about your team becoming explorers, charting their own course. It’s a mindset that’s less about taking orders and more about discovery. You need to probe the depths of “What’s the best thing to build? Why? How?” It’s a journey of learning, experimenting, and iterating, where the team doesn’t just accept tasks; they question, they understand, and they innovate.

Both mindsets involve tackling projects, but they’re worlds apart in approach and impact. With a project mindset, your path is often pre-decided by external forces, leaving little room for team input. In contrast, a product mindset empowers the team to choose their battles, to embark on initiatives born from discovery and insight.

It’s a shift from being project executors to being product visionaries, where the focus is on building something that resonates with the market’s pulse, not just what’s on a predetermined list.

So, let’s dig in to the details, the differences between a project and product mindset, and what you can do to encourage your team as it transitions from the former to the latter. And, of course, why you should bother!

What are the differences between a project and product mindset? 

A team with a project mindset typically thinks in terms of getting deliverables out the door in order to meet output-focused aims. These are aims that are often tied to other needs within the business.

Sometimes they’ll be sales-driven needs, tied to things that the Sales team has sold that don’t exist yet, or they could be other projects that are needed throughout the business. 

What tends to happen with the project mindset is that the business constantly needs the product team to simply deliver a laundry list of things to be made. Their job just becomes, “If these are things to do, and we have this many people to work on it, how long is it gonna take us to do it?” Wash, rinse, repeat. So the team just becomes focused on getting those projects out the door, whether or not those projects, are in fact, the right thing to do.

Don’t just make stuff for the sake of it

A product mindset flips that on its head a little bit. The team works in a way where they think about “What are the best projects to build to best serve the business?”, as opposed to the business telling them from different angles which projects to go build.

And so a product mindset is much more focused on the team doing discovery. They need to be asking the right questions to figure out what should be built and why, in what order, and then doing the discovery, the learning, the experimentation, and iterating along that path.

Both approaches involve taking on projects, but the nature of those projects will be different with a project mindset. They’ll often be predetermined by some external force ahead of time. The team actually delivering the projects has no say, or very little say, on what they’re delivering. They just have to go deliver it. 

Whereas in a product mindset, the team has a lot of control over what projects they take on. They’re basically kicking off an initiative here to go do some discovery. And then that will determine which projects they take on after that.

Project mindset:

• Temporary endeavor: Projects are defined by their temporary nature, aiming to achieve specific goals within a set timeframe and budget.
• Structured planning: Involves a clear beginning, end, and a series of predetermined steps and milestones.
• Focus on execution: Emphasis is on adhering to the plan, schedule, and deliverables with little deviation or innovation.
• Output-oriented: Success is measured by the completion of the project objectives​​.

Product mindset:

• Ongoing process: Products are seen as evolving entities that adapt and grow over time.
• Strategic and adaptive: Focuses on long-term strategy, market feedback, and changing user needs.
• Outcome-focused: Prioritizes customer value and strategic outcomes over specific tasks or features.
• Continuous improvement: Involves regular updates and iterations based on user feedback and market changes​​.

Are there times that it’s still useful to have a project mindset when you’re making a product?

Yes, sometimes. It can be useful to have a project mindset if the thing that you’re looking to build is a known quantity. If you know what the final solution is and that final solution will lead you to success and all you need to do is build that thing, then the best way to tackle it is to break it down as a project.

Figure out how many resources it’s going to take, what’s the best order and how long it’s going to take if we break it down into pieces and tackle them. Then you break it down into smaller bits or sub-projects and manage them like a project. That is the most effective way of managing it, and good project management can be magic!

But the reality is, when you’re building a product company or you’re building a product you don’t even know what the final product is!

Is that your final answer?

That is the case for most of us in product companies. You don’t have this final answer. And even if you did know what that perfect finalized product was, by the time you got there the markets will have changed, the competition will have changed. You can’t know what the perfect product will be by the time you’re done making it, because the context around it will have changed.

We don’t know the future. So no one truly knows what it is that they should be building. That’s why the best product teams should be adaptable.

That’s what the shift from the project to product mindset is all about. Instead of setting a list up ahead of time, working out all the projects that you’re going to build, and then setting out the best, most effective way of building them really quickly… They should be building a way to be adaptable so they can build towards the best thing reflective of what the market needs at that time. Because they might be building the wrong thing.

What sort of impact does shifting from a project to a product mindset have on your business strategy?

Perhaps most importantly, it allows your team to be more adaptable to change. If you’re in a project mindset, you’re often behind the curve and missing out on opportunities in the market. You’ll keep finding that you’re building outdated stuff, because you came up with that list of projects to build some time ago.

By the time it takes you to take that list of projects, flesh it out, and work out exactly how long it’s going to take and get people working and moving on it, the world in which those assumptions were based will have already changed.

Doing all that takes time, and that’s time not necessarily well spent. Because in that time, your competitors (who already shifted from a project to product mindset) have been cracking on and just finding ways to solve problems.

So it means that you end up falling behind your competitors just by nature of the fact that you’re spending so much time on all this planning work.

Project Impossible

Worse still, despite all this planning, projects don’t go perfectly, so you keep on building in tech debt.

You end up launching something, and it’s one thing to build just the one project. But when you have a project mindset… Sure, you’ve finished your project, great! But then your plan said that you have to build another project the next month, and another project a month after that.

If you want to keep on track, all those projects have to line up on time. So you have to rush them out the door, because inevitably at leas one of them is going to be late (probably more than one of them because projects are never completed on time!).

You end up with multiple of them either coming close on time or over time. And so you end up by the cutting out scope and finishing less of them than planned, or you finish them, but not to the level of quality that they should be made to.

Death by a thousand cuts

Oftentimes, for the product manager and the rest of business side of team, this is seen in the code in very insidious ways.

Ask one of your developers if they’re proud of their code. Is this code that they would be happy to support six months from now, or six years from now?

Or even two years from now, when they’re training up a new developer on the team – have they done all the documentation and code commenting within, so they know what’s going on and how to explain it? Is it the most elegant way of implementing something that’s scalable, secure, and performant? Is it going to be fast enough?

Or did they realize, “Oh…  this is due on Thursday for Friday’s release, so I better just make it work somehow.” And it works. Great, they got it out the door. And when they go do the next one, cool, they also made that one work.

And so what you have are a bunch of projects that work, but ultimately you have incoherent spaghetti code that would make a new dev cry.

This is how you end up with teams who have lots and lots of these projects, and it’s like cutting with a thousand paper cuts. They end up with such tech debt-ridden code that they have to basically call technical bankruptcy, and just throw it all out. They have to do an entire rewrite of their code because it’s junk. 

And, because they’ve been running these stressful, get-it-out-on-time launches every month (or however often they do launches), the developers are all stressed. Plus, the code isn’t any good, so no one likes to work on it. So the developers have started quitting because it’s stressful. They can go work elsewhere if they want to. 

So they have to rewrite the code because no one knows how to even deal with this monster any more. And that’s really expensive, as opposed to just saying, “Hey, you know what? Maybe let’s work on the best thing for the company and not necessarily just stack up a list of projects?”

Avoiding the Iron Triangle

You’ve probably heard of the Iron Triangle of project management. Basically the corners of the triangle are scope, cost, and time. If you scrimp on those, it squishes out the room for quality, which is in the middle of the triangle. And, for example, if you have a fixed point like a time when the project needs to be completed, and a set budget to work with, that means you have to compromise on the scope.

If you go do way ahead of time, make a big list of projects, and then just do them blindly because the plan said we had to go do them in this order and at this time… If you have date and if you have time and scope fixed then quality has to give basically. And that’s what that’s exactly what does give, most often.

The thing is that companies with a project mindset tend to want fast and cheap. I mean, it looks good on the surface, right? That’s because they’ve got front-end developers that can make things look good. But underneath… Spaghetti code.

And then you’ve got teams who end up building the wrong thing because they are a little bit blinkered. They’re blinded to what the best things are to build because they don’t have this mindset of saying “We’re building a product, and this product has to be something that is going to be valuable to our users. It has to be technically feasible. It has to be valuable to the business and desirable.

They’re not asking “What is the best possible intersection of things that we could build based on where we are now, what we have, where the business is going, and what we know in general? What are the stepping stones we should follow to get there?”

Instead, they just go, “Well, Boss said we should do this, and the salespeople said we should do this. And last year’s roadmap said to do this. And there’s a bunch of stuff in the roadmap. Sooo… kind of pile that up together, and we got this. Let’s just go build that. Right”

And they get a little pat on the head for saying, yeah, we can go build these things, but they’re not really doing great product management. They’re not doing critical thinking or strategic thinking, really. They’re just building out a bunch of projects, which you can do, but it’s not going to make yourself a great product overall.

Is shifting from a product to project mindset just something for the Product Manager to do, or is this something for the whole team?

The transition from project to product mindset should be something that the entire team adopts. The Product Manager should champion it, be a really good advocate for it, and be the person who helps to make sure that the team goes through with it.

But it also helps when this product mindset is adopted at the Exec level, and isn’t just something that the product manager is going on about while everyone else looks around and shrugs.

One of the ways that product mindset really helps is to provide some transparency into the product management process. Sad to say, a lot of the time, people think that product management is where ideas go to die, right? They think the Product Manager is hiding away all these arcane secrets about why one idea goes to development and then another idea doesn’t.

And we don’t mean to, right? We’re not saying “no” to your idea out of spite or because, you know, Ted’s ideas are our favorites.

It’s because Ted came up with ideas that are aligned with the overall business goals and helps solve a problem along path that’s going to help us reach our vision. And that’s why his idea got on the roadmap and yours didn’t. But if you want to see how you’re having an impact, then you can see that your idea for the product ended up on the roadmap here.

That way, when I say no to your idea, it’s easier for you to see that it’s not me saying no to your idea. It’s the product management system. And the product management system is saying yes to just the select few things that will help us to build the best product.

And it’s not me picking and choosing. I’m helping to guide it. helping to externalize the product management decisions. Then the factors that go into the product management decisions, but it’s not me just standing on a pedestal going, “This one… yes. This one… no!” It’s based on factors that you can see and that you and everyone else in the team can weigh in on.

But that product mindset really comes down to thinking more holistically about what is good for the business and those central three factors: Is valuable for the business? What’s desirable for our customers? What’s technically feasible?

And for the record, I’d argue you should add two more factors to that set: What’s ethically right to do? What’s sustainable?

How to evolve your team from a project to product mindset

1 – Admit there’s a problem

Transitioning from a project mindset to a product mindset can be one of the hardest things in the world for an established company. A lot never survive the process. What tends to really happen is a lot of these bigger, really slower companies end up dying out and getting replaced with younger, more product mindset companies who already have this more nimble product mindset.

That is one of the realities. But some companies are after making that transformation. And, as ever, what it really comes down to is admitting that there is a problem. Once they recognised that there’s a problem with the way they work, they can get the right people on board to identify the problem, and then that problem can be tackled head-on.

2 – Avoid the Agency Trap

A lot of times, the way that a company’s been working isn’t just down to how ideas are tracked, how things are released, and that sort of that stuff. It comes down to where where that work comes from in the first place.

If your company has been operating in a way where that’s very Sales-led, the Sales team is basically taught “Go over there and sell the product, whether or not what you’re selling exists yet!” That can be a hard habit for them to break.

Whereas if you work with your salespeople you can say “Here’s our ideal customer profile, sell to these types of customers. Don’t sell what we don’t have already in the product. Your job is to sell to our ideal customer and find more of them. If you’re not able to find more, you’re not working hard enough! It’s not your job to go make up the difference for people and invent a product that doesn’t exist yet.”

Because that’ll end taking up all the development time to go do something new that they’ve been forced to add, when the Sales team could have just picked up a few more phones and called somebody else who wants what you’re already making.

I’ve written about this in more detail before, as well as giving a talk on the subject at UX Brighton in 2022 that you can watch here.

3 – Embrace a long-term vision using a product roadmap

Implementing an effective product roadmap is like having a GPS for your product’s journey. It’s not just a document; it’s a strategic beacon that lights up the “what”, “why”, and “when” of your team’s focus. This roadmap is your storytelling tool, combining the grand vision with the nitty-gritty of planning. It’s about looking beyond today’s achievements and charting a course for future success.

Your roadmap is where ambition meets strategy. It’s about setting those sky-high goals that push your product to evolve and grow. The roadmap is a visual story of this vision, balancing lofty aspirations with the practicalities of day-to-day tasks. It’s about making sure every small step taken today aligns perfectly with the big leaps planned for tomorrow.

4 – Keep your users at the forefront

Keeping your users at the center stage isn’t just a buzzword; it’s a crucial strategy. Your product team will need to make the effort to hone in on the evolving needs, preferences, and pain points of your users.

It’s about trying to keep your finger on the pulse of the market. Establishing a feedback loop becomes essential here. It’s not just about collecting feedback; you want to create a dynamic conversation with your users. This dialogue is what fuels the continuous improvement of the product, making it resonate more profoundly with their needs and expectations.

Incorporating this user feedback into your decision-making requires making choices that aren’t just based on gut feelings or trends but are rooted in real, tangible user insights. This approach transforms your product’s development into a data-driven journey.

And what happens when your users suggest a change? The product team doesn’t just take note; they’re ready to pivot, ensuring that the product not only meets but exceeds user expectations. It’s this kind of agility that keeps a product relevant and desirable.

5 – Optimize your team’s organization to encourage autonomy

Imagine a world where teams are structured to have the authority and resources to make their own decisions. It’s empowering, right? Plus, when you mix in a diverse range of skills in each team, you’ve got a recipe for covering all bases in product development. It’s like having a well-oiled machine where every part plays a crucial role.

But the perks of team autonomy go beyond just empowerment. Teams that can make swift decisions respond quicker to changes, boosting their overall efficiency. And when it comes to innovation, autonomy is like a magic ingredient. Teams with the freedom to make decisions are like scientists on the cutting edge, always ready to experiment and innovate.

However, as Uncle Ben reminds us, with great power comes great responsibility. Maintaining a balance is key. It’s essential to ensure that these empowered teams are still aligned with the broader organizational goals. Regular communication channels are vital to keeping these autonomous teams connected with the overall vision and strategy.

6 – Use a Now-Next-Later roadmap

The Now-Next-Later Roadmap, if I do say so myself, is a fantastic tool for Agile product management. It works using time horizons, dividing your product journey into three exciting phases: Now (what we’re tackling right this moment), Next (our near-term adventures), and Later (those big dreams down the road).

What’s great about this approach is its focus on outcomes, rather than features or deadlines. It’s about aligning with those big-picture strategic objectives.

Even better, the NNL roadmap has flexibility baked in. It adapts as new learnings roll in, as feedback signals changes, and as the market dances to its own unpredictable tune. This adaptability provides a crystal-clear view of what’s happening now and what lies ahead, helping teams make strategic decisions with confidence.

Implementing this roadmap isn’t a set-it-and-forget-it deal. It’s a living, breathing document that requires regular updates to reflect the ever-changing business landscape. And here’s where it gets inclusive: stakeholders get to have a say, ensuring everyone is on board and aligned with the roadmap. This way, the Now-Next-Later roadmap becomes more than just a planning tool; it’s a beacon, guiding teams to focus on what’s truly important at any given moment.

ProdPad is the home of the Now-Next-Later roadmap (though it’s getting more and more popular these days!). If you want to take a look at how one works in practice, take a look at our Sandbox!

Back to the Later

The shift from a project to a product mindset is akin to transforming from task executors to strategic thinkers. It’s about elevating your team from simply following a set plan to actively engaging in discovery, innovation, and adaptation.

Not only does this encourage a more dynamic and responsive approach to product development but also keeps your team aligned with the ever-changing needs of your market and customers. It’ll also keep them happier, as they’re not bogged down in unparsable code and unbearable tech debt.

Embracing the change from a project mindset to a product mindset will position you to not just to respond to the present but to shape the future. You may still need roads though. Or a NNL roadmap, at least!