Smart Community SaaS System

The project was often easier to describe from the AI side, but the real product centre was the property SaaS system. I framed it as a property-management SaaS product that could unify core business data, daily execution, resident-facing services, and connected smart-community software.

I defined the solution as one connected product architecture with the SaaS backend at the centre. The property SaaS system handled property basic-data configuration, the workbench, customer management, vehicle management, and device management; the staff app supported execution-side tasks; the owner app supported resident-facing services; the AI Cloud Eye console handled monitoring and alert workflows; and the access-control and central-control software connected physical operations back into the platform.

The key product move was to stop treating these surfaces as separate requests. I treated them as one operating system for property organisations, so architecture decisions, release priorities, and workflow logic could be made at the system level rather than feature by feature.

The project started when the company began partnering with some property companies and acquiring others, creating a clear need for one unified property SaaS system and connected software stack. The first phase was designed to standardise operations across those partner and acquired businesses, then validate the model through pilot use in about three property companies before scaling it as a broader SaaS offering.

I aligned the work around three levels of goals: business integration after partnership or acquisition, a repeatable first-phase product structure for rollout, and clearer day-to-day workflows for managers, staff, and residents. That framing helped me turn field signals into phased priorities instead of treating every request as equally urgent.

This mattered because the project was not trying to win as a single AI dashboard or a single app. It was trying to create a usable first-phase SaaS product foundation that could connect operations, devices, AI, and service workflows under one shared structure.

This was a real B2B product environment, so I could not treat "the user" as one generic audience. I broke the problem down across business buyers, property managers, frontline staff, residents, and the internal teams responsible for software, hardware, and AI delivery.

My research approach combined stakeholder interviews, field visits, contextual observation, questionnaires, and requirement synthesis. The point was not simply to collect requests. It was to understand which needs were structural, which were local, which affected rollout, and which should shape the first release of the SaaS product.

My first responsibility was to make the business and user landscape legible. In the early phase I handled business communication, requirement discovery, and field research with different stakeholders so the product architecture would be grounded in real operating needs rather than assumptions.

Because this was a real B2B rollout project, I did not treat all users as one group. I segmented management-side buyers, property managers, frontline staff, residents, and operating stakeholders, then used field visits, observation, interviews, and questionnaires to understand what data had to be standardised first, where execution was breaking down, and how apps, alerts, and device workflows should connect back into the SaaS platform.

This phase was also where product thinking mattered most. The challenge was not to capture every request, but to translate fragmented field feedback into a coherent product structure: what needed to be standardised first, what belonged in the backend, what belonged in app surfaces, and what should remain part of later phases.

Once the requirements were clearer, I translated them into the initial SaaS architecture and the cross-role service loop. This made the solution easier to explain internally and easier to prioritise as a system rather than as disconnected feature lists.

The architecture covered property basic-data configuration, the workbench, customer management, vehicle management, device management, resident-side connections, staff-side connections, access-control coordination, central-control support, and risk-response coordination. I turned these into product architecture, requirement structures, PRD documents, and Sketch wireframes so design, engineering, and QA could move with shared clarity around the SaaS platform.

In other words, the work moved from requirement discovery into system design. My job was to make the platform legible: what the core product was, how the roles connected, where data and actions should live, and how the first release could stay coherent while still supporting later expansion.

The product strategy was phased rather than all-at-once. I prioritised a usable first-phase SaaS foundation that could standardise core business data, support management visibility, and connect the most important staff-side and resident-side workflows. That made it possible to validate the architecture in real property environments before expanding the system.

I used the business context to guide product priorities: first unify the core structure across partner and acquired property companies, then validate the operating model through pilot rollout, and only then support broader SaaS scaling. This helped avoid feature sprawl and kept the first release grounded in repeatable operational value.

AI Cloud Eye was an important supporting capability inside the full solution, and the product value went beyond simple alarm display. According to the public AIForward Yunyan product framing, the platform combined AI scene applications, remote quality management, and a data cockpit to help property teams manage both community-governance service scenarios and risk-recognition scenarios.

That meant the product design had to balance speed and reliability. I treated alert lists, map views, tracing logic, evidence capture, and follow-up handling as part of one operational workflow, then connected them back to the people and systems responsible for action. The system needed to support high-frequency property scenarios such as fire-lane occupancy, e-bike-in-lift alerts, restricted-area alerts, abnormal gathering, illegal waste disposal, shared-area clutter, abnormal loitering, staff on-duty checks, and pet-leash compliance.

I also drove the fast-iteration loop after the initial release cycle. Instead of treating the PRD handoff as the end of product work, I kept collecting stakeholder feedback, user comments, and operational questions to identify where the architecture or flows still felt heavy or unclear.

Typical iteration themes included improving task-entry speed, making data views more readable, reducing the number of steps needed for review, clarifying mobile notifications, and making dashboards more useful for different business modules. This is where product management and UX judgment needed to work together closely.

The rollout stage was also where the B2B loop became most visible. I was not only refining screens. I was helping the product become more usable in the real context through training, field feedback, and iterative clarification of what actually worked for customer teams.

Product work on this project did not stop at architecture and PRD delivery. Because the system was being introduced into real property environments, rollout support mattered. I supported customer-side understanding through training and helped reduce usage friction by clarifying how the system should be used in practice.

This stage was important because it exposed the difference between a theoretically complete product and a product people could actually use. It also gave me a second layer of insight into which design decisions improved adoption and which still needed simplification.

The project delivered measurable commercial and operational value in a real smart-community setting. It improved day-to-day efficiency for property operations, supported labour-cost reduction, and created a stronger basis for SaaS rollout across partner and acquired property companies.

I approached this project as a structured B2B product problem rather than as a bundle of software requests.

I used stakeholder interviews and field observation to understand how management needs, frontline execution, resident services, and device workflows connected in practice.

I used role-based requirement discovery to avoid flattening everyone into the same user type, because each group needed different workflows, visibility, and interactions.

I used product architecture and phased prioritisation to keep the first release coherent, usable, and scalable for later rollout.

I treated rollout, training, and feedback loops as part of product work, because adoption in a B2B environment depends on what happens after the first release as much as on what is defined before it.

One of the biggest lessons in this project was that B2B complexity cannot be solved by feature accumulation. Early on, it was easy for requests from different roles, pilot customers, and internal teams to pull the product in too many directions at once.

I learned that the more complex the environment is, the more important it is to protect the first product structure. That meant making harder prioritisation calls, separating structural needs from local requests, and treating rollout feedback as evidence to refine the architecture instead of reopening everything every time.

This project strengthened my belief that product clarity matters more than feature volume, especially when operations, apps, devices, and AI workflows all have to work together.