Translating principles into day-to-day ways of working.
In Part 1, I described why the traditional Product—Engineering split fails in early-stage B2B startups, and why our context at comundo led us to approach collaboration differently.
In this post, I’ll go deeper into the “how” — the concrete practices and rituals that let us stay fast, aligned, and effective without resorting to heavy planning or detailed specifications.
Before Writing Code
The most important part of shipping value happens long before we write a single line of code. It starts with identifying which projects are actually worth shipping.
Projects enter our prioritization pipeline from multiple directions. Often, it’s a request from a client — something they can’t yet do in our product but need to. Sometimes it’s a discovery from a sales conversation that could unlock a deal. Other times it’s an idea from an engineer who notices how integrating better with a third-party system could meaningfully improve the user experience.
Regardless of the source, the first step is always the same: we capture the project in terms of the user problem or the value it should create. At this stage, this can be just a few sentences — enough to understand why this might matter.
Once a project is captured, the process is straightforward:
- Product estimates the business potential
- Engineering estimates the complexity
Both are intentionally rough numbers on a scale of 1 to 100. Their correctness matters far less than their internal consistency — if we sorted projects by complexity alone, the most complex ones should reliably appear at the top.
We then combine the two numbers:
priority = business potential / complexity
This helps us identify where we can create the most value per unit of effort.
But we don’t blindly follow the top ratio. Some projects depend on earlier technical groundwork. Others are high-value but too large to tackle right now. And sometimes there’s a small project that unblocks learning or delivers quick value.
Most importantly: the choice is always a conversation. Product, Engineering, and other relevant stakeholders look at the ranked list, share perspectives, and select the next project together.
This ensures we stay aligned on why we’re building something, not just what.
Solution and Scope
I have a thesis: only the engineers working on a system can design the appropriate solution.
This comes from witnessing teams try — again and again — to force a square peg into a round hole because a solution was predesigned without deep understanding of the system’s intricacies. Only engineers working inside the system understand its constraints, its quirks, and the paths of least resistance. That context is essential.
So once a project is selected, the engineering pod designs the solution. The most crucial part of this stage is scope alignment with stakeholders, especially Product. In many cases, the solution is straightforward and alignment is quick. But in cases where the system doesn’t naturally support the desired outcome, we need to make explicit tradeoffs:
- Should we invest more time to work around limitations?
- Is the simpler path good enough to deliver value?
- Are we solving the core of the challenge, or just the symptoms?
Clarifying these tradeoffs before we start building ensures that we don’t ship something technically elegant but useless — or something valuable but architecturally damaging.
A shared understanding of scope is what makes sure we ship value, not just features.
Engineering Pods
I’ve mentioned Engineering Pods a few times — here’s what they are. An Engineering Pod is a pair of engineers who work closely together on a project. They jointly:
- investigate the project
- define scope
- design the solution
- decide how to collaborate on code reviews, testing, and delivery
Pods follow shared engineering practices (e.g., backend conventions, frontend conventions), but they operate with autonomy in how they execute the work.
Why Pods?
Originally, we were one big team working on everything together. Everyone planned together, aligned together, and contributed to the same project board. This had benefits — shared context, collective ownership — but it also slowed us down.
When a project got stuck or needed clarity from Product, no one was clearly responsible for unblocking it. It was also easy to start new projects before finishing the ones already in progress — a classic early-stage trap. Pods solve this by giving:
- clear responsibility
- tighter focus
- faster iteration
- stronger ownership
Two engineers owning a project end-to-end almost always outpace six engineers loosely collaborating on it.
This has it’s downsides - engineers who work on a certain part of the system will know that part a lot better than the ones who did not. However, in the early stage this tradeoff is worth it — speed is a lot more important than complete alignment at our stage. We also balance silo formation by having two engineers collaborate on a project — the solution will be more balanced compared to someone working on it alone.
Concrete Practices
Given all of the above, what does our actual day-to-day look like?
Two-week sprints
We plan work in two-week sprints and run a retrospective at the end of each.
Sprints mostly help us organize non-project work: writing new integrations, maintaining existing ones, addressing operational needs, or supporting customer success.
Weekly Product & Engineering alignment
Once a week, the broader Product and Engineering group syncs on:
- active and upcoming projects
- shifts in client needs
- discoveries from sales
- system considerations
- cross-team visibility
It’s short, direct, and ensures no one drifts out of alignment.
Straightforward engineering workflow
Pods use a simple engineering workflow:
- feature branches
- code reviews
- CI/CD pipelines
- automated testing
- Staging and Production environments
Just enough process to ensure quality and consistency while maintaining high speed. We also iterate with the process. For example, we introduced CodeRabbit in our code review process and removed mandatory code reviews for certain repositories as a result. The team is also great at testing new approaches to see if other practices can be useful for us.
All of this lets us move quickly without relying on heavy planning or rigid handoffs — while still maintaining clarity, quality, and alignment across company.
The collaboration model only works when principles and practices reinforce each other. Prioritization shapes focus, pods shape ownership, and tradeoff conversations shape the quality of what we ship. This is how we make our philosophy real.
In the final post of the series, I’ll go into the outcomes: how this approach has affected speed, engagement, reliability, and the way we build products at comundo.