This week marked the end of my sixth Chingu Voyage. For those unfamiliar, Chingu is a unique remote organisation that brings together teams of strangers to build a project over six weeks. Each “voyage” is broken into week long sprints. I always participate as a Product Manager and I remain a huge supporter of the program. Unlike other expensive courses or programs, Chingu has a very low barrier to entry for aspiring developers, data scientists, PMs and designers to gain real-world team experience, whether that’s building social skills, finding people to pair program with, etc.

For me, it’s a place to experiment with approaches to building software with a team that’s free from the usual corporate red tape. It’s also an opportunity for me to give back and absorb best practices from other professional PMs, all for free! For this post, I won’t get into the weeds of how I did product discovery, etc. Instead, I wanted to write down what worked best for me in setting up these volunteer teams up for success, as the factors here are different from mature tech teams - where processes already exist.

The First Week

The first week is all about getting to know each other and laying the groundwork. I always start by setting up an introductory meeting where we can introduce ourselves, understand our individual motivations, and discuss our commitments and preferred time zones. This is also where we begin the conversation about what we’d like to build over the next six weeks.

While Chingu provides example product ideas, I always encourage the team to build something new that aligns more closely with our personal goals. I’ve met developers who want to try out a new tech stack, UX designers eager to research a particular problem space, and PMs like myself wanting to try a new methods for managing work streams and building strong teams. To decide, we run a simple voting exercise to land on an idea we’re all excited about.

Once we have a direction, we establish a Working Agreement. This isn’t an overbearing contract, but rather a simple document outlining our expectations for how we’ll communicate, make decisions, and run our meetings. It’s a rough guide to how we want to work with each other.

Kicking off the work

With the basics in place, three work streams begin almost simultaneously. As the Product Manager, I start developing the product vision and goals. I work closely with the UX designer to begin researching the problem space, identifying user needs through generative research, and brainstorming potential solutions.

At the same time, the development team begins evaluating and setting up a tech stack and CI/CD workflows. We share our initial solution ideas with them early on, so they can start thinking through the technical architecture and any challenges we might face. This parallel process is crucial for moving quickly.

Prioritise, refine, repeat.

By the end of the first week, we have a good idea of what problem we’re trying to solve and why. I then develop the first set of user stories that define the core MVP. I often use a framework like MoSCoW or a prioritisation method the team is comfortable with, sometimes using a Miro board to visualise my thought process. These stories are then shared with the development team for their input on the technical approach.

Simultaneously, the UX designer shares low-fidelity wireframes for feedback on both the user experience and technical feasibility. Once we’re aligned, the designer creates high-fidelity mockups for the first few core user stories, getting us ready to hit the ground running on Monday.

hi-fi mockup of an error flow

Finding a rhythm

Come Monday of week two, the team is ready to start building. We kick off with a planning meeting where I teach the team how to estimate the sprint tasks for the week. While many teams were comfortable with story points, I’m always inclined to make sure everyone is on the same page about how we estimate work going forward and document it. After planning, team members are free to assign themselves tasks from the project board I’ve set up.

The github project board I set up.

Throughout the week, I hold one or two refinement sessions to clarify upcoming user stories and ensure they are ready for the next sprint. This is also my time to identify new features that would improve the user experience and get them into the backlog. At the end of the week, we hold a short review and retrospective to demo our work, share what went well, what went wrong, and what we could improve.

To keep everyone on the same page, I aim to maintain a light Product Requirements Document (PRD) and create supporting artifacts like user personas and user flows as needed.

retros!

Why keep doing this?

My goal as a PM during every voyage is to experiment and learn. We only have six weeks to build an MVP, so we want to minimise process overhead and help people to collaborate as effectively as possible. It’s important to always ask questions and learn as much as I can from the developers, UX researchers, and designers on the journey. It’s about discovering what works for them and adapting on the go.

In the end, it’s an incredibly enjoyable process. It’s a refreshing break from work to just get together with a motivated group of people, rally around an idea, and support each other in achieving our goals.