--- title: "Writing product requirements without a technical background — Orvun Labs" description: "Describe observable behaviour before choosing a technology. A useful requirement identifies the person, their starting situation, the action and the result they can verify." canonical: "https://orvunlabs.com/en/journal/product-requirements-for-founders" language: "en" last_modified: "2026-09-13" --- # Writing product requirements without a technical background Describe observable behaviour before choosing a technology. A useful requirement identifies the person, their starting situation, the action and the result they can verify. ![Writing product requirements without a technical background](https://orvunlabs.com/images/blog/mvp.svg) - Published: 2026-09-13T09:00:00.000Z - [MVP & validation](https://orvunlabs.com/en/journal/topic/mvp.md) ## The decision Describe observable behaviour before choosing a technology. A useful requirement identifies the person, their starting situation, the action and the result they can verify. Add access restrictions and exceptions where they change that result. ## A worked example For an illustrative expense tool: a team member submits a receipt; their manager approves or returns it with a reason; finance exports approved entries. State what happens if the receipt is unreadable, the manager is absent or someone edits an approved amount. Those cases shape the product more than the phrase “expense dashboard”. ## Write one example that can be acted out Take the expense submission and write it with concrete, fictional values: a team member uploads a receipt for a named trip, chooses the project and submits it. The manager sees only the submissions they are allowed to review. Returning it requires a reason and makes the item editable again. Approval locks the approved version for the agreed workflow. Avoid assuming what “lock” means: specify whether a correction creates a new version, requires renewed approval or is rejected. Someone should be able to act out the example using cards or a rough sketch before any technical implementation is discussed. ## Distinguish rules from preferences and assumptions Use separate labels for a mandatory rule, a design suggestion and an unresolved question. “Only finance can export approved expenses” is a permission rule. “Put the export action at the top right” is a design suggestion. “Finance needs spreadsheet format” is an assumption until the receiving process is known. This distinction lets a designer improve the interface without accidentally changing the promise. Include the source of a rule and who can clarify it. If a contractual or legal requirement is involved, obtain the relevant authoritative wording or qualified interpretation rather than asking a developer to guess from a second-hand summary. ## Review the requirement with the people on both sides Ask the submitter, reviewer and receiving finance operator to follow the same example. Their questions often concern different failures: an upload interrupted, an absent manager, an export repeated or a receipt corrected after approval. Add the necessary decisions and leave nonessential preferences open. Then write what the demonstration must show and what data is needed to run it safely. Keep a versioned record of approved requirements so changes can be evaluated against a known baseline. A clear requirement is not the one with the most technical vocabulary; it is one that lets the team build and evaluate the intended behaviour without inventing business decisions on your behalf. ## Alternatives worth weighing A short narrative explains context. An annotated sketch clarifies interaction. Acceptance examples establish boundaries. Use all three where helpful; a large formal document is unnecessary if the decision record stays complete and current. ## Where the plan breaks Avoid prescribing database tables to express a business rule. Do not write “fast” or “easy” without saying which task and how you will assess it. Keep requested behaviour separate from design suggestions, and nominate one person to resolve conflicting requests. ## Before you commission the work Can another person demonstrate success and failure from this description? Is each role named? Are sample records safe to share? Bring the requirements and uncertain cases to an MVP workshop; technical details can follow once the intended behaviour is understood. ## MVP development A first product with a clear reason to exist. - [Discuss this service](https://orvunlabs.com/en/services/mvp-development.md) ## Related reading - [Which features belong in a first MVP?](https://orvunlabs.com/en/journal/choosing-mvp-features.md) - [No-code, low-code or custom development for a first product?](https://orvunlabs.com/en/journal/no-code-low-code-or-custom.md) ## Let's make something useful. A first product, a difficult workflow or software that needs a fresh start. Tell us where you are. - [Tell us about your project](https://orvunlabs.com/en/contact) ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://orvunlabs.com/#organization", "name": "Orvun Labs", "url": "https://orvunlabs.com", "logo": "https://orvunlabs.com/orvunlabs-icon-512.png", "description": "Custom software, SaaS products and AI-powered tools — designed around your business.", "knowsAbout": [ "Custom software", "SaaS product development", "AI integration" ] }, { "@type": "WebSite", "@id": "https://orvunlabs.com/#website", "name": "Orvun Labs", "url": "https://orvunlabs.com", "inLanguage": [ "en", "es", "de", "fr", "pt", "ja", "hi", "ar", "id", "tr", "pl" ], "publisher": { "@id": "https://orvunlabs.com/#organization" } }, { "@type": "WebPage", "@id": "https://orvunlabs.com/en/journal/product-requirements-for-founders#webpage", "url": "https://orvunlabs.com/en/journal/product-requirements-for-founders", "name": "Writing product requirements without a technical background", "description": "Describe observable behaviour before choosing a technology. A useful requirement identifies the person, their starting situation, the action and the result they can verify.", "inLanguage": "en", "isPartOf": { "@id": "https://orvunlabs.com/#website" }, "about": { "@id": "https://orvunlabs.com/#organization" }, "breadcrumb": { "@id": "https://orvunlabs.com/en/journal/product-requirements-for-founders#breadcrumb" } }, { "@type": "BreadcrumbList", "@id": "https://orvunlabs.com/en/journal/product-requirements-for-founders#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Orvun Labs", "item": "https://orvunlabs.com/en" }, { "@type": "ListItem", "position": 2, "name": "Writing product requirements without a technical background", "item": "https://orvunlabs.com/en/journal/product-requirements-for-founders" } ] }, { "@type": "BlogPosting", "headline": "Writing product requirements without a technical background", "description": "Describe observable behaviour before choosing a technology. A useful requirement identifies the person, their starting situation, the action and the result they can verify.", "datePublished": "2026-09-13T09:00:00.000Z", "dateModified": "2026-09-13T09:00:00.000Z", "inLanguage": "en", "author": { "@id": "https://orvunlabs.com/#organization" }, "publisher": { "@id": "https://orvunlabs.com/#organization" }, "image": [ "https://orvunlabs.com/images/blog/mvp.svg" ], "mainEntityOfPage": { "@id": "https://orvunlabs.com/en/journal/product-requirements-for-founders#webpage" } } ] } ```