The Method
Section 03
Understand it, then change it | in that order.
Our process isn't complicated, but it is deliberate. Each step exists to keep us honest about the problem before we spend your money on a solution.
- Phases
- Five, in sequence
- Working style
- Alongside the people doing the job
- After launch
- We stay involved
The procedure
Listen & observe
Fig. 01
We start with the people doing the work, not the org chart. What does a normal day look like, and where does it stall? Nothing gets proposed in this phase.
- What happens
- Time on-site or on a call with the people who touch the process daily, watching, asking, taking notes on what actually happens rather than what's supposed to happen.
- What you get
- A plain written account of the current process, in the language your team already uses for it.
- What we need from you
- Access to the people doing the work and permission to watch a normal day, not a showcase day.
Map the work
Fig. 02
We draw the workflow as it truly runs, including the shortcuts and the steps that live in someone's memory. Seeing it on one page changes the conversation.
- What happens
- The scattered observations become one map: every handoff, every workaround, every place where information gets re-entered or lost.
- What you get
- A single-page map of the real workflow, reviewed with your team until everyone agrees it's accurate.
- What we need from you
- A short review session to correct anything we got wrong or missed.
Design the right fix
Fig. 03
We choose the smallest change that removes the most friction, and we say plainly what it will and won't solve. Sometimes that means using what you already own.
- What happens
- We weigh options against the map, configuring what exists, cutting a step, or building something narrow and specific, and pick the one that costs the least to maintain.
- What you get
- A plain-language plan: what changes, what stays, what it costs, and what it won't fix.
- What we need from you
- A decision on the plan, and any constraints we should know about, budget, timeline, systems that can't move.
Build & test
Fig. 04
We build in short passes and put it in front of real users early, with real data. Feedback while it's still cheap to change is the whole point.
- What happens
- Short build cycles, each one shown to actual users with actual data before the next cycle starts.
- What you get
- A working version, tested by the people who'll use it, not just by us.
- What we need from you
- Someone on your side who can try it and tell us honestly what's confusing or wrong.
Refine in the real world
Fig. 05
Launch is the midpoint. We watch how it holds up under a busy week, fix the rough edges, and adjust as the work changes.
- What happens
- We watch the first real cycles of use, fix what only shows up under real conditions, and document what a person on your team needs to own going forward.
- What you get
- A tool that runs on its own, with rough edges sanded off and ownership handed over clearly.
- What we need from you
- A little patience during the first busy week, and word when something isn't holding up.
What we hold to
A few commitments
Built with the people doing the work
The person who runs the process daily knows more about it than anyone in a planning meeting. They're part of the design, not just the rollout.
Small useful wins first
We'd rather relieve one real pain in a few weeks than disappear for six months chasing a grand plan.
Accountable after launch
We stay involved long enough to see whether it actually stuck. If it didn't, that's ours to fix.
Launch isn't the finish line. It's the point where the real feedback starts.
Curious where your work gets stuck?
Point us at the part of the day that always runs late. We'll take it from there.