Software project and product

Software project and product: two different commitments

When people search for software project and product, they are usually trying to untangle two words that get used interchangeably. A software project is a bounded piece of work: it has a scope, a deadline, a budget and a point at which it is declared finished. A software product is something people keep using, so it has no natural end. It is judged by whether it continues to solve a problem for a defined audience.

Both are legitimate. An internal migration, a one-off integration or a campaign site is often best run as a project. A tool that customers return to every week is a product, even if it began life as a project. Trouble starts when a team treats one as the other: shipping a product with project habits, or burying a short job under product rituals it does not need.

What changes when you call it a product

The label decides what 'done' means. In a project, done is delivery against an agreed specification. In a product, delivery is the start of the evidence: you learn whether the problem was real, whether the interface is usable and whether people come back. Roadmap items therefore become hypotheses rather than promises.

It also changes ownership and cost. A product needs someone accountable after launch for support, accessibility fixes, security updates and small improvements. If nobody will own that work, it is more honest to scope the effort as a project with a clear handover or retirement date than to call it a product and let it decay.

• Project: success means agreed scope delivered on time and within budget
• Product: success means a measurable change for a named audience, sustained over time
• Either: a written statement of the problem and who has it

Start with problem clarity, then release in small testable steps

Whatever you call the work, the first artefact should be a short, falsifiable problem statement: who struggles, with what, how they cope today and what would visibly improve. If that cannot be written in a few sentences, scope is not yet clear enough to estimate a project or justify a product.

Next, match the build to the question you need answered. IVRYN's guide on prototypes, MVPs and proofs of concept separates them by purpose: a prototype explores the experience and whether people understand it, a proof of concept tests one technical feasibility claim, and an MVP is a bounded real-world release that produces evidence. The guide is explicit that a deployed MVP does not by itself prove adoption, revenue or product-market fit. Choosing the wrong artefact wastes effort, for instance polishing an MVP when the open question is whether a data source can be accessed at all.

Small releases keep both projects and products honest. Each release should change one thing you can observe, so a disappointing result points to a cause rather than to a pile of simultaneous changes. 'Minimum' never means unprotected: the guide notes that an MVP still needs authentication, privacy, accessibility, error handling, monitoring and recovery wherever its context requires them.

Accessibility and outcomes belong in the definition

A product that some people cannot operate has a smaller audience than its roadmap assumes. Keyboard access, readable contrast, clear labels and forms that explain errors are worth planning from the first release; as general guidance rather than a measured finding, retrofitting them later tends to touch more of the interface. WCAG 2.2, which the IVRYN guide lists among its primary sources, gives a recognised reference for these checks. Treat them as release criteria alongside functional tests.

Measurable outcomes complete the picture. Pick one or two signals tied to the problem statement, such as tasks completed without help or the share of users who return for the same job, and decide in advance which result means continue, change direction or stop. Totals like sign-ups rarely show whether the problem is being solved.

Example: is this scheduling tool a project or a product?

This is a hypothetical example, not a case IVRYN has worked on. A three-person team at a small clinic network wants software to stop rooms being double-booked. The founder sees a product to sell to other clinics; the operations lead sees an internal project.

Working through the checklist below, the team finds the problem is clear for its own sites but unverified elsewhere. A sensible path is to run the internal build as a fixed-scope project, while treating outside demand as a product hypothesis explored with a prototype shown to a few other clinics. Only if they report the same pain, and someone is ready to own the tool long term, does it graduate to an MVP: one bounded booking path released to real users, with the authentication, privacy, accessibility, error handling, monitoring and recovery that patient-adjacent scheduling requires, and a named decision the evidence will inform.

• Can we state the problem, the audience and today's workaround in three sentences?
• Is there a natural end date, or will people rely on this indefinitely?
• Who owns maintenance, support and accessibility after the first release?
• What is the cheapest build that answers our current question: proof of concept, prototype or MVP?
• Which one or two measures will show it worked, and what result means stop?

Limits of this advice and how IVRYN frames it

IVRYN, a Paris studio that operates independently, runs each of its products as a distinct offer with its own domain, intended users and page. Its public methodology describes how it builds, verifies, operates and explains products, and sets the evidence standard its case notes must meet, favouring tight scope and automation that stays accountable. This article draws on that stance and the guide cited above; it reports no studies, client work or measured results, because none are claimed here.

The guidance is deliberately general. Regulated sectors, contractual delivery terms, procurement rules and safety-critical software can impose requirements that override any project-or-product framing, and those questions belong with qualified advisers. Use the checklist to structure a conversation, not to replace domain review.