Product vs project – similar words but very different approaches

Long before software development was a thing, people were working on projects. From building a house to writing a book, a project is a broad term covering many processes where you start with a plan and then you execute it. Software development is a relatively new knowledge area so people borrowed methodologies that they were familiar with and adapted them using a term that everyone would understand: projects.

What is SaaP - Software as a Product

But one big problem with software and projects is that projects assume a lot of previous knowledge and understanding – there’s the need for that plan that we mentioned. Writing software doesn’t tend to be like that, you don’t have the certainty of a plan when you start, instead you type the first line of code and you learn as you progress. From a rough idea you discover things over time, then iterate the software and shape what you’re working on into something that is good enough to be released for users.

Recently people have taken this to mean that projects are therefore always wrong for software development and we should always be talking about products instead. But I feel this newly established wisdom is flawed – while the vast majority of digital-first companies should embrace a more software product-based approach, projects are still the way to go in some situations. To know whether to approach software as a product or service, you should understand the benefits and limitations of each, so you can take the right approach to gain maximum value and avoid the kind of mistakes that can kill initiatives.

Is your software initiative a project or a product?

There are several key differences between product and project approaches.

A product

could be software or a service, but it aims to meet a specific need and will require ongoing maintenance and upgrades. Product teams therefore stay together long term to ideate, build and run the product. Unlike projects, which are about the result, products are about the journey. There is no known end point and participants are learning as they go. With a product you never know when each lifecycle stage will end – for example when you’ll move from experimenting to growth. Even if everything seems predictable in the maturity phase, you don’t know when there’ll be disruption. You can’t control the product lifecycle; all you can do is try to prepare for change.

A project

on the other hand, is a way of executing an idea. In practical terms, with a project you need to understand a lot of things before you start: what time, money and people you have available, the expected quality and all the other constraints and drivers across the project execution. These all need to be outlined in the scope. A project is super focused on execution – if you deliver late or over budget, it’s usually not a success even if your story tells otherwise. Projects are temporary with a defined beginning, one or more milestones and a fixed deadline. When the project is finished, the team members leave and begin a new project. Projects assume a predictable environment to start and be successful and planning is an essential part of the process.

One clear example to compare the difference between the two approaches would be the act of planning and writing a book (project) and that of maintaining a blog (product).

Real-life project examples of software as a product and project

Software is complex and abstract, there are many solutions to the same problem and it’s hard to outline what you want to achieve. This means that a product approach is frequently the best way to execute software, but there are still plenty of exceptions.

Security is a case in point. For example, I was once working with a large team of people taking care of data leakage prevention. In this case the solution was to install a set of tools so we had a lot of certainty – we knew exactly what was required, we had a deadline and a budget. It was totally predictable so managing it as a product would be completely wrong. It was a project and needed to be treated as such.

Hackathons are another good example of software as a project. Many software products are the result of a hackathon, but the hackathon itself is a project because it’s short term with fixed constraints and few learnings are allowed within the hackathons' timeframe.

One final example: any time you have a minimum viable product (MVP) you should be working on a project. When you release the first version of the MVP you can then decide to drop it or continue. But if you continue from MVP with a project approach, you will most likely not reach a sustainable pace that is essential to create a good product – a software project is a sprint, a software product is a marathon.

A note on uncertainty

Organisations – and people in general – hate uncertainty, so they seek predictability. This can lead to endless planning and market research, rather than truly iterative and incremental practices like Agile. When we’re working on products we need to focus on the value we want to deliver and embrace the unknown by understanding that we know some things but there are many others that we are yet to discover.

Releasing "good enough" solutions to the problem at hand rather than spending time planning solutions to implement has been proven over the years to be the most successful approach to digital product development. This is essential because most modern software engineering practices only pay off in the long term, so the predictability that a project structure requires is often illusory in these timeframes.

Certainty plays a vital role when we need to evaluate if a project is feasible or not. Understanding our limitations – be it the budget or time or something else – to create as much certainty as we can for the situation will allow us to decide if it still makes sense to continue with the plan.

While projects focus on the outcome and the fixed constraints (cost, time, resources) available to achieve them, products need to focus on crafting a sustainable environment that allows the development of a high-quality outcome regardless of what it is. The sustainable environment is what allows the team developing a product to learn and evolve instead of just following an unrealistic plan.

What your choice of approach means for managing risk

The level of uncertainty embraced ultimately affects the relationship with risk and this is a major difference between products and projects.

When executing a project, risk is part of project management. For every risk, a decision needs to be made as to whether you accept it or mitigate it. This is possible because within a project you have your constraints and landscape mapped out for you. Risk is a constant for projects – you have the same risks throughout the project timeline, although in a good project the risk will decrease as you get closer to project delivery. Project execution is all about managing risk with the assumption that if you can control all risks everything will go smoothly.

With a product you have to embrace risk, be aware of your surroundings and make decisions on the go, with everyone in the team accountable for different risks depending on their role. Risk changes a lot throughout the product process and you have to be ready to pivot on the fly. In a product the risk is constantly high because your product is affected by external factors that you have no control over. For example, when a new competitor releases a better, cheaper product.

Do you have to choose just one approach?

To combine project and product approaches you need to be aware of the differences between them and choose carefully when to go from one to another. Most big tech companies maintain software products, but sometimes a project is needed. Perhaps a competitor has created something interesting and your company wants to see if it would work for you. This would require a software project: a burst of effort, delivery, and then see if it’s something to pursue. Another time a product-focused company would pursue a project is to mitigate risks: maybe some new legislation is introduced and you need to purchase software to continue to operate. A software project can address these needs and solve the problem alongside the product approach.

That said, I disagree with people who say that a product lifecycle is lots of small projects. This can be very harmful because if people aren’t allowed to pull their heads out and see the big picture the long-term perspective can be lost and there is no product innovation or evolution. In a project you need to reach your goal no matter what. While this is good for your project, it’s harmful for your product and people over time.

In a product approach you need to have the freedom and autonomy to take pauses; the team is accountable and they should be trusted to take breaks. When you have one project after another you’ll soon see stress, burnout and high employee turnover, all of which are barriers to innovation. While everyone can work at 100% for two weeks to meet a project deadline, for a product everyone should work at a more sustainable pace, say 80%. Then if there’s a product lifecycle change you can work a 150% burst to pass the critical phase and then return to a sustainable 80% level.

Final thoughts on software as product vs. a project

As you can see, it’s not a matter of product being better than project – they are wholly different approaches – like a hammer and a drill, two different tools for two different jobs. The benefits of both approaches can be leveraged but you need to be aware of the pitfalls of each and when to switch from one to the other. For most software development cases, a product approach will be the right one, but a project approach can be invaluable if deployed at the right time and conducted in an excellent manner. By considering the difference between the two you can continuously make the right choice to extract maximum value from all your software initiatives.