The problem: Low adoption under growing investor pressure
Telecom antenna construction depends on building plans. Most are wrong. When measurements fail, everything downstream breaks. Teams arrive on-site with custom-built pieces that do not fit. Redesign. Re-manufacture. Delays. Millions in costs.
Acernis was built to prevent that. A 3D scanning tool designed to quickly capture accurate, up-to-date building plans during the first technical visit. Adoption did not follow.
Features kept shipping. There was no clear understanding of who the product was for or why the active users stayed. The roadmap was shaped by what was technically possible, not by what users actually needed on a construction site.
At the same time, investor pressure was increasing. I was brought in to answer one question: Why does this work for 10% of users and fail for the rest?
This wasn't a redesign but a search for product-market fit, with a shrinking runway.
The insight: The product was misaligned with how and where the work happens
Two observations reframed the problem.
Telecom construction is not one workflow
A complex site on a historic building has nothing in common with a simple equipment swap. Constraints change. Budget, timeline, team size, time on-site. Treating them as one use case made the product irrelevant for most situations.
The tool had two contexts: Field and office
On-site work is fast and constrained. Office work is analytical and collaborative. Analyze results, export plans, share documents, and move the planning and construction process forward. The product focused on the second step, and neglected the needs of users collecting data in the field.
These two insights shaped every decision that followed.
The process: Breaking the product into distinct use cases and testing directions
"Active user" was hiding the problem
The first interviews made one thing clear. "Active user" was a useless category.
Someone logging in to download a PDF is not the same as someone spending 45 minutes inside a 3D visit comparing scan data against construction plans. Two completely different behaviors, one label.
The metric was not wrong. It was flattening everything.
So I reframed the problem.
Active doing what? For which type of project? At which stage of the construction process?
Mapping the full lifecycle exposed the gap.
At that point, the priority was not to improve the product. It was to define what product we were building, and how it should be structured.
The product was designed for the wrong environment
The product assumed phone usage in the field.
In reality, teams rely on tablets during technical visits. On-site work is constrained. Data needs to be captured and annotated quickly. Phones are not used. The screen is not large enough for this type of work under time pressure.
Back in the office, work shifts. Analysis, export, coordination on desktop.
Two environments. Two types of work. Two devices and one was wrong.
Three directions. Two failed immediately
We tested three product directions. Each combined existing features with different hardware, pricing, and project types. Two failed quickly.
- A remote pre-visit offer. Meant to reduce time pressure during site visits. Users compared it to Google Earth. No value. Interest only appeared when testing precise measurements such as building height or roof tilt.
- A model where site visits were delegated to external operators for simpler projects. No trust.
- One direction held attention. A lighter and more portable scanning setup. Useful for mid-complexity sites. Faster to capture. Easier to handle.
Not every project needs the same level of precision.
The product needed to adapt to different levels of complexity. We restructured the offer into distinct tiers, aligned with different project types.
Several features did not hold up
Some existing features had no clear use case. Others failed as soon as they were tested.
- Auto-sorting and AI search sounded useful, but broke how teams actually work. Users rely on photo chronology to reconstruct a visit. Auto-sorting removed that context.
- Image compression reduced file size, but removed the level of detail planners need when zooming.
At the same time, simple ideas identified early solved real problems with minimal effort. Secure sharing with external teams became the priority.
This clarified the direction. Several planned features were deprioritised.
The outcome: From one product to structured use cases and clearer product direction
The product direction was shifting, but we did not reach implementation. The main investor pulled back before an MVP could be built.
What changed regardless:
A product strategy where there was none
The team moved from one product to a clearer structure of use cases. Different project types. Different needs. Different levels of precision.
Feature decisions became grounded in observed workflows, not assumptions. Several features were deprioritised after testing showed they did not match real workflows.
From tool to system
From a single tool used by a small group of active users to a system designed for both contributors and external viewers, depending on role and stage in the project.
A viewer seat, with protected document access and no account required, became a clear value candidate.
The reflection: The right direction came too late to act on it
I wish they had hired me earlier.
Acernis brought me in when they were already behind schedule with investors. We compressed months of discovery into weeks. The direction became clear, but there was no time left to act on it.
If I could change one thing, it would be timing. By the time the right questions were asked, most of the cost had already been incurred. Features had been built. Users had not stayed. Investors were losing patience.
This project reinforced something I carry into every engagement. Utility and technical effort cannot be treated separately. The product suffers when they are.
