Like many of you, I keep track of how quickly AI tools are changing and how there is always something else worth trying. In my earlier Field Note, Keeping Scope Clear When Building Gets Faster, I shared a product delivery experiment where I was deliberate about keeping the scope focused. This observation takes a closer look at how I tested that scope.
Key user need:
- view several BIM models together,
- inspect properties,
- and make basic section cuts in a lightweight IFC viewer.
I used two projects to test the prototype across smaller and larger project scales. This would help establish proof of concept and provide enough evidence to begin testing with intended users. The larger test project loaded nine models and more than 8,000 visible elements into the viewer. At roughly 25,000 m², the mixed-use office complex gave me a different test from the 4,500 m² education building I had also used.
The core tasks stayed the same. Load the models together, inspect element properties, and make section cuts. I wanted to check whether the focused scope remained useful as the project became larger and more complex.
Before development, I translated the user need into an epic, then broke it into user stories with acceptance criteria that could be shared and discussed across teams. This is an approach I’ve used with larger digital products over the years. It gave me a clear basis for directing the build and checking the result.
The engineering phase, using agent-assisted development, shortened the time between defining that scope and having a prototype to test. I could move into reviewing actual model content sooner and check it directly against the acceptance criteria. What I could quickly see was that the viewer stayed responsive during the core review tasks, with three models loaded for the smaller building and nine for the larger complex. That gave me enough confidence to move into initial user testing without first expanding the scope.
During the initial testing, users reported that the current scope met their needs, with few requests for immediate changes. That was encouraging feedback for this release. It supported the original product assumption and brought me to the next question. How would the prototype perform when people used it to complete review tasks on their own projects?
In the next stage, I want to observe whether people in the intended user roles can complete those tasks independently, understand where they need guidance, and identify where the prototype falls short. Those observations would give a product team a basis for agreeing improvements and help shape training and onboarding playbooks so that Customer Success can respond to the difficulties we actually see.
Model filtering and targeted clash checks are the next additions I have in mind. But before extending the scope, I want clearer evidence of how users work with what is already there.
This experiment brought the familiar parts of product delivery closer together: defining a need, building to a focused scope, checking acceptance criteria, and gathering feedback.
The shorter build stage gives stakeholders earlier evidence for deciding where to focus next. My role is to organize that evidence and help turn it into an agreed next step.
I’m sure there’s much more that could be written here, but my goal is a relatively concise observation following the earlier Field Note, so I’ll leave it at this. If there’s something in particular you’d like to explore, drop me a note!