How we work
From how work runs today to software that runs it.
The method is the same for a website, an app or an ERP. Each stage produces something you can read and correct before we build on top of it.
Five stages
- 01Process map
Map the operation
See the work as it really happens.
- What we do
- We follow the process with the people who do it, including the workarounds, the exceptions and the parts that live in one person's head.
- What you get
- A process map that shows steps, owners, handoffs and the information each step needs.
- What it lets you decide
- Where the real problem is, before anyone proposes a solution.
- 02Domain model
Model the business
Decide what the system must know.
- What we do
- We define the records, the rules between them, the roles that act on them and the states they move through.
- What you get
- A domain model in plain language that your team can check against reality.
- What it lets you decide
- What is in scope, what is not, and what must always be true.
- 03Architecture and scope
Architect the product
Shape the system and its first release.
- What we do
- We turn the model into modules, screens, permissions and integrations, and choose what ships first.
- What you get
- A product architecture and a scoped first release.
- What it lets you decide
- What to build first, and what it depends on.
- 04Working release
Build the system
Working software, in short cycles.
- What we do
- We engineer the application, data and integrations in increments, each one usable in real work.
- What you get
- Running software your team can use, and documentation that explains how it is built.
- What it lets you decide
- Whether the system fits the work, judged by use instead of by slides.
- 05Change log
Iterate in use
Improve it from real usage.
- What we do
- We watch how the system is actually used, then change the model or the software where they diverge from the work.
- What you get
- A steady list of changes tied to observed use.
- What it lets you decide
- What to extend next, and what to leave alone.
Working principles
- 01
Start with one workflow that hurts
A single, real process beats a plan for the whole company. The rest grows from a system that already works.
- 02
Put software in use early
People understand a system by using it. A small release in real work teaches more than a long specification.
- 03
Documentation is part of the system
The model and the reasoning behind decisions are written down, so the system can be maintained by people who did not build it.
What we need from you
Little of it is technical.
- 01
Access to the people who do the work, not only those who manage it.
- 02
Real examples: the spreadsheets, forms, messages and documents used today.
- 03
One person with the authority to decide when the people who do the work disagree.