Read: User-driven product development for a Parallel Society

INTRODUCTION

Building for Activism: User-Driven Product Development

Building within Logos means creating the infrastructure of a parallel society. Hacktivists work with Circles and communities to identify recurring problems and turn successful solutions into tools, businesses, or open-source infrastructure that can serve the wider ecosystem.

The focus is on building things that solve real problems people are already experiencing, while keeping the long-term needs of the parallel society in view.

BUILDING FOR THE PARALLEL SOCIETY

Logos is building alternatives to institutions and systems that are no longer serving people effectively. Circles are already putting this into practice by organising locally around issues such as community cleanups, fundraising, and other forms of civic action.

Hacktivists contribute to this work by building parallel infrastructure:

• Software and open-source tools
• Businesses and services
• Small solutions to specific recurring problems
• Infrastructure that can eventually serve a much larger ecosystem

Taken together, these projects can form the foundations of a parallel economy. Looking at how different parts of an economy function in the real world can help identify opportunities for what needs to be built.

The starting point, however, is always the same: a real problem experienced by real people.

START WITH THE PROBLEM

User-driven product development means involving the people who will actually use a product throughout the development process.

The process starts with problem identification, not brainstorming solutions in isolation.

• Talk to people in Circles and communities to understand their day-to-day problems.
• Look for problems that are genuinely painful and important.
• Pay attention to recurring problems that affect multiple people or communities.
• If you are part of a Circle, problems you experience yourself can be a useful starting point.
• Avoid assuming that a problem is important simply because it seems interesting to solve.

Not all problems have the same level of urgency. A common mistake is building something that people say sounds useful but that they do not actually need badly enough to use.

The goal is to find a problem that is both painful and achievable.

TALK TO USERS

Before deciding what to build, spend time understanding the people experiencing the problem.

User interviews should focus on their actual experiences rather than on explaining your own idea.

• Ask about what they currently do and how they solve the problem.
• Understand what is difficult, expensive, slow, or frustrating about the existing process.
• Look for evidence of behaviour, not just stated interest.
• Avoid leading people towards the solution you already have in mind.
• Use conversations to test your assumptions about the problem.

Good product development starts with listening.

A useful resource for learning how to conduct better interviews is The Mom Test, which focuses on asking questions that reveal genuine needs rather than encouraging people to give polite or hypothetical feedback.

CHOOSE AN ACHIEVABLE STARTING POINT

Even when the long-term vision is ambitious, the initial problem should be small and clearly defined.

Many successful products started by solving one narrow problem for a small number of people before expanding.

An initial problem should:

• Be specific enough to understand clearly
• Be small enough to tackle within months rather than years
• Have a clearly identifiable group of users
• Allow you to test whether the proposed solution actually works

A focused starting point makes it possible to learn quickly without committing large amounts of time or money before the underlying assumptions have been tested.

BUILD AN MVP

Once a problem and potential solution have been identified, build the simplest possible version that can test the important assumptions.

An MVP, or minimum viable product, is not the finished product. It is an experiment.

The aim is to:

• Build quickly and cheaply
• Keep the scope as small as possible
• Get something into users' hands
• Observe what actually happens
• Use the results to decide what to do next

Avoid spending too much time making the first version perfect. The purpose of an MVP is to learn whether the solution works, not to produce a polished final product.

Sometimes the first experiment does not even require software. A manual process, landing page, prototype, or small real-world activation can be enough to test whether people actually want the solution.

VALIDATE THROUGH REAL USE

Once something is in users' hands, stay close to them.

• Talk to users about how they are actually using the product.
• Ask what works and where they encounter problems.
• Observe behaviour rather than relying only on what people say.
• Where appropriate, use analytics or other forms of product tracking.
• Look for patterns that reveal where users are getting value and where they are dropping off.
• Use this information to guide product decisions.

Validation is about evidence that people are getting value from the solution, not simply positive reactions to the idea.

ITERATE, LEARN AND GROW

Product development does not end when the first version is launched. It becomes an ongoing cycle of learning and iteration.

Keep asking:

• What are users repeatedly asking for?
• What patterns are emerging across users?
• Are people actually getting value from the product?
• Is there a simpler way to solve the problem?
• Is there a related problem that may be more important?
• Is the current approach the right path?

Do not become overly attached to the original product idea. If it works, continue developing it. If it does not, the process may reveal a different problem or a better way to approach the same one.

Successful products often emerge after many iterations and experiments. The ability to keep listening, adapting, and trying again is part of the work.

THINK ABOUT SUSTAINABILITY

A product also needs a sustainable way to continue operating.

Depending on what is being built, this could mean:

• A business model
• A donation model
• An open-source funding model
• A token-economic model for protocols

Existing projects with similar solutions can provide useful examples of how different models work in practice.

The goal is to understand how the product can continue serving its users over the long term, rather than treating sustainability as something to solve later.

EXAMPLES FROM THE ECOSYSTEM

FUNDBRAVE

Fundbrave is an example of a product emerging directly from a Circle's needs.

• The Benin City Circle needed a way to raise funds for its winnable issues.
• The team initially built a very simple landing page to accept donations.
• Other Circles expressed interest in using a similar solution.
• The team first created individual fundraising sites for those Circles.
• This provided validation that the problem extended beyond the original Circle.
• The solution then evolved into a self-service fundraising platform.

The important pattern is:

Solve your own problem → solve the same problem for others → build a reusable product.

AQUARI

Aquari followed a similar path from a local problem towards larger-scale infrastructure.

• The initial problem was local waste and ineffective cleanup efforts.
• The team explored whether blockchain could help coordinate and incentivise local cleanup activity.
• Their first MVP was a small local cleanup using token incentives.
• This tested whether people would actually participate.
• They then explored funding through donations, partnerships, and government contracts.
• The project has since developed towards a more mature protocol and larger-scale opportunities.

The initial experiment was deliberately small. It tested the core assumption before significant infrastructure was built.

BUILDING IS ACTIVISM

The role of an Activist Builder is to turn real needs into working solutions.

The process is:

Identify a real problem → talk to the people experiencing it → build a small experiment → test it in practice → learn from users → iterate → scale what works.

The objective is not to build technology for its own sake. It is to create infrastructure that people actually use and that can eventually serve the wider parallel society.

Building is activism that scales, and the parallel society needs people willing to do that work.