Foreword
I spent years in project management, earned my PMP certification, and led numerous complex projects. But nothing quite prepared me for the mindset shift required to move from project to product management.
Project management is all about planning and foresight, but when I tried applying them to product management in the same way, it just didn’t work. Product management thrives on agility, rapid iteration, and adaptability. The moment you try to impose rigid structures, innovation stalls.
The idea of sharing our workflow has been floating around for a while. Now, as we focus on expanding our blog, we’ve decided it’s time (me: YAY!🕺). This article is the first in a three-part series, starting with the core process: continuous development.
Our way
Every team claims to be agile, but the reality is that no two agile workflows are the same. Why is that? Should we be concerned about these differences? Should we try that method that worked for that other company? These are the kinds of questions we constantly ask as we refine our processes.
At Octopus, our product development cycle follows a simple loop: craft an idea → develop → analyze success → repeat
The differences lie in the details—how we shape ideas and how we run a truly continuous development process.
But it wasn't this way from the start. Like many other teams, we had to find our perfect way through trials and errors. We considered features as smaller projects with a start and end (legacy mindset from a website design agency, we know), which they are in some way, but that approach was too rigid to move rapidly.
We tried ceremonies and processes that became obsolete along the way—all to get to this point where I'm glad to share our process with you.
For instance, retrospective was re-implemented last year. First time the benefit wasn't entirely clear to us and the meeting was discountinued in that format. Today, as the team matured and cross-feature development is encouraged, retrospective is invaluable.
Development process
In Octopus, everyone is involved in development with no exceptions. We’ve built a transparent process where responsibilities are distributed, ensuring that every team member has a role in pushing tasks forward.
While each person is accountable for their part, we encourage a culture of momentum—whether it's through suggestions, assistance, or a quick nudge to prevent bottlenecks. This fosters a highly efficient and engaged team.
Tools for product development that we use:
- Slack → Team communication
- Linear → Task tracking
- GitHub → Version control
- Sentry → Issue tracking
- Better Stack → System monitoring
- Notion → Process documentation
For task management, we use Linear—a lightweight, UX-focused tool that aligns with our product philosophy. We admire the team behind Linear—their approach to building products, and their values resonate with how we operate, making it a natural choice for our development workflow.
From Weekly Releases to Continuous Deployment:
Up until seven months ago, we practiced weekly releases every Thursday. If a task wasn’t ready, it had to wait another week. This setup also required a dedicated person to resolve conflicts and merge all branches into the staging environment.
Today, our release cycle is much more fluid. Each developer is now motivated to push their tasks live as soon as they’re ready. This shift has created a more dynamic, accountable, and efficient development culture—where every team member owns their work from start to finish.
Backlog
The backlog is where every task is born. It stays there until it’s reviewed during planning, assigned to a specialist, and scheduled for a development cycle (or sprint, in Agile terms).
We treat the backlog as a workshop rather than a storage unit. Tasks may sit there for weeks or even months, evolving as requirements are refined, assumptions are validated, and descriptions are shaped. Some tasks are canceled and never make it to development, which isn’t a failure—it’s a sign that we’re moving fast and adapting to market changes.
Our development cycle lasts three weeks—we experimented with often used 2-week sprints until we found the sweet spot. This timeframe balances structured ceremonies with enough time to deliver semi-complex features within a single cycle, and is as long as we can commit in advance. If a feature requires more time, we break it into multiple sprints.
For example, our recent Publish Wizard update took exactly three weeks to develop and test.
To keep things organized, tasks are always clearly labeled with a precise name and description. This ensures easy tracking and quick retrieval when they’re ready for execution.
The backlog is continuously refined during:
- Cycle planning – Prioritizing tasks for the next development cycle.
- Cycle week review – Checking progress and making adjustments.
- On-demand sessions – Addressing urgent issues like blockers or continuous bugs.
Some tasks bypass the backlog and go straight into an active development cycle. This happens in two cases:
High-priority bugs – These take precedence, regardless of ongoing development.
Sub-tasks of larger tasks – breaking a feature into smaller, trackable iterations improves progress visibility and enables phased releases.
Cycle planning
At the first day of each cycle, we hold a cycle planning meeting to select tasks from the backlog for the next three weeks. Engineers, designers, and managers all take part—yes, it’s a time investment, but trust us, it pays off. Transparency, motivation, early risk identification, and better planning—these benefits far outweigh the time spent talking.
A person is far more motivated to complete a task when they’ve had a say in choosing it.
That’s why our planning process ensures tasks are picked with careful consideration, factoring in: roadmap alignment, priority, developer availability, and developer interest in specific task if there's a choice.
We skip the Agile tradition of using story points and instead estimate in days or weeks—but only for larger tasks that take at least a couple of days to complete. This is mainly because we have only one Agile team, and estimates are given by the specialist who will be working on the task, then reconfirmed by the lead developer.
As a result, each specialist understands and confirms the tasks they are expected to complete within the cycle.
Once a task is assigned to a developer, included in the cycle, and marked as To-do, it’s considered planned—meaning it’s expected to be completed and released within that cycle.
Development
This approach strikes a balance:
- Management can still plan releases with a reasonable margin.
- Developers work without unnecessary micromanagement.
Instead of pressuring the team with strict deadlines, we focus on empowering them to take ownership—encouraging initiative and proactive task completion.
Task Progression
- Picking up a task → The developer changes the status to
In Progress, making it clear to everyone who’s working on what. - Completing a task → The task moves to
Review, signaling it’s ready for feedback before release.
This simple yet effective process keeps work transparent, structured, and efficient.
Review and QA
During the review phase, the product manager and product owner evaluate the task against its acceptance criteria—whether it’s a new modal matching the design template or a storage limit being correctly increased.
If any inconsistencies are found, they leave comments and send the task back to the developer, switching its status back to In Progress for necessary fixes.
Once a task passes review, it moves to Testing, where our QA specialist runs regression and manual functional tests.
It’s the QA specialist’s responsibility to:
- Write and maintain automated tests for new features.
- Ensure existing tests remain valid after any changes to service functionality.
I have a love-hate relationship with this stage. On one hand, I want to ship features faster. On the other, I want them bug-free when they go live—so I force myself to be patient and let QA do its job.
Staging & Production
Before merging code into the staging environment (Stage) and then deploying it to production (Live), we require at least two developer approvals for code review. This extra layer ensures quality and helps protect our users from a poor experience.
For releases that include multiple tasks, we run another round of regression tests in the staging environment—catching potential issues before they reach production.
Retrospective
A valuable Agile ceremony that, unfortunately, often gets dismissed as a waste of time. Sure, it takes an hour or two, but in return, our team gets a dedicated space to highlight wins and challenges, identify risks early, and I, as a Product Owner, get essential input for refining processes to keep development efficient, smooth, and fast.
We hold retrospectives on Thursdays, the last day of the cycle. There’s no rigid agenda—just a shared vision: reflect on what worked, what didn’t, and how we can improve. If there’s too much to cover in one session, we vote on topics to focus on the most pressing discussions.
Conclusion
First and foremost—doing things differently drives progress. The most successful product companies embrace challenges and stay open to new ideas. They experiment often, validating each attempt, while less experienced teams can struggle—getting caught up in the process rather than learning from it.