We’ve shipped 15 new versions of beams within the last 24 weeks -averaging nearly one release per week. Here's how we achieved it:
Capture What to Build
We maintain a funnel for identifying what to work on next. Feedback is sourced from users via email (team@usebeams.com), our Slack community, linkedin, feature beams' feature request page, and during UI/UX research meetings.
All these inputs go into our system. We have a clear vision on the problem and why we are building beams that frames the roadmap. We know the tools our target users rely on daily, identify the ones causing distractions or creating siloes. The rest is the work we do: continuously iterating and refining the solution to minimize distraction, aggregate data, generate insights, improve and ultimately automate workflows.
Prioritizing Work
This part deserves a blog post alone but I will keep it short :)
Deciding what to work on involves balancing bugs, hot fixes, new features, improvements of older features, and new integrations. On top, the challenges for early-stage start-ups, time and resources are extremely limited, so prioritization is vital and mortal.
We focus on the most impactful tasks for the moment and near future. #what
We strike the right balance: the speed we gain justifies the trade-off in quality. #how
Also what is really urgent when everything is urgent? We work on the planned work, but we also detour when/if a core functionality is broken/not working. #when
How We Work
We don't do sprints but we also are not trapped into one-single-never-ending-sprint-of-a-backlog.
We’re working on projects and they are not equal to products. A project can be a feature, an integration or bundle of improvements.
2 basic rules we have:
- (Before we initiate the project) we define must-haves for release.
- (When we release) the project ends.
This approach avoids the pitfalls of timeless Kanban boards, which can lead to outdated tasks and loss of focus.
As a small team it’s impractical for us to have long sprint planning sessions. We prefer brainstorming meetings: the idea exchange makes people internalize what we can build without having a strict definition.
Also, we often cross roles, such as a backend engineer handling a frontend task to prevent bottlenecks, so we don’t have a defined role/resource.
Reading recommendation: Scrum is turning good developers into average ones.
We don’t have rules such as no new tickets can be added to the project: We can always add a new ticket and mark it as high if it is blocking the release. This will for sure delay the release. But it also creates a critical thinking for every team member. Is this piece of work really needed for the release? Until the release blocking tickets are finished, all other lower priority tasks can be worked on by the team members. When must-haves are done, we can release. We can choose to wait for All the remaining tickets to be implemented if we are good on time. If we feel like releasing and iterating sooner, we can move them to the project’s backlog or delete them.
Our Workflow
We use Linear to manage projects, which may span multiple products or roles such as backend, design, copywriting, product management, and frontend development.
- Backlog: Ideas we consider implementing.
- Product (UI-UX Research/Copy): User research and product evaluation.
- Design: Finalizing product and design decisions.
- Ready to Implement: All pre-work is done; tasks are ready for development.
- Todo: Tasks prioritized for the next 1-3 weeks to be worked on.
- In Progress: Active development.
- In Review: PR/code review or testing.
- Done: Completed tasks, published to production/users.
- Cancelled: Things we decided not to do, irrelevant or infeasible tasks.
Not every tasks requires all the steps, some go from backlog to ready to implement, some requires more pre-work (technical feasibility, design figma links).
Ready to Implement is the critical stage that we are confident we have a clarity on the work. But it still doesn’t mean that we will work on it.
There can be tasks that are ready to implement but from business evaluation we may decide not to work on it, in the near future (costly, not having enough impact).
Developers only work on the task after marked as Todo.
Labels and Prioritization
We categorize tasks by type (bug, improvement, infrastructure) and by product/repository (Backend, Webapp, Mac-client, Landing Page). Prioritization labels (urgent, high, medium, low) help us address the most critical issues first.
By maintaining a clear, structured process and fostering a flexible, cross-functional team environment, we achieve our goal of shipping new features and versions almost every week. This agility allows us to rapidly respond to user feedback and continuously improve our product.
Stay tuned for more updates!
Video of Mihri’s talk at the code.talks in Hamburg
*Check our Changelog page for the progress.
Work better, not more!
Download the beams Mac App now 👉 usebeams.com