#1 Are we coding too soon? — Day 3

This blog is the first in a series documenting the Re:Permissioning the City(PtC) product development journey. In the spirit of “working out loud”, the series aims to share our ongoing progress, learnings, and reflections on building a digital permissioning system designed to unlock underutilised spaces in the city for civic use, through introducing participatory and distributed forms of spatial governance.

Day 3: Product scoping — balancing strategy and feasibility

On the third and fourth days of the workshop, we started sketching wireframes based on the user journey. This required merging the two scenarios we developed, creating a coherent flow, and listing out both the technical and UI/UX requirements.

Once we layed out the entire journey, we quickly realised that a significant part of what we were building was in fact quite similar to a typical booking platform. There were two parts of the system that were interdependent: 1) a booking system that allows a user to list spaces and book events, and 2) a new permissioning system that introduces alternative ways to approve bookings, allows users to be part of permissioning groups and create rules.

Due to restrictions of time and capacity (4 months of development time), we had to prioritise, which meant we had to decide which part of the system we were going to build.

Through some debate, we came up with three potential strategies and decided to choose one.

Maximise Experimentation
In this approach, we aimed to minimise the necessary development efforts, particularly for features already common in the market. By doing so, we could redirect our development capacity towards creating interactive prototypes that facilitate permissioning experiments. This included exploring scenarios such as “How would a liability group come together?” and “How would this permissioning group share decision-making responsibilities?” (Focusing on permissioning system)

Risks:

• There is a risk that funders may not support this approach, as the booking system may not be fully functional.
• The development timeline could be delayed because the prototype is not fully specified yet, meaning the development team would need to wait until the prototype design is finalised.

Opportunities:

• Focusing on experimentation benefits future pathway building especially innovation funding

Maximise Potential for Real Users
This strategy recognises the significant impact of involving real users at the end of the process. We proposed developing a functional booking system while continuing to explore the formation of liability groups and the permissioning mechanism through design workshops. (Focusing on booking system)

Risks:

• Misalignment with the broader Dm identity and portfolio: investing too much time in developing features that are already available in the market may not align with Dm’s vision and strategic goals.
• Deadline Pressure: even if we allocate all development capacity to building a fully functioning system, we may still struggle to meet the 4-month deadline.
• Project objectives: We want to validate our concept around permissioning through this first phase, and we cannot do that by building a booking system.
• Funding risks: it depends on what kind of funding we are going for, but innovation funders will want to see the innovation.

Opportunities:

• Foundation for future experimentation: Developing functional software provides Dm with solid tools and a platform for future experimentation.
• High-quality delivery: This approach ensures that we deliver a fully functional system, likely to perform well in assessments.
• User ready: If we can have real users, we can apply for other types of funding e.g. specifically for product development

Interoperable Permission Engine
In this direction, we focused on the importance of a fully functional user flow while dedicating our development efforts to creating versatile digital tools for experimentation. This includes developing an interoperable permissioning plugin compatible with existing booking systems. (Focusing on permissioning system)

Risks:

• Can end up developing all the fullstack systems for the MVP.
• It’s uncharted territory so we might underestimate the development time needed.

Opportunities:

• Can focus on building more value aligned outcomes.
• Can acquire a broader range of potential users than running a single platform ourselves.
• Can provide more dynamic types of usage by having some flexibility on scopes of entities who host the permission engine.

We ended up choosing the third option, which was suggested by our backend developer Donghun. The reason why we documented this lengthy debate and decision-making process is because it triggered a lot of critical, fundamental questions and areas for clarification.

What does product development in Dark Matter Labs look like?

Triggered by the debate around feasibility and vision, we had a chance to reflect on the tensions caused by different priorities. As a collective of individuals primarily trained in architecture, design, and policy, Dark Matter Labs as an organisation doesn’t resemble a typical tech start up. Then what does a product development journey look like in our unique context? How is the product that we are striving to develop different, and how should the development journey be adapted to work in our current team dynamics, without compromising delivery? We don’t assume that we would be able to answer these questions right now, but we document here some of the reflections that emerged in our conversations during the workshop.

How is our product different?

We all agree that Dark Matter Labs is not a tech start-up trying to make a product that responds to market demands. We are more of a strategic design and research lab interested in elucidating systemic problems and developing experimental products that can provoke, and perhaps, solve some of these fundamental issues. In recent years, we’ve moved beyond crafting narratives that provoke thought, to actually building products that do both — provoke and solve problems. Circulaw is a good example of such a product built with actual users in mind. Having developers on the team who were involved in building products like Circulaw (and other market-ready solutions) gave us the opportunity to raise critical questions.

Product development at Dm presents unique challenges and opportunities, particularly when addressing systemic issues rather than simply filling market gaps or meeting unmet needs. Can we really build a product that addresses the problem of ownership and centralised governance? How far can we go in embedding our critical (but speculative) ideas into a product? Will people even understand and appreciate it? (Even our blogs are notoriously difficult to read). Who is our primary audience or user? Building a product that requires significant upfront resources and diverse capabilities compels us to answer these questions from the outset.

Are we coding too soon?

During the workshop, we had an opportunity to reflect critically on our current approach to transitioning projects into products, particularly how this process affects developers within Dark Matter Labs. One key takeaway was the importance of having a robust paper prototyping phase to validate key concepts and hypotheses before coding begins (tensions could emerge when project holders underestimate the labour of coding — and the labour of having to re-write it). This phase, alongside thorough user interviews and testing, would help refine smaller details early on. From a developer’s perspective, it’s much easier to focus on how to build something if the what has already been clearly defined. As Donghun pointed out, getting these what questions sorted beforehand allows developers to focus on building a product with technical integrity, without worrying about shifting goals.

There are definitely advantages to loosely structured projects within Dm which have been our default pattern — the ability to adapt to changing contexts, being open to radical iteration — but product development requires a different level of investment and nature of collaboration, which in turn demands new structures and practices. Perhaps it’s useful to clearly distinguish the paper-prototype phase supported by workshops, before attempting to start building digital prototypes.

We also realised there was room for improving how strategic designers and developers work together. How can we ensure smoother handovers from concept to execution? Developers thrive when they work on projects with real-world applications — projects that go beyond one-off workshop tools and are sustained long enough to generate meaningful data for future iterations. This sense of continuity and contribution is crucial for developer growth. Ideally, we envision a scenario where designers and developers co-create provocative projects that go live to meet real user needs, operating for a sufficient time to gather the data necessary for iteration and future improvements. This way, developers get a sense of growth and contribution, knowing their work has a lasting impact.

Wrapping up the workshop and looking ahead

This concludes the documentation of our first in-person workshop focused on product scoping. It wasn’t a very structured workshop at the beginning, but we managed to build the necessary structures and processes that allowed us to move to the next stage.

1. Defining the horizons
2. Deliberating on core principles and values of the product (more suggestions collected throughout the week)
3. Designing two types of scenarios and user journeys
4. Merging two scenarios into one user journey and sketching paper wireframes
5. Prioritising what to develop/code
6. Discussing pathway strategies
7. Ideating around branding/identity
8. Identifying questions for the future (collected throughout the workshop)

These were some of the concrete steps we took, with countless conversations in between. As we move on to the next phase of production, we hope that this documentation will serve as a template for teams that are looking to explore (digital) products — bridging strategic design and product development, and making the move towards transitioning projects into products.

Lastly, we share some questions that we identified throughout the workshop, which we have ‘parked’ for now.

• Do we need everything to be decentralised?
• How far does decentralisation go?
• What kind of deliberation and decision-making model would the permissioning group adopt? E.g. consensus-based, and what is the reasoning?
• How do we help space stewards(permissioning group) shape the rules of the space? What kind of facilitation is needed?
• Will financial values be generated by spaces? How do we deal with financial value without encouraging rent-seeking behaviours?
• How could Horizon 1 look different from the current system (while still operating within existing systems)
• How to convince cities of new ways of doing things?
• What is “functionality” for research grant funders? And how do we best meet their expectations regarding tech products? (especially funders who are not typical product development funders)

Read Day 1: Transitioning from project to product

Read Day 2: User journey and scenario building

This blog was written by Eunsoo Lee in conversation with the core team of Permissioning the City and utilising the records of the workshop.

Team members who contributed to the workshop (in alphabetical order):
Calvin Po, Donghun Ohn, Eunji Kang, Eunsoo Lee, Fang-Jui ‘Fang-Raye’ Chang, Hyojeong Lee, Shuyang Lin, Theo Campbell

Wider advisory group:
Indy Johar, Hee Dae Kim, Gurden Batra, Charlie Fisher

Partners and funders:
NIPA(National IT Industry Promotion Agency), P4NE(Partners for a New Economy), Parti