The software product and software process

The software product and software process: two related but separate things

When people talk about the software product and software process, they mean two different things. The product is what people actually receive: running code, the interface, stored data, configuration, documentation and support material. The process is the set of activities and decisions that produce and maintain that product. It includes discovery, design, building, testing, releasing, monitoring and retiring features. You can inspect a product directly. You usually see a process only through its effects.

Keeping the two apart matters before you act. A team unhappy with its software might change the process when the product is the real problem, or the reverse. A new workflow cannot fix a feature nobody needs. A clear feature idea will still disappoint if it is shipped carelessly.

This article is written from the perspective of IVRYN, an independent product studio in Paris. The advice reflects how the studio documents its own approach. It is not based on any study, survey or measured result.

How the process shows up in the product

Process choices leave marks on the product. If testing happens only at the end, defects reach users in batches. If design decisions are never written down, the interface drifts and becomes inconsistent. If releases are large and infrequent, it gets hard to tell which change caused which effect. Seen this way, many product qualities, such as reliability, consistency and clarity, are partly process outcomes.

The link has limits, though. A disciplined process can still produce something nobody needs, because process quality does not prove usefulness. A loose process can occasionally produce a useful tool, though that is hard to repeat or maintain. So treat the process as something that makes good outcomes more likely and easier to check. It does not guarantee them.

Start with problem clarity before choosing a method

The most useful first step is to write the problem down precisely. Say who has it, in what situation, what they do today, and what would count as better. If you cannot fill those in, debating Scrum against Kanban, or monorepos against microservices, is premature. The problem statement decides which process questions are worth asking.

Problem clarity also tells you what kind of artefact to build first. IVRYN's guide on prototypes, MVPs and proofs of concept separates these by the question each one answers. A proof of concept checks whether something is technically feasible. A prototype checks whether the shape and flow make sense to people. A minimum viable product checks whether real users get value from a working, if narrow, version. Confusing these is a common way the process undermines the product. For example, a team may ship a demo as if it were an MVP, then read silence as rejection.

Small testable releases and accessible interfaces

Small releases connect process and product most directly. Each release should change one thing you can describe and observe. When something improves or breaks, you can then trace the cause. Small releases also lower the cost of being wrong, which matters most when evidence is thin early on.

Accessibility shows why some product qualities have to be built into the process rather than added at the end. Keyboard navigation, readable contrast, meaningful labels and clear error messages are product properties. They only arrive reliably when they are part of how work is designed and reviewed. Standards such as the W3C's Web Content Accessibility Guidelines are a practical reference, though meeting a checklist is not the same as being usable by everyone. Following a standard is a floor, not a finish line.

Measuring product outcomes without inflating claims

Process metrics, such as tickets closed, deployment frequency or story points, describe activity. Product outcomes describe whether users' situations changed: a task finished faster, fewer errors, a workflow abandoned less often. Both are useful, but only outcomes tell you whether the product is doing its job. Choose one or two outcome measures tied to the problem statement before building, not after.

Be careful about what the numbers can support. Small user groups, short time windows and changes that overlap make strong conclusions unsafe. IVRYN's public methodology reflects this restraint. The studio prefers narrow scope, usefulness that can be checked, and automation that stays accountable, and it avoids claims that outrun the evidence. Automation in the process, such as tests, deployment pipelines or generated content, should still have a person responsible for what reaches users.

Example: a decision checklist for a three-person team

Example (hypothetical): a three-person team has built an internal scheduling tool. Users say it is "clunky", and the team is considering a full rewrite with a new development workflow. Before deciding, they go through the checklist below. It helps them see whether the issue sits in the product, the process, or both.

In this hypothetical, the answers suggest the product problem is one confusing booking step. The process problem is that releases bundle many changes, which hides cause and effect. The sensible next move is a small release that fixes the booking step, plus a commitment to ship one change at a time. That is cheaper than a rewrite and easier to evaluate.

• Can we state the user problem in one sentence, naming who has it and when?
• Do we know which artefact we need next: proof of concept, prototype or MVP?
• Can the next release be described as one observable change?
• Have we picked one outcome measure tied to the problem, not to team activity?
• Is accessibility part of design review, or checked only before launch?
• Does every automated step have a named person responsible for its output?
• Would our evidence support the claim we plan to make about the result?