When I was living in Tokyo 🇯🇵 in mid-2023, I applied for a Lead Architect position at Woven City, a green technology subsidiary of Toyota. This was my submission to the product challenge step of their interview process. The goal was to build a 4-6 page Product Requirements Document (PRD) to assess my product development skills, thinking, and shape it to practical product architecture with a fluid green problem.

Interweave: Woven City Accelerator Hub

Attracting smart city inventors from around the world into a community of like-minded innovators to share, learn, and connect with residents

Background

Interweave is a new integration platform from Woven built to support a growing inventor accelerator program. The ecosystem is designed to capture the imagination and evoke a sense of excitement and possibility, while also transparently creating value through cutting-edge technology and ideas.

🏁 This Product Requirements Document (PRD) will define the customer, including problem alignment and value proposition, then jump into requirements, architecture, a few technical challenges, and a roadmap with estimated resources required to achieve the vision

Customer

Interweave customers are inventors, investors, and entrepreneurs who are interested in developing and commercializing smart city solutions. The target market encompasses individuals and organizations who have the skills and resources to create solutions that can address the city's most pressing challenges.

Problem Alignment

📣 The mission of Woven is “Building the Future Fabric of Life in a City as a Test Course for Mobility” where people actually live, test and invent new services and systemstogether with residentsin a wide range of mobility areas.

The Woven vision requires a robust and trustworthy platform to underpin the city's core engine accelerator program. The platform must be designed to support a sustainable ecosystem that encourages inventors to create and share innovative solutions to the city's challenges. At the same time, the platform must provide transparency into the innovation process by promoting public trust and support for smart city initiatives. Former smart city projects have come under heavy scrutiny and subsequently failed amid concerns over privacy and data harvesting:

We need to gather data to create a green, tech-forward utopia that can provide comprehensive environmental and community benefits to residents -- and yet, those residents must be able to trust the intentions driving such surveillance enough to allow the project to proceed. Without trust, sustainable communities will never come to fruition. From the get-go, project leaders need to address trust and transparency. They must adopt a near-nonprofit perspective that prioritizes social gain over profits to avoid accusations of corporate greed, and involve advocacy groups in their decision-making processes. Residents must understand how their data will be used, who has access to it, and what they can do to maintain their privacy in a space where data collection is a necessity. It seems an obvious truth, but it bears saying: when you build a smart city, you need to think as much about the residents as you do about the technology that owers it. — Bennat Berger<br> Sidewalk Labs’ Failure and the Future of Smart Cities Words

📣 Past efforts have lacked tools for collaboration, data sharing, and project management to facilitatecommunication between inventors, residents, and city governments

Sidewalk Labs, which won a competition to design a futuristic neighborhood at Quayside on [Toronto’s] eastern waterfront in October 2017, made very little about its plans public. Leaked presentations raised questions about the transparency of the waterfront planning process as it appeared Google’s sister company was already having talks with public officials about lands beyond what they’d been publicly invited to plan for. What started out as excitement when Google was selected to develop a master plan for the former industrial lands erupted into controversy, when a slew of consultants and advisory board members resigned in quick succession, citing concerns over how personal data would be collected and used, as well as the secrecy surrounding the project. — Marco Chown Oved <br>Google’s Sidewalk Labs plans massive expansion to waterfront vision

Value Proposition

📣 Interweave aims to remedy the mistakes of previous tech-focused smart city projects by promoting atransparency culturethat benefits both the city and its residents.

The accelerator program, built atop the Interweave platform, will provide a myriad of benefits to customers, including:

• [x] Access to Cutting-Edge Technology and Infrastructure: provide inventors with access to cutting-edge technology and infrastructure to develop and test their solutions
• [x] Secure Data Transparency: enforce prebuilt connectors, pipelines, and dashboards for inventors’ solutions to easily obey resident preferences for data collection, de-identify public space data at the point of collection, and surface collected data for resident review
• [x] Mentorship and Support: provide inventors with mentorship and support from experienced professionals who will help them navigate the challenges of developing and commercializing their solutions
• [x] Funding and Resources: provide funding and resources to help inventors turn their ideas into reality
• [x] Investor Network: establish an investor network that will connect inventors with investors who are interested in funding their solutions

Requirements

Requirements are separated into one of two buckets: functional, written as user stories, and non-functional, that describe how the system will perform.

Functional

Functional requirements are written as user stories following the “As a [persona], I [want to], [so that]” pattern. Here are a few example user stories:

As an inventor, I want to be able to configure my smart city solution to match the data collection preferences of a resident, so that I can better surface what data I’m collecting for that resident.

As a resident, I want to be able to view what data is being collected from me across all smart city inventor solutions, so that I can better determine what data I’m comfortable sharing.

As an investor, I want to be able to see what smart city solutions are collecting what data elements about residents, so that I can better decide which inventors I’m interested in supporting.

Non-functional

Non-functional requirements for the Interweave platform partition into the following areas:

| Area | Description| |:--------|:--------| | Scalability | The ecosystem should be designed to handle growth and expansion, both in terms of the number of inventors’ solutions and the number of resident devices connected to it. | | Transparency | The ecosystem should be designed to be transparent, with clear policies and procedures in place to ensure that stakeholders understand how the ecosystem works and how it is being used. | | Interoperability | The ecosystem should be designed to work with existing infrastructure and devices, and be able to communicate with a wide range of systems. | | Security | The ecosystem should be secure, with measures in place to protect against cyberattacks and other security threats. | | Privacy | The ecosystem should be designed with privacy in mind, with clear policies and procedures in place to protect user data. | | Sustainability | The ecosystem should be designed to minimize its environmental impact, with a focus on energy efficiency and sustainable practices. | | Accessibility | The ecosystem should be accessible to all users, including those with disabilities or who may have limited access to technology. | | User-centered design | The ecosystem should be designed with the needs and preferences of users in mind, with a focus on ease of use and an intuitive user interface. | | Data management | The ecosystem should be designed to handle large amounts of data, with efficient data management processes in place to ensure that data is accurate and up-to-date. | | Collaboration | The ecosystem should foster open collaboration between stakeholders, including government agencies, businesses, and individual users. |

Architecture

Several technology layers and a variety of components and edge applications are within or connect into the Interweave architecture footprint. Below is a simplified example of a logical architecture diagram and quick outline of the building blocks.

Simplified Logical Diagram

Connectors

Reusable, out-of-the-box extensions for inventors to easily add new smart city solutions into the Interweave ecosystem following approved resident data collection transparency patterns.

Edge Applications

• Real-time overview dashboards are the crossroads between innovation and data collection, tailored to the appropriate persona
• Resident Data Collection Transparency Portal
• Inventor Portal
• Investor Portal

Integration Hub

• API gateway: a secure access point to route requests, aggregate responses, and enforce service level agreements through features like rate limiting
• Experience APIs: correlate to an edge application and built in GraphQL allowing consumers to fetch specific data in a single request, reducing load times with fewer calls:
• Resident Experience API
• Inventor Experience API
• Investor Experience API
• Process APIs: provide a means of combining data and orchestrating multiple System APIs for a specific business purpose:
• Resident Preferences Process API
• Device Data Capture Process API
• Investor Registration Process API
• System APIs: surface data from source systems keeping the data model intact:
• Resident System API
• Resident Preferences System API
• Device System API
• Smart City System API
• Service Bus: load-balancing and coordinating transactional work that requires a high-degree of reliability
• Resident Registration Exchange
• Resident Preference Exchange
• Device Data Exchange

Data Sources

• Resident Data Store
• Data Collection Preference Center
• Device Data Store
• Smart City Data Store
• Analytics Data Lake

Technical Challenges

A platform like Interweave must overcome a handful of challenges to successfully support a smart city accelerator program:

• [x] Integrating a variety of technologies: the platform will need to integrate numerous technologies, including IoT devices, sensors, and cloud-based analytics platforms.
• [x] Ensuring data privacy and security: the platform will need to ensure that all resident-approved data collected by the platform is kept secure and private, in accordance with local laws and regulations, and is made available on demand when requested by a federated resident.
• [x] Managing complex partnerships: the platform will require partnerships with a variety of stakeholders, including the city government, technology companies, and investors. Managing these partnerships will require effective communication and coordination.

Roadmap and Resources

Below is the proposed roadmap and estimated resources required to achieve the above vision. Our delivery motto is smaller, simpler, sooner. This improves predictability, feedback cycles, and implementation, while reducing risk.

Work Schedule

Estimated Resources

Conclusion

The transparent ecosystem approach to the Smart City Core Engine Accelerator Program aims to promote collaboration and trust between residents, inventors, and city governments. With a scalable platform, supportive resources, and a clear roadmap, this program has the potential to create significant value for both the technology industry and society as a whole.