Case study
B2B product architecture, rollout, and customer-driven iteration
This project started from a business integration problem, not from a feature brief. The company was partnering with some property businesses and acquiring others, but the existing systems were old, fragmented, and hard to scale. I worked as the early product manager and UX lead to turn those scattered business signals into one connected B2B system: a property SaaS backend linked with employee and owner apps, AI monitoring workflows, and device software. The first phase was designed to validate the model through pilot use in roughly three property companies before scaling nationally — the platform eventually launched across 6,000+ property enterprises. My work focused on requirement discovery, architecture definition, rollout support, and feedback-driven iteration across real property customers.
The company was in an active expansion phase — simultaneously partnering with external property businesses and acquiring others. Each incoming business brought its own legacy workflows, fragmented software, and disconnected operational data. There was no shared platform, no unified view of operations, and no consistent way to manage work orders, property data, or resident services across communities.
What made the situation more complex was that the company already had meaningful technical assets in place. The hardware division had developed its own access-control and central-control devices, already deployed across multiple communities. There was also an established AI-based smart alarm capability — an intelligent alert system that could detect risk events such as fire-lane blockages, restricted-area intrusions, and abnormal gatherings from live camera feeds. But these components were entirely disconnected. The hardware ran its own device software. The AI alert system operated independently. Property teams were managing physical devices, AI-generated alerts, and day-to-day workflows through separate channels with no integration between them.
The product challenge was not to build a standalone SaaS tool in isolation. It was to unify an existing hardware estate, an existing AI capability, and the operational needs of multiple newly merged property businesses into one coherent, scalable platform — while keeping the first release focused enough to pilot across roughly three property companies and validate the architecture before national rollout.
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.
The SaaS backend was positioned as the centre of the system, with connected employee, resident, AI, and device-side products around it.
I defined how managers, staff, residents, and connected devices linked back to the SaaS platform through the right product modules and information structure.
I converted research findings into requirement groups, release priorities, and functional boundaries for the first phase.
I produced wireframes for management screens, work-order flows, and connected interactions so the team could align quickly.
I worked across teams to keep implementation aligned with the architecture, the PRD, and the pilot requirements.
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.
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.
During my tenure
Platform-level scale (post-launch)
Platform-level figures are sourced from public smart-community solution materials published by AIForward.
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.
How projects like this changed my assumptions about PM work, ambiguity, and what good product judgment actually requires in complex B2B environments.
These public references show the company and smart-community solution area connected to the project.