Validating a smart-building integration product before engineering build
MyMSI was a new product concept for Master System Integrators—the specialists who connect systems such as HVAC, lighting and boilers before buildings enter normal operation. The team needed to make an unfamiliar, multi-role workflow tangible enough to demonstrate to prospects and precise enough to inform engineering decisions. This was a 0→1 product challenge, not a redesign of an established system.
Choosing validation before implementation
I worked with a small cross-functional team comprising a cofounder, an integration engineer, a backend engineer and the Product Manager. After clarifying initial requirements and developing wireframes, we faced a practical constraint: an engineering-built MVP was estimated to take at least a month, with further iterations likely before the full experience could be demonstrated.
I proposed building a disposable functional prototype in Axure RP. The purpose was to explore the intended behaviors, reveal gaps and make the product demonstrable before committing comparable engineering capacity—not to replace production development. I took ownership of designing and building the prototype, using the initial requirements as a starting point rather than treating them as a complete specification.
Simulating an end-to-end, cross-role product
In approximately two weeks, I developed an interactive journey covering customer and building setup, floors, vendors and devices, integration work orders, assignment, status tracking, testing and completion. The prototype represented both the integration engineer’s tasks and the building owner or operator’s view of progress, so the team could examine handoffs rather than isolated screens.
Using Axure’s dynamic data capabilities, I made records persist during a session and update across the two role-based views. Creating a building or work order, changing a status or completing an integration step could be reflected elsewhere in the experience. This made workflow dependencies tangible in a way static mockups could not. The behavior was simulated within the prototype; it was not a connected production backend or a live multi-user service.
Turning prototype into a shared reference
The integration engineer used the prototype in demonstrations with prospective customers. Internally, it served as a functional reference for engineers implementing the product, giving the team a concrete model of intended journeys, states and interactions. From my recollection, the build required only minor adjustments to the prototype’s UI and requirements; that observation is not a measured reduction in engineering effort.
MyMSI later secured its first customer, but I cannot attribute that sale to the prototype. The defensible outcome is that the team had a realistic end-to-end experience in roughly two weeks for demonstrations, feedback and implementation planning, rather than waiting for an initial engineering MVP estimated at a month or more. The prototype reduced ambiguity about what to build without being presented as production-ready software.
Impact: a tangible 0→1 product concept ahead of engineering implementation; simulated cross-role workflows and shared state changes; and a functional reference for product discussions and development. No quantified time savings or causal commercial uplift are claimed.
