Strangers to Shippers
You can find my team's project documentation here. Feel free to use it as a reference for future voyages/projects.
How do you take a bunch of strangers scattered across the globe and turn them into a working team in six weeks? That's the basic problem of a Chingu voyage, a 6-sprint, 6-week software development marathon. I'm a volunteer Product Manager who just wrapped up my sixth voyage there, and I wanted to write this up as a retrospective for myself, and as a reference for anyone thinking about joining the next one.
Across several voyages, the approach I keep coming back to hinges on a few ideas:
- Clarity over control. My job is to make sure everyone understands the why and the what so they can own the how.
- Co-create, don't dictate. The Working Agreement, the product idea, the sprint plan — these get built with the team, not handed to them.
- Momentum is the goal. In a six-week project, the biggest risk is stagnation. Stay lightweight, clear blockers, celebrate weekly progress.
If that sounds too cookie cutter, here's how I actually run it.
Week 1: from strangers to a team
The first week is about turning a group of individuals into something that resembles a team. Before we even discuss what to build, we focus on how we'll work together. I schedule a kickoff meeting with one goal: build a bit of psychological safety. We go past the standard intros and talk about why people joined, what they want to learn, and their real-world constraints like time commitments and time zones.
Chingu provides example projects, but I've found teams are most motivated when they build something that aligns with their own goals. We run a dot-voting exercise on a digital whiteboard to brainstorm and gauge enthusiasm for different ideas. A short discussion on the top voted concepts, anchored to what's realistic in six weeks, usually lands us on a direction everyone's actually excited about.
From there, we co-create a Working Agreement. It's not a rigid contract, more a living document that answers a few questions upfront: what's our primary chat tool? How do we signal when we're blocked? What's our process for merging code? This kind of alignment prevents most of the communication issues that come up later.
Building the engine: from idea to an actionable plan
With the team foundations in place, we kick off three parallel workstreams with tight feedback loops. My first task as PM is to draft a simple Product Brief. It's a one-page doc that lays out the vision, the problem we're solving, who it's for, and what success looks like. The team uses it as a reference whenever a scope question comes up.
Working closely with our UX designer, we start initial discovery: light competitive analysis, generative user research, a survey blast to potential users to pressure test our assumptions. At the same time, the dev team evaluates tech stacks and sets up the CI/CD pipeline. We pull them into the discovery conversation early, sharing our initial solution hypotheses and user needs, so the architecture and the UX get shaped together instead of one chasing the other.
By the end of week one, we had a validated problem statement. I translated our goals into a prioritised set of user stories for the MVP, usually using MoSCoW to separate the must-haves from the nice-to-haves. The UX designer had high-fidelity mockups for the core flows by then too. We review them as a team to check alignment and technical feasibility before anyone writes a line of code.
Finding a cadence: the art of the sprint
With a prioritised backlog and designs in hand, Monday of week two is our first sprint planning. I walk the team through estimating their tasks, and I'm explicit that the point isn't to enforce deadlines, it's to understand complexity and surface dependencies. Once the sprint is planned, team members self-assign tasks from the GitHub project board.
To keep things moving, I host one or two backlog refinement sessions during the week. Finding time in everyone's schedules is hard, but we make it work. In those working sessions, we clarify upcoming stories, break down the larger epics, and make sure next sprint's work is ready to go. It's also where I feed new insights from ongoing user feedback back into the backlog.
We close out each week with a short demo and retro. We celebrate what we shipped, talk about what went well, name the bottlenecks, and commit to one improvement for the next sprint. Nothing fancy — just a rhythm the team can rely on.
Week 6: the real MVP is the team
The MVP we ship is only half the story. The real outcome of a Chingu Voyage is the team itself: a group of people who learned to work together, push back on each other respectfully, and build something they actually care about. Good things tend to come out of empowered people with a shared goal more than they come out of process and red tape. It's cliché, but it's true, and it's why I keep coming back.