The showdown between the “project” and “product” mindset has been sweeping the software industry. Even the most reserved developers are getting heated and opinionated. While some voice a definite winner, it all depends on what each of our clients aims to achieve as far as we're concerned.

But we get it. From a software company’s perspective, the product mindset has an undeniable appeal, returning the highest professional satisfaction. On the other hand, projects can present thrilling digital challenges, so we’re not quick to dismiss the approach. Thus, the question “Which one to follow?” remains. What now?

It’s not about what we prefer. We believe all clients should know what each model entails to pick a side(and win!). Without further ado, here’s the difference between both the product and project approach.

Product-approach: Business at the Core

When engagements between a software company and a particular client follow a product approach, either the digital product that’s being developed is the core of the client’s business or has a persistent business issue that can only be solved with tech.

In this case, a custom multi-functional team is whipped together to ideate, build, and run the product on an on-going basis. The team will act as an embedded part of the client’s business. It will usually include developers and UX designers, but it will also leverage soft or analytical skills from business analysts, product owners, product engineers, and other specialists.

Regularly tuning in with the client, the team establishes the scopes and specs but has the flexibility to reorient quickly without losing the software's architectural integrity. With a vision of long-term effectiveness, the product team also performs short-cycle iterations to perfect and grow the product indefinitely.

The budget in a product approach is not fixed. While specific guidelines or even monthly budgets are agreed upon, adjustments following any new requirements will be expected. Time-wise, the product approach is open-ended, with software teams working as long as the product is successful and profitable.

Project-approach: Specific Problem Targeting

The project model can be applied to solve specific problems adjacent to the core of a client’s business. Thus, whenever a target is clear and quantifiable in terms of time, budget, and scope, running a development engagement by following a project approach makes a lot of sense.

To tackle a project engagement, smaller teams are formed. Often times, these are build-only teams that have a single focus. With a well-defined task and scope, the teams develop the digital project in an established time-frame without having too much calibration freedom.

The risk in this particular case is coming up with an end-result that is well within the initial estimations, but that’s not 100% adjusted to the perfect real-life environment. We all know that tech changes at unbelievable speeds, so the biggest danger of project-based engagements is sticking with only one method just because it was planned. We’re huge advocates for flexibility, whether it’s “product” or “project.”

The project approach type of engagement has fixed budgets and fixed timelines. Again, while constraints can be real focus-generators when getting teams to pull-through, these should be reassessed if the project's best interest requires it.

Talk it over.

The verdict is: there’s no fit-all right or wrong answer. Choosing between one collaboration model or another should be tailored to fit a client’s final objective.

When deciding if it’s a “product” or “project” mindset we should follow, it all comes down to working as a team. Together we'll find the pros and cons and discover which model works best.