From how work runs today to software that runs it.
The method is the same for a custom system and for our own products. Each stage produces something you can read and correct before we build on top of it.
Five stages
Map the operation
See the work as it really happens.
Process map
Model the business
Decide what the system must know.
Domain model
Architect the product
Shape the system and its first release.
Architecture and scope
Build the system
Working software, in short cycles.
Working release
Iterate in use
Improve it from real usage.
Change log
Five stages
Map the operation
See the work as it really happens.
- Business operations
- Product thinking
- Software engineering
- 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.
Model the business
Decide what the system must know.
- Business operations
- Product thinking
- Software engineering
- 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.
Architect the product
Shape the system and its first release.
- Business operations
- Product thinking
- Software engineering
- 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.
Build the system
Working software, in short cycles.
- Business operations
- Product thinking
- Software engineering
- 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.
Iterate in use
Improve it from real usage.
- Business operations
- Product thinking
- Software engineering
- 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
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.Put software in use early
People understand a system by using it. A small release in real work teaches more than a long specification.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.
Access to the people who do the work, not only those who manage it.
Real examples: the spreadsheets, forms, messages and documents used today.
One person with the authority to decide when the people who do the work disagree.