Start with the problem, not the portfolio
A portfolio becomes repetitive when its products begin as variations on an internal preference: the same interface pattern, the same audience description, or the same feature list applied to different labels. A stronger starting point is a precise external problem. Who experiences it, in what situation, and what useful change should the product make possible? Those questions give each product a reason to exist before any visual or technical decisions are made.
For IVRYN, an independent product studio based in Paris, the portfolio includes Imryn, Datvero, Facet, Reef, Flare, Sealed, Crucible CLUB and Victor Laybats. Each has its own domain, audience and product page. That separation matters because a product should be shaped by the work people are trying to do, not by a need to make the studio catalogue feel uniform.
Problem clarity also makes exclusion easier. A team can say what the first release will not address, which users it is not for yet, and which adjacent requests belong elsewhere. This protects a focused product from becoming a broad studio platform in disguise.
- Write the user situation in one plain sentence.
- Name the smallest useful outcome before listing features.
- Record the important exclusions for the first release.
Treat standards as working agreements
Shared standards do not need to dictate a shared appearance. They can define how decisions are made instead. A studio may expect every product to state its problem clearly, test a small release, consider accessibility, and review measurable product outcomes. Those are operating commitments, not a visual template.
This distinction leaves room for products to differ where difference is useful. One audience may need a quiet, information-dense workflow; another may need a guided first step. One domain may reward direct language and short paths; another may require more context before an action. Consistency belongs in the discipline behind these choices, while the choices themselves should respond to the product’s audience.
Standards work best when they are concrete enough to use during planning and review. “Make it simple” is too vague to guide a release. “Can a first-time user understand the primary action without specialist knowledge?” gives a team a question it can inspect and improve.
- Use the same decision questions across products.
- Allow product-specific answers to those questions.
- Review standards at release points, not only in retrospectives.
Build small releases that reveal differences
A small, testable release is not merely a reduced version of a larger roadmap. It is a deliberate way to learn whether a particular product problem has been understood. The release should make one meaningful action possible and give the team a way to observe whether that action is useful.
This approach prevents false consistency. If every product launches with the same onboarding sequence, dashboard structure, or automation pattern, the studio may be copying its own habits instead of responding to evidence. Small releases create permission to choose a different path when the problem calls for one.
A useful release plan names the assumption being tested, the people it is intended to help, the moment of use, and the signal that will inform the next decision. The signal does not have to be elaborate. It might be completion of a core task, repeat use of a workflow, or feedback that identifies a point of confusion. The point is to connect shipping with learning rather than with presentation.
- State one primary user action for the release.
- Remove features that do not support that action.
- Decide in advance what observation will trigger a revision.
Make accessibility part of product judgment
Accessible interfaces are a shared standard that can still produce distinct products. Accessibility is not a style that makes every screen look alike; it is care for whether people can perceive, understand and operate what is in front of them. Clear labels, readable hierarchy, predictable interactions and sensible keyboard support can be adapted to many product contexts.
The practical benefit is that accessibility forces useful questions early. Is the purpose of this control obvious? Does color carry information that also needs another cue? Can a person recover from an error? Is the language understandable to the intended audience? These questions often improve the experience for everyone, while keeping the team focused on real use rather than decorative similarity.
For a small team, accessibility becomes manageable when it is included in normal product review. Check the core path before release, make the interface understandable without relying on hidden knowledge, and treat reported barriers as product work. This avoids turning accessibility into a late-stage checklist detached from the product’s purpose.
- Use direct labels for primary actions.
- Provide more than color to communicate status.
- Test the core journey with keyboard navigation and readable content.
Measure outcomes without flattening context
Measurable product outcomes give a studio a common way to judge whether work is useful, but the measures should follow the product rather than standardize it. A product designed to help someone complete a recurring task may need different indicators from one intended to support exploration, coordination or a one-time decision.
Choose measures that connect to the problem statement. If the intended outcome is a clearer handoff, look for evidence around the handoff rather than a broad activity count. If the intended outcome is successful completion of a task, focus on the path to completion and where it breaks down. Quantitative signals can be paired with direct observations and user feedback so that the team does not mistake motion for usefulness.
Responsible automation belongs in the same conversation. Automation should have a clear role, visible boundaries and a way for people to understand or correct its effect. It should reduce unnecessary work, not obscure important decisions. A shared expectation of responsible automation can guide every product while the actual degree and form of automation remain specific to its domain.
- Connect each measure to a stated user outcome.
- Review incomplete or confusing paths alongside successful ones.
- Explain what automated actions do and where people retain control.
Show the portfolio as a set of commitments
A studio site can make differences legible without forcing products into a single story. Give every product its own page, domain and audience description, then explain the studio’s shared commitments in a separate, concise layer. Visitors should be able to understand both: why this specific product exists and how the studio approaches building it.
The editorial task is to document work plainly. Describe how products are researched, designed, shipped and improved without inflating claims. Show the problem being addressed, the boundaries of the current product, and the practical choices behind a release. This is more useful to founders and operators than a portfolio of interchangeable slogans.
The result is a portfolio with a recognizable standard of care rather than a uniform surface. IVRYN can be coherent through problem clarity, small testable releases, accessible interfaces, measurable product outcomes and responsible automation, while each product remains accountable to its own audience and use case.
- Give each product a clear audience and product page.
- Keep studio principles separate from product-specific language.
- Update pages as the product’s scope and learning change.
Frequently asked questions
How can a product studio keep a consistent identity without identical design?
A product studio can share an identity through decision-making standards: clear problem definitions, small testable releases, accessible interfaces, measurable outcomes and responsible automation. Each product can then use different language, workflows and visual choices that fit its own audience and domain.
What should every product in a portfolio have in common?
Every product should have a clear purpose, a defined audience, an understandable core action, accessible interaction patterns and a way to evaluate whether it is helping users achieve a meaningful outcome. Those common foundations do not require the products to share the same features or visual style.
How do small releases help products stay distinct?
Small releases test a specific assumption about a specific user problem. Because each product learns from its own use case, the team can avoid copying a familiar feature set or interface pattern across the portfolio and instead improve the product based on what its audience needs.
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.