One of the great perks of being a Product Manager at Sudolabs is the autonomy we have in how we approach each project. Each project is different, with unique client engagement styles and collaboration modes, and this freedom allows us to adapt our methods. Over the past 9 months, I’ve run three projects without any active backlog management, and I’d like to share what I’ve learned from the experience.
AG
Ales Glomb
Product Manager
Project 1: Ideapp
The goal of Ideapp was to create AI-powered innovation management software for handling ideas within organizations.
TEAM AND SCOPE
The milestones included improving a free chat web application, aka a beta version, and building a clickable Figma prototype. The timeline? Just six weeks.
The team was small: I was the PM, a tech lead, and a product designer. Our client, a corporation in the banking industry, provided one business stakeholder, but no one else from their side was involved operationally.
APPROACH
Despite the enterprise context, we approached this project with a startup mindset, keeping things lean and avoiding unnecessary bureaucracy. We only created a simple Notion activities overview for visibility, but I didn’t actively use it to steer the project. We skipped story points and estimations, focusing instead on weekly deliverables.
Our alignment came from internal and external syncs, not ticketing systems. This meant the tech lead and designer could focus on building the product while I worked on validating market demand for the enterprise segment.
RESULTS
By the end, we delivered everything: a vBeta freemium version, Figma prototype, and as addition also marketing materials and social media posts.
It worked great for a small, senior team, but I wondered, would this no-backlog approach scale with more engineers? That question led me to try it out on the 2nd project - TheStream Plan.
Project 2: The Stream Plan
This project was a classic digital development effort to build an insurance portal for Stream Plan, covering everything from initial quotes to policy management.
TEAM AND SCOPE
The project scope was much broader than Ideapp, involving multiple user types (client, agent, admins), HIPAA compliance challenges and AWS setup, API integration with a carrier provider, and more complex user flows.
The team started with three members (PM, tech lead, designer) but later expanded to five with two engineers, one medior, and one junior. From the business side, only founders were involved. The project timeline was eight weeks.
APPROACH
Again, I didn’t manage a backlog or write tickets. After discovery, the engineers set up simple tickets in Linear for their visibility (just titles and bullet points), but we didn’t estimate or over-document tasks. Later, during the crunch phase, even those tickets created by engineers were abandoned in favor of faster MVP delivery.
I felt uneasy at times, lacking a clear overview of progress, but trusted the team. We spent more time on daily syncs early on, sometimes over an hour, discussing designs and solutions. This shifted alignment from tickets to conversations, which the team preferred.
RESULTS
Despite the broader scope and two-week timeline extension, the results were impressive: the newly built portal reduced quoting time from 3 days to 5 seconds, and the MVP attracted Stream’s major business accounts. My takeaway? No backlog management saved me time to focus on:
User interviews
Competitors Analysis
Collaborating with the designer on user flows and copy reviews.
Although I did miss some predictability during development, encouraged by these results, I applied the same approach to 3rd project - AI Travel Agent.
Project 3: AI Travel Agent
This project involved building an AI chatbot for travel bookings, with a goal to launch it for an initial cohort of 1,000 users in six weeks.
TEAM AND SCOPE
The setup was different, as responsibilities were split:
Sudolabs handled front-end and AI development.
Partner company managed back-end, APIs, and product design.
The team was distributed across the US and Europe, with varying allocation levels:
Engineers were assigned 25–100% of their time.
My own allocation ranged from 20–50%.
APPROACH
I maintained the no-backlog approach but we used Notion for a basic roadmap where Sudolabs engineers logged their activities, mainly for client visibility. Planning and alignment happened in 30-minute syncs, and as the partially dedicated PM, I focused on resolving dependencies and coordinating priorities.
RESULTS
This lighter approach worked well. The client appreciated the lack of heavy project management overhead, which let the team focus on development. As a PM, I could focus on high-value tasks like scope planning and business coordination.
A comparison with a larger project: The Expert
The Expert is a platform that connects world-class interior designers with clients through online consultations and has expanded into e-commerce.
When I took over the project, it had already faced a massive six-month delay in releasing a new e-commerce business vertical. I also inherited a bloated backlog in Zenhub with over 280 unestimated tickets. Many of these tickets were created years ago and were either obsolete, duplicated, or irrelevant. The state of the backlog mirrored the overall project issues:
Zero visibility for business stakeholders.
Broken collaboration within the team.
Team members work in individual silos.
TEAM AND SCOPE
At this point, the team consisted of nine Sudolabs members: myself as PM, one designer, a project manager, and six engineers, including a tech lead. The team was split into two: one focused on developing the new e-commerce vertical (“Showroom”), and the other on maintaining and improving the client’s existing consultation business.
APPROACH
The first step to bringing order was backlog cleanup. Instead of reviewing the massive backlog with the team, we decided to close all 280+ tickets. To my surprise, only a handful were reopened based on engineering requests. This bold move allowed us to focus on what truly mattered.
Next, we ran a scope prioritization workshop with the main business stakeholders using MoSCoW and story mapping frameworks. This exercise clarified the priorities for the first release and reduced the original scope by about 50%. This helped align everyone around what we needed to deliver first and within what timeframe.
With a refined scope, the next steps were to:
Collaborate with the designer and engineering team to create designs, flows, and product specifications.
Document the deliverables via Zenhub tickets with clear descriptions and acceptance criteria.
Introduce story points (SP) for estimation to better predict timelines and team velocity.
This structured approach gave us visibility into what remained to be done and when it could realistically be delivered. The e-commerce release was broken into three phases:
December: Beta launch (full product range, limited user base).
January: Public release (marketing campaigns and broader user access).
As the team grew from 9 to 14 people and split into three squads, we leaned more on Scrum principles to maintain focus and alignment. Regular events like sprint planning, demos, refinements, and retros became essential. We also designated one engineer as a part-time Scrum Master to ensure smoother sprint execution.
Despite the increased complexity, we hit all three release deadlines. The new e-commerce vertical, with over 6,000 products, multiple designer showrooms, and integrated vendors and shipping providers, was a success. This also marked a major business milestone, establishing The Expert as a strong player in e-commerce.
RESULTS
Backlog management was crucial in this project for several reasons:
Predictability:Estimations and structured tickets helped align expectations with stakeholders and keep the team on track.
Scalability: With a larger, more diverse team, written documentation ensured shared understanding and reduced miscommunication.
Coordination: As dependencies grew, managing tickets helped ensure nothing critical slipped through the cracks.
However, backlog management wasn’t without its downsides. Maintaining such a large backlog required constant attention, multiple meetings, prioritizing tickets, refining specifications, and ensuring they stayed relevant. After the public release, the backlog began to grow again with unvalidated ideas, tech debt, and ad-hoc requests. This highlighted how backlog management can easily become a time sink if not properly controlled.
One size doesn’t fit all
As a Senior Product Manager with over eight years of experience, I’ve learned that backlog management is just another tool, which is not mandatory for every project. For smaller teams, daily syncs can replace ticketing systems, letting PMs focus on high-value activities. However, for larger teams or projects, backlog management can be essential for predictability, alignment, and handling complexity.
If you want to try no-backlog management, be prepared to invest more time in syncs and direct communication. But if you notice signs like misaligned outputs, poor predictability, or a junior-heavy team, it may be time to bring back the backlog.
Ultimately, the best approach depends on your project, team, and goals. As PMs, we have the freedom to experiment and adapt, and I’d encourage you to experiment with no backlog management as it might just transform how you approach product development.
