Capabilities

What we do, and why.

Seven disciplines the studio brings to every venture it builds, organised by the four concepts. Each starts from a problem rather than a deliverable.

C.01

Product strategy & discovery

The problem
Teams start building before they know which problem they are solving, for whom, and why now.
The work
Observing how the work is done today, talking to the people who do it, mapping the workflow and the market around it, and defining the problem precisely enough to build against — or to decide not to.
What it produces
  • Problem definition
  • Workflow and market maps
  • Product concept and scope
  • A build / don’t-build recommendation
Where it fits
The first two steps of the approach — Observe and Define — and the heart of Genesis.
Related work
wheneuSortOut
C.02

UX & interface design

The problem
Software shaped like the organisation chart instead of the task: too many screens, unclear states, the important number buried.
The work
Information architecture, interaction design and interface systems built around the real sequence of a task, on the devices people actually use — including the phone in someone’s hand at a front desk.
What it produces
  • Information architecture
  • Interaction flows
  • Interface design system
  • Responsive layouts
  • Accessibility review
Where it fits
The Design step. Interfaces are tested against the problem definition, not against taste.
Related work
wheneuSortOut
C.03

Web application engineering

The problem
Prototypes that cannot carry real data, real users, or a second year of changes.
The work
Data models and permissions designed first; server-rendered web applications built on them; integrations with the services a product depends on; deployment on infrastructure that is dull in the right ways.
What it produces
  • Architecture and data model
  • Production web application
  • Roles and permissions
  • Integrations
  • Deployment and monitoring
Where it fits
The Build step, and the architectural half of Allocation.
C.04

Digital product development

The problem
Products stall in the hand-offs between strategy, design and engineering.
The work
One team carrying a product from concept through design, build and launch into its first cycles of iteration, with the same people accountable at each step.
What it produces
  • Roadmap and release plan
  • A launched product
  • Post-launch iteration cycles
Where it fits
All five steps of the approach, end to end.
Related work
wheneuSortOut
C.05

Business & operational systems

The problem
Businesses that run on registers, spreadsheets and chat groups — where the information exists, but nobody can see all of it at once.
The work
Mapping how a business actually operates, then designing the records, internal tools, workflows and roles that make its current state visible to everyone who needs it.
What it produces
  • Operational map
  • Internal tools and dashboards
  • Process and role design
  • Migration from existing records
Where it fits
Operations, applied to a business rather than a single product.
Related work
wheneuSortOut
C.06

Automation & AI-enabled workflows

The problem
Repetitive work — follow-ups, reconciliation, data entry — consuming the people who should be making judgement calls.
The work
Separating the steps that are rules from the steps that are judgement; automating the rules, and using language models only where they measurably help, with a person accountable for each outcome.
What it produces
  • Workflow audit
  • Automations and integrations
  • AI-assisted tools with human review
  • A plan for measuring the effect
Where it fits
Where Operations meets Theory: every automation starts as a hypothesis about time saved.
Related work
wheneuSortOut
C.07

Experimentation & prototyping

The problem
Large bets placed on untested assumptions.
The work
Turning beliefs about a product into explicit hypotheses, and answering each with the smallest thing that can: a clickable prototype, a manual pilot, a single working feature.
What it produces
  • Hypothesis log
  • Prototypes
  • Test plan and results
  • A recommendation
Where it fits
Theory in practice. It runs alongside every other capability.

—Framework

The four concepts behind the list.

II

Operations

How will it run on an ordinary day?

A product is only as good as the operation behind it. Operations is the design of what happens after launch: the records, workflows, roles and tools that let a business see its own current state.

  • Workflow design
  • Internal tools
  • Roles and permissions
  • Automation
Related work
wheneuSortOut

Next

Think something should exist?

Write to the studioSee the ventures