Product or Project Approach: Which One, When and Why

The [e-spres-oh] Team
Tea Break by [e-spres-oh]
4 min readDec 16, 2019

--

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, as far as we’re concerned, it all depends on what each of our clients aims to achieve.

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 too, 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 in order 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, it means that either the digital product that’s being developed is the core of the client’s business or that they have 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. Usually it will 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 architectural integrity of the software. With a vision on 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 in accordance with any new requirements are to 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 that are 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 advocated for flexibility, no matter if 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 it comes to getting teams to pull-through, these should be reassessed if the better of the project requires it.

Talk it over.

The verdict is in and 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.

So, when deciding if it’s a “product” or “project” mindset we should follow, it’s about you and us together. Only as a team we can discover which model is best. And the answer is, each time and engagement, it is different.

If you want to keep up with our mischievous ways of coding and doing fun things with great energy, subscribe to Tea Break (our blog right here on Medium), stay up-to-date with our LinkedIn, like our Facebook page, talk to us on Twitter or follow us on Instagram (but not in a creepy manner).

--

--

We are a software development company with headquarters in Washington DC and engineering offices in Timisoara, Romania. Read our stories to find out more.