IVRYN
What a product development studio does
A product development studio helps turn a defined problem into software that can be designed, built, released and improved. For a founder or small operating team, its value is not simply adding development capacity. It is helping create a useful sequence of decisions: whose problem matters, what the first release must prove, what should wait, and how progress will be assessed after release.
The phrase product development studio covers different working models. Some teams concentrate on design or engineering delivery, while others support earlier product definition and later iteration as well. Before acting, ask where the studio enters the work. A team with an untested idea may need help clarifying the problem and selecting a learning-oriented first release. A team with a narrow, validated workflow may instead need reliable execution against an existing scope.
IVRYN is an independent studio operating from Paris with a portfolio of separate digital products. Its public product context supports a focused view of studio work: products should have a clear audience and a distinct home, while automation should remain responsible and usefulness should be observable. That context does not establish universal results for every product or client situation.
- A studio can help define the problem, but it cannot supply certainty that the market wants the result.
- A first release can test a focused assumption, but it is not a promise of a scalable business.
- Technical delivery matters, but it cannot replace product decisions about audience, workflow and trade-offs.
Start with problem clarity before choosing a build
The most important early question is not which technology to use. It is what precise difficulty a person or team faces, in what situation, and what better outcome would look like. A broad ambition such as “make operations easier” is usually too vague to guide a first release. A clearer version identifies a user, a repeated moment of friction and a change that can be checked.
Problem clarity also separates an urgent workflow from an interesting concept. If a team cannot describe the current workaround, the cost of the problem or the decision a user is trying to make, the work may still be exploratory. That is not a failure. It means the next step should be designed to reduce uncertainty rather than prematurely produce a large application.
A useful studio relationship makes assumptions visible. For example, an assumption might be that independent operators will return weekly to review a short prioritised list. The associated product question is then narrower: what minimum experience would let those operators complete that review with less effort than their present method? This is more actionable than a request for a general dashboard.
- Name the intended user and the context in which the problem occurs.
- Describe the current workaround without treating it as proof that a new product is needed.
- Write one observable outcome for the first release, such as a completed workflow or a repeat action.
- Separate known constraints from assumptions that need to be checked.
Product development studio choices: prototype, proof of concept or MVP
A product development studio should help match the format of the work to the uncertainty being addressed. IVRYN’s public guide distinguishes a prototype, a proof of concept and a minimum viable product as different tools, rather than interchangeable labels. The useful choice depends on the question that must be answered next.
A prototype is appropriate when the main uncertainty concerns interaction, comprehension or the shape of an experience. It can make a proposed flow concrete enough to discuss without claiming that it is production-ready. A proof of concept is better suited to a technical uncertainty: whether an integration, model, architecture or other capability can work under the relevant constraints. An MVP is a usable, limited product release intended to deliver a core use case while supporting learning from real use.
These formats should not be chosen because one sounds more advanced. Building an MVP when the core technical dependency is unknown may create expensive rework. Treating a prototype as market validation can overstate what polished screens reveal. Conversely, delaying a small usable release until every edge case is settled can postpone the information a team actually needs.
- Choose a prototype when the key question is “Can people understand and use this flow?”
- Choose a proof of concept when the key question is “Can this critical technical approach work?”
- Choose an MVP when the key question is “Will a limited, usable release address the core task well enough to learn from use?”
How to define a small, testable release
A small release is not merely a reduced feature list. It is a coherent path through one important job. The user should be able to arrive with a real need, take the essential actions and reach a meaningful end state. Removing secondary controls, broad permissions systems or future integrations can be sensible; removing the step that makes the outcome useful is not.
The release should include a way to judge whether it is helping. That does not require a complicated analytics programme or a claim of causal proof. It means deciding in advance which product signals are relevant: completion of the central workflow, return use for a repeated task, error patterns, time needed to complete a step, or direct requests for a missing capability. Interpretation should remain cautious because a small number of signals may reflect onboarding, novelty or a narrow user group.
Accessible interfaces belong in the scope of useful product work, not in a final visual pass. Clear labels, understandable states, keyboard-reachable controls, sufficient contrast and error messages that explain recovery paths can help more people complete the same core job. Accessibility decisions should be considered alongside interaction and content choices from the start.
- Define one primary user journey and its successful end state.
- Record what is deliberately out of scope and why.
- Choose a small set of product outcomes that relate directly to the release’s purpose.
- Include basic accessible interaction and recovery states in the definition of done.
Worked example: deciding what to build first
Example only: imagine a five-person operations team that loses track of recurring approval tasks spread across email and chat. The team believes a shared workspace could help, but it does not yet know whether the main difficulty is discovering overdue work, assigning ownership or obtaining timely decisions.
A sensible first move may be a prototype if the uncertainty is whether people can scan, sort and understand task responsibility in a proposed interface. If the product depends on reliably drawing data from an existing system, a proof of concept could come first to establish whether the technical connection is feasible within the intended constraints. If the workflow and technical path are already sufficiently understood, an MVP might offer one shared approval queue, explicit owners, due dates and a completion state.
For that MVP, the team could define a product outcome as: can a designated operator find the next approval, assign it and see its completion status without returning to their previous manual tracker for that task? This does not prove broad demand, revenue potential or long-term retention. It gives the team a bounded way to assess whether the narrow workflow is becoming more useful.
- Problem: approval work is fragmented and ownership is unclear.
- First-release focus: one queue for one approval workflow, not a complete operations platform.
- Measure: whether the core approval path can be completed and whether the old workaround remains necessary for that path.
- Limit: the result would not by itself validate every team type, integration or future feature.
Limits, responsibilities and how to choose well
A studio can bring structure to discovery, design and delivery, but it cannot remove commercial, organisational or technical risk. Product outcomes are shaped by factors outside a build process: timing, distribution, internal adoption, data quality, procurement constraints, policy changes and competing priorities. Treat claims about product success with care, especially before a release has been used in its intended context.
Responsible automation deserves the same scrutiny as any other product choice. Automation may reduce repetitive effort, but it should have a clearly defined task, understandable inputs and outputs, appropriate review paths and a way to handle exceptions. Do not add automation merely because it appears modern. Ask what decision or action it supports, what happens when it is wrong, and who remains accountable.
When selecting a product development studio, look for a working approach that exposes decisions, boundaries and evidence needs. Ask how scope changes are handled, how accessibility is included, what constitutes a releasable increment and how the team will distinguish useful signals from unsupported conclusions. IVRYN’s published methodology and guide provide a public framing for focused product work, but they are not a substitute for assessing fit with a specific project.
- Ask for a proposed first decision, not only a proposed feature set.
- Confirm ownership of product decisions, content, data, operations and post-release support.
- Agree on what evidence would justify expanding, changing or stopping the work.
- Treat measurable outcomes as decision inputs, not guarantees of commercial success.
Frequently asked questions
What is a product development studio?
A product development studio is a team that helps shape and deliver digital products, often spanning product definition, design, engineering and iteration. Its exact role varies, so clarify whether it is supporting discovery, a prototype, technical feasibility work, an MVP or ongoing improvement.
Should I build a prototype, proof of concept or MVP first?
Choose based on the main uncertainty. Use a prototype to explore an interface or user flow, a proof of concept to check a critical technical approach, and an MVP to release a limited but usable core experience. More than one may be needed in sequence.
What can a product development studio not guarantee?
A product development studio cannot guarantee demand, adoption, revenue, technical certainty or long-term product success. It can help make assumptions explicit, define smaller releases and choose relevant product signals, while external conditions and product decisions still affect outcomes.
Sources and further reading
These resources provide the wider reference frame. Product statements on this page are limited to the public information provided by IVRYN.