RPP - Rapid Prototyping Pod


  1. This brief introduces the Rapid Prototyping Pod (RPP).
  2. The RPP aims to foster an innovation engine capable of navigating a full spectrum of complexity in software projects, from simple predictable mature business lines to opportunities in complex political economies (like Ethereum).
  3. The RPP structure involves using briefs as a tool for alignment and “pods” as agile, goal-oriented teams with limited scope and duration.
  4. Pods are the primary vehicle for promoting rapid prototyping and collaboration towards achieving innovative outcomes. A pod with momentum can compound quickly into exponential value creation.

A Brief, Incomplete, History of Software Dev at Gitcoin

Software development at Gitcoin has broadly speaking followed two different organizational methodologies.

  1. YOLO Build - there is a problem. Fuck it, lets solve it as lean as possible.
  2. Traditional Agile - build a team + invest in their context + success, and point them at a roadmap.

Both of these approaches come with trade-offs.

What are their cultures?

In the parlance of Rands in Response, YOLO Builders are Volatiles and Traditional Agile teams are stables.

The culture of the YOLO Builds is like that of Pirates. They adapt + response to a chaotic environment. While they are effective at making lean bets + sometimes those bets pay off, they leave a path of carnage in their wake.

The culture of the Traditional Agile team is more like the Navy. They are predictable + are great at sailing for a longer time in one direction. They can scale higher but also they cost way more.

There have been various lineages of both of these cultures over the 7 years of Gitcoin’s existence.

  1. Lineage of YOLO Builds
    1. Gitcoin 1.0 Owocki driven (2017-2020) => Moonshot Collective (2021-2022)
  2. Lineage of Traditional Agile
    1. Centralized team (2019-2020) => Gitcoin Product Group (2021-2023) => Grants Lab (2024)

What are their tradeoffs?

The YOLO Builders (at their best) are effective at lean creation of new business lines 0 to 1, experimenting with bold new ideas, sensemaking, or working emergently with the community.

At their worst, they’ve been costly, sloppy, uncoordinated distractions from Gitcoin’s core mission.

The Traditional Agile Builders (at their best) are more effective at maturing business lines from 1 to 10. Synthesizing the needs of an ever increasing TAM of customers, and solving the tradeoffs that come with having to scale.

At their worst, they’ve been money furnaces - ingesting cash but not producing much in terms of product market fit or network effects.

Synthesizing these two perspectives

In this post, I would like to reason about what a RPP at Gitcoin would look like. I envision a continuum between these two types of teams.

By reasoning about the merits of both types of teams, we can create an innovation engine that can hold both modalities at once.

By having both modalities nurtured, we build vehicles that are adept at navigating the entire spectrum of the Stacy Complexity Matrix - from simple areas where we’ve got predictability (like our mature business lines) to the frontier of complex political economies like the Ethereum ecosystem (or the world).

Reset Opportunity

As the dust settles on the most recent re-org, we have an opportunity to reset from the habits of the past.

We can build DAO Forward, non-skeuomorphic ways of working.

We can learn in public.

We can build more effectively towards Gitcoin’s Essential Intents.

We can leverage what we know about 3 years of being a DAO, about how we might organize our work. We can leverage Allo protocol. When all else fails, we can copy what works at other DAOS (I personally think Optimism is crushing it at innovating with their community - having won a bid to build RetroPGF voting software there in Q4 2023 and launching EasyRetroPGF.xyz out of it in Q1 2024 - an opportunity that never would have been afforded me in non-DAOs)

While it may feel safe to lean on traditional development models, it has not so far been effective. So let’s reset - and chart a new path forward. Lets Make Gitcoin a Leader Again.

Rapid Prototyping Pod (RPP)

Orbital Model

At it’s start, the RPP will have the following centers of gravity, ranked from inner orbit to outer orbit:

  1. Priority Council -
    1. Who? Comprised of executives (has budget, has a vision, has an agenda)
    2. Archetype: Meg, Owocki, Rena.
    3. Accountable for: Representing GS, the market, synthesizing inputs + greenligthing budgets, etc etc
  2. Citizens
    1. Who? Anyone who identifies as a Gitcoin Citizen.
    2. Archetype: Umar, Kris, Carl Cervon, etc.
    3. Accountable For: Sensemaking or building.
  3. Market
    1. Who? Anyone building in the Ethereum/EVM ecosystem or in one of our target markets.
    2. Archetype: Our partners, community, etc

The job of the priority council + the citizens is to work together to capture the most valuable opportunities into Gitcoin’s network.

Unfortunately our attempts to be involved in RetroPGF at Gitcoin have come with some false starts. In early/mid 2022, Scott and I saw it coming and negotiated with Optimisms founding team to have Gitcoin Grants tech at the heart of Optimism RPGF. As that agreement got passed along to implementation, it was not prioritized/resourced appropriately (or something else went wrong, depending on who you ask) and Gitcoin lost the deal. Optimism broke up with us in Q4 2022 and decided to go it’s own way technology-wise. This cost us a partnership with the new PGF market leader + $40m/yr-$200m/yr in GMV on Allo. This is an example of a missed opportunity.

In 2023, we were aiming for a reset and so we bid on a voting interface build during Optimism RetroPGF 3. We won the bid, and built a tool that was used fairly successfully to facilitate the voting in RetroPGF 3. Not content to just be a software provider, we also launched Greenpill Impact SZN - a series of 10 interviews of market leaders in the RetroPGF/Impact Tracking ecosystem - positioning Gitcoin’s network to understand the contours of RetroPGF. Last month, we launched EasyRetroPGF.xyz - a tool that allows anyone to run a RetroPGF round - and we’ve got a pilot in the works worth $1million+. This is an example of a captured opportunity.

You can think of the RPP as an innovation machine, that creates gravity wells or directed tractor beam of force, which over time captures opportunities into Gitcoin’s orbit.

Briefs - the currency of alignment

The primary currency of alignment in the RP Pod is the brief.

A “brief” refers to a document that is meant to create alignment between stakeholders of a DAO. You are reading a brief right now :earth_americas::woman_astronaut::gun::woman_astronaut:.

Briefs are powerful because of how they scale. If I tell you an idea on a zoom call, then that can create an alignment between n=2 people. But if I pass a brief around, I can create alignment between n people where n is the number of people who read the brief.

A good brief works backwards from its audience to create context, alignment, and cohesion. Depending on the needs, the brief may specify an objective, background information, recommendation, budget, timeline, deliverables. Briefs may be a living document, inviting peers and critics into the fold to add constructive commentary. Constructive commentary early in a briefs lifecycle is good because it prevents costly (but preventable) misadventures later in a pods existence.

A good brief is brief. Your brief should have a TLDR. Or be compressible into memetic form.

A good brief creates a bias towards action in the people who read it.

A good brief is the prerequisite to the next building block of action in the RPP - the Pod.

Pods - the vehicle for momentum

A pod is a group of contributors working together on pushing a common objective forward.

Pods are NOT workstreams.

In contrast to workstreams,

  1. Pods are small + agile. Each team should be only a few contributors. Every person on a pod should be involved as an individual contributor + contributing directly to the pod’s goals.
  2. Pods have limited time/scope. They are designed to serve their purpose then break up. (Though if they are successful, they may get more budget to try new things and form a new pod around that).
  3. Pods contributors have complementary skillsets. The EasyRetroPGF.xyz pod will has a dev, designer, PM, and BD resources on it.
  4. Pods are designed around an important objective. The EasyRetroPGF pod’s objective is to run a pilot cohort of RetroPGF campaigns (and set up a prospective RetroPGF business line).

Pod Maturity Model

A good sign that a brief has momentum is that a pod is starting to gather resources around it.

If a pod is gathering budget, then that’s a sign someone with the ability to fund it thinks its a good investment. If it’s gathering contributors, then that’s a sign someone thinks it will advance Gitcoin (and their career at Gitcoin). Momentum begets momentum. A pod with momentum will slice through problems like a hot knife through butter. And that will compound into more momentum. A pod that reaches this exponential escape velocity of momentum is the most likely to get more budget for follow-on pods.

One way a pod can gain momentum is by going through the Rapid Prototyping Workstream process (linked below).

The cost of a pod (in time/$$$) is 10x more in prioritization than it is in conception. Likewise, it is 10s more expensive in active build than it is in prioritization. So we should ask sharp questions about the viability of a pod as early in the process as possible.

If we zoom out, we can see that the above RP process is just an inner loop to a cycle of learning/improving that comes when you try audacious new things.

Zooming out even further, we can ask ourselves, does this pod seem to be on this trajectory?

Or is it on this trajectory?

Now that we are zoomed out, lets take a look at the goals of the RPP:

  1. Create strategic value for Gitcoin.
    1. This means create as many pods on an exponential trajectory as possible. The more pods + the most exponential, the better.
  2. Graduate a pod into a mature business line.
    1. There is a certain threshold of value creation that justifies the handoff from a pod with a pirate culture to the creation of a more 1 to 10, Navy-culture, stable team. I don’t think that any of the existing builds coming out of this group have met that threshold yet. We’ll know it when we see it.
    2. Resist the urge to just fund things bc we’re non-confrontational.
      1. Shelve experiments that aren’t working (or where the time isnt right, or they arent a fit for Gitcoin)
    3. Nail the handoff from 0 to 1 to 1 to 10.
      1. We’ve never been historically good at this.

Starting Small.

Gall’s Law states that a complex system that works is invariably found to have evolved from a simple system that worked.

We will be starting small on the RPP this season with a few different builds (EasyRetroPGF.xyz, and I’ve got a couple other things cooking). The primary priority council for the RPP right now its Meg, Owocki, Rena, Kyle + is focused on Grants.

If (and only if) we are successful with the first season, we will expand to doing more builds + more priority councils. Here are some areas we might explore.

This season, I want to get an early win under our belt to show that this is all worth the DAO’s resources.

I also want to experiment with ways of partnering with the Gitcoin Citizens on these builds - Gitcoin Citizens are our eyes, ears for sourcing new ideas (and turning them into briefs). They are the muscle that is going to help us accomplish these goals. I look forward to sending a few RFPs through the new Citizens Innovate Process and seeing if we can’t engineer a few briefs => pods that reach escape velocity together.

Further Reading


I like this a lot. I see Purpose to Practice and many Liberating Structures.

Purpose, what makes this work meaningful?
Wicked Question: how might we be both responsive and stable at the same time?

Principles, what rules must we follow in order to achieve our purpose?
Agreement Certainty Matrix: because different approaches are helpful in different situations

Participants, who do we require engagement from in order to achieve our purpose?
Social Network Webbing: these are the archetypes and people as well as their levels of engagement

Structures, how must we organize ourselves and distribute control to achieve our purpose?
What? So what? Now what? A brief adds observation with inference to indicate a direction of action
Min-Specs: a pod should consist of the essential skills necessary to about a test

Practices, what are we going to do and how are we going to do it?
My only point of departure from the perspective of structure, with a note that in the domain of complexity there exists only good practice where reasonable people disagree because of perspective and preference
I believe Ecocycle and Panarchy are better containers for both the developmental path, process of prototyping and potential trajectory. I believe that you are trying to emphasize the ephemeral and nonlinear/deterministic nature of things (hard agree). However
Ecocycle is similar to a Kanban board: you can map any progression or developmental path through it.

The only trick is the indexing of information in order to clarify context/content, which Panarchy provides. The Tasks nested in the RP nested in the maturity of the pod nested in portfolio of the council nested in the strategy blah blah blah. Yes this is likely more challenging to pick-up as the distinction between elements as you’ve described them may be less clear. Nevertheless I believe that the affordances that flow from making explicit their relationships to one another are worth it.

I’m also quite enthusiastic about the contents. I’ll add commentary there after I walk the dog. The reason I point out and refactor into LS is to make the patterns, that can be separated and recombined endlessly, legible because I believe that by converging on them this post is very coherent. This makes it way easier to grok one another across differences in content and context

Content: an important benefit of near continuous assemblage is social network stimulation. People have the opportunity to get to know a bunch of other people. As the organization and movement grows having relationships in many places reduces coordination costs in a big way: in stead of relying on explicit process, a player knows a nerd over there and asks for where to go for what they need. Far fewer steps and much faster to chaordinate with strong relational coordination.

While this idea sounds like an async one, regular synchronous moments can empower it.
If it swells, FAST may be a great compliment to it. TLDR: run a regular Open Space Technology where the Council(client/sponsors), Pods and Citizens(end users/ community) can chaordinate.

One thing that I missed is the “place” Briefs go to live, become anctivated and pods get created from. I’d be happy to host sessions to either generate Briefs, form Pods or especially interesting to me are evaluation sessions. Think more seasonal Shark Tank than sprint review, this can create a game that acts as nexus for citizen evaluation, feedback and up/down regulation.

You might find some resonance yonder

Anybody else?

1 Like