Matrix DNA
A B2B data collection and management platform. Success isn't how many forms get created, it's how much of the data comes in right and is ready for analysis.
Context
It's a web platform for building, distributing and managing modular forms, responses and structured data. On one side, data-entry users, often non-technical, who need to submit fast and simply. On the other, analysts and data owners who need consistent fields, correct permissions and analysable data.
When I joined, the product was a new pilot with very few users and a very negative reputation: an unstable MVP, low trust, workflows split across eight systems, and performance and UI problems, all while running in production.
Results
- active users
- 1,000+
- active users in 15 months
- ×12
- active data sources
- ×46
- MAU in the first 9 months
- ×11
| Active users | |
|---|---|
| Active data sources |
| Before | |
|---|---|
| After |
The North Star I set: the number of analysis events based on data from the system. It measures value, not activity. Secondary: managed sources, BI events, active users, new forms.
What I did
- Mapped user workflows, field research, prioritisation across several units
- Set up product analytics from scratch, and grew the team with design, customer success and analytics
- Vision, roadmap and KPIs; needs translated into epics and a backlog with acceptance criteria
- Daily work with engineering, QA/DevOps and design; moved the team to Kanban
- Steered an infrastructure refactor and stabilization while shipping, without stopping the business
- Turned a parallel platform from a competitor into an additional usage channel
Personas
| Persona | Job to be done | Design implication |
|---|---|---|
| Data entry | Submit an accurate report fast without knowing the data model | Simple form, clear fields, error states, fast entry |
| Form owner | Maintain structure and sharing, keep quality | Form builder, permissions, responses, views |
| Analyst | Pull uniform, reliable data for analysis | Consistent schema, integrations, export, sync |
| Admin | Manage access and change without hurting users | RBAC, soft delete, audit, exceptions |
Product decisions
A six-role permission model
Full control, manage responses, manage without delete, read only, create only, and my responses. Conflict rule: when permissions come from several sources, the highest wins. Hiding a button alone is not a security mechanism.
Excel import: all or nothing
XLSX only, up to 1MB, exact column names and order. Any error blocks the whole import, so you never end up with half the data in. Errors are grouped by field and type so users can make sense of hundreds at a glance.
Quick Edit in the responses table
A spreadsheet-like feel with Tab / Shift+Tab, without turning the product into Excel. Only changed cells are validated, and system fields stay locked.
The hard problem isn’t adding options to a form builder, it’s getting a person in the field to supply reliable data, again and again.
Timeline
| When | Topic | Insight |
|---|---|---|
| 2025 | Stabilization, UX, permissions, adoption | From a technical persona to usable data entry |
| Early 2026 | Infrastructure refactor and a major release | An outage during the refactor, and lessons on rollout and monitoring |
| May–Jun 2026 | Excel import, Quick Edit, form-in-form, colour rules | Detailed specs and UX reviews |
| Jul 2026 | A Data Lake sync bug | Focus on data reliability, retries and status feedback |
| Sep–Oct 2026 | Table column widths, a new-feature popup | QA sign-off and releases |
What I learned
- Separate two kinds of value: UX for data entry, and data quality and availability for analysts. It prevents optimising for one side.
- In a system of rules and permissions, a good spec covers the edge cases: permission clashes, partial errors, deletions, schema changes.
- Stability is a feature. Refactors and wide changes need rollout, monitoring and rollback.