The Inspection Configurator
InsideMaps Inc. · Product Manager
From hand-coded JSON to a self-serve tool — 23.89% reduction in client wait time per configuration change.
ROLE
Product Manager
TIMEFRAME
2023–2024
STATUS
Live in production
METHODS
AS-IS mapping · UX flows · Benefit framing
Background
In mid-2023 at InsideMaps, I started mapping a process that was supposed to be straightforward and found a small disaster. Every time one of our enterprise clients wanted to change how their property inspections were configured — adding a question, tweaking a section, switching a package type — the request came to my desk, sat in a queue, and eventually surfaced in a JSON file I would edit by hand. Five or six days later, after clarifying rounds and a test cycle, the change would ship.
I watched over twenty of these go by in six months and realised the problem wasn't the process. There was no product.
“The thing I was working on wasn't a configuration request. It was the absence of a product that should have been there.”
The Setting
InsideMaps sends inspectors into a property to capture 360° spatial context alongside structured answers to a questionnaire — what's broken, what's missing, what needs work — all stitched onto a walkable 3D model. Each enterprise client uses a custom inspection “package”: a configuration that defines exactly what gets asked, where, at every level of the home.
Until the Configurator existed, that config lived in JSON — hand-edited by the product team every single time a client asked for a change. A package also drives downstream workflows that touch scheduling, inspection, scope review, approval, project coordination, customer support, and operations. A slow config loop isn't a one-team problem.
The Problem
The deeper problem wasn't the duration — it was the loops. Ad-hoc tweaks during build, errors caught in QA, errors caught by the client in testing, post-delivery modification requests. Every single one of those loops travelled back through one step — manually editing JSON — performed by one team.
When the same step appears in every loop, that step is a missing product.
Manual JSON editing wasn't a quirk of the process. It was the gravitational centre of the entire lifecycle. The product team had been acting as the configurator, by hand, for years.
Mapping the AS-IS Lifecycle
Before designing anything, I mapped the current end-to-end config lifecycle on a FigJam — partly to brief stakeholders, mostly to test my own intuition. The map made one thing impossible to argue with.
Figure 1 — The AS-IS inspection configuration lifecycle. The "Manually edit JSON" node is the destination of every feedback loop.
Hidden Complexity: The Data Model
Before sketching a flow, I needed to understand why DIY config had stayed hard for so long. The honest answer wasn't user inability. The underlying data model is genuinely deep.
A package isn't a flat questionnaire. It's a five-level hierarchy with question groups attachable at every level — and Room additionally holding Spins, Tasks, and Assets. That depth is what made hand-edited JSON tolerable, and what made “just expose a form” the wrong answer.
Figure 2 — The inspection package data model. Five hierarchy levels, with question groups attachable at each, plus Spins / Tasks / Assets inside every Room.
The First Attempt — and Why I Threw It Away
My first UX flow was functional. It was also wrong. The flow was straightforward — nothing was structurally broken. What was broken was the framing.
The whole flow was organised around the noun Package — the same word the product team had used internally for years. But that's not how a client thinks. A client doesn't open the tool to manage “a package.” A client opens the tool to change what an inspector should ask about. The unit of thought is the questionnaire. The clean UI was sitting on top of the wrong mental model.
SIDE PANELS OFF DASHBOARD:
ROLE MODEL:
Discarded: Flow was organised around the noun Package — the team's internal artefact, not the client's unit of work. A client doesn't open the tool to manage "a package." They open it to change what an inspector should ask.
Figure 3 — The discarded initial flow. Built around the existing Packages framing — clean enough, but mirroring the old data structure too literally.
The Reframe — From Packages to Questionnaires
The second flow centres on Questionnaires and on one specific UX move: the unlock pattern. The entry point is the Organisation Portal. The flow follows the work, not the data shape.
The piece that took the longest to land was how to handle defaults. Most products resolve this badly — either defaults are too rigid or autonomy is too open. The unlock pattern is the compromise: defaults stay clean and governed, autonomy stays available and auditable. One click. One fork. Every divergence logged.
INSIDE A QUESTIONNAIRE
THE UNLOCK PATTERN
Platform-curated. Visible and usable, but not editable. Stays clean across all clients.
(1 click · logged)
Fully editable instance owned by the client. Default is untouched. Divergence is attributable and reversible.
The lock isn't a barrier — it's a fork point. One click converts a governed default into a client-owned copy. Every divergence is logged, attributable, and reversible.
ROLE-AWARE ACCESS:
Full self-service access
Read-only oversight
Full platform control
Figure 4 — The adopted Configurator flow. Centred on Questionnaires, with an unlock pattern that converts governed defaults into client-owned custom groups.
Why One Config Change Matters
A single config change ripples across a multi-team downstream workflow at the client — scheduling, capture, scope review, sign-off, project coordination, customer support, and operations. The Configurator's value isn't only the product team's days back. It's that everyone downstream gets clean, current packages with less friction.
What Shipped & Measured Impact
The release was deliberately tight — enough to remove the product team from the cycle for everyday config changes. What shipped: role-aware login, organisation and package navigation, the configuration dashboard, edit and create flows, full activity log, project- and room-level questions, scanner notes, package settings, and both package types (Scan-less and Scanning).
On the gap between target and outcome
The original PRD target was 35%. We landed at 23.89%, and I want to be honest about that gap rather than dress it up.
Adoption curve on complex changes
The most complex changes — touching unusual structure levels or spanning multiple question groups — still occasionally route through the manual path while clients learn the tool's full surface. That'll narrow as familiarity builds.
Deliberate friction in the unlock pattern
The unlock-to-customise step adds one explicit click that an unconstrained editor wouldn't have. That click is a feature, not a bug: every divergence from the curated defaults is now logged, attributable, and reversible. I'd make the same trade again.
“35% was the headline number on a slide. 23.89% is what the system actually does in the world, with real clients, real change requests, and the audit trail intact. I'd rather report the second number honestly than chase the first.”
Reflection
Map the AS-IS before you design the to-be.
The lifecycle diagram did more strategic work than any feature list. It made the bottleneck visible in a way a spreadsheet couldn't. Most of the strongest product decisions I make now come from spending a deliberate afternoon mapping the current path on a wall before I let myself sketch a screen.
If the same step appears in every loop, that step is a product.
Manual JSON editing wasn't a quirk of the process — it was a missing tool. The shape of the diagram told me what to build before I'd written a single feature spec.
Throw away the first flow on purpose.
The discarded Packages model wasn't a failure — it was the cheapest way to see what the right flow had to fix. I now treat the first flow as a question, not an answer.
Match the noun to the user's mental model.
Internal nouns are convenient for the team; user-facing nouns should match the work the user is actually doing. Reframing from Packages to Questionnaires changed the entire UX downstream, and almost nothing else needed to move.
Design for governance and autonomy at the same time.
The unlock pattern is the move I'll reach for again. Defaults stay clean and supportable; autonomy stays available and auditable. The cost of using it is a single extra click; the benefit is a platform that can scale without quietly fragmenting.
Target high, report what actually happened.
The 35% target became a 23.89% measured outcome. The discipline that matters is reporting what the system does in the world, understanding why the gap exists, and using the delta to point at the next thing to fix.
Always include the downstream.
A change that looks like five days saved on one team is often a week of cumulative time across many teams. Designing the local fix without the systemic context risks declaring victory on the wrong metric.