Greetings, dear reader! This is the very first post in my blog, and I’d like to share my own research in the area of project management systems. What you’ll find here is a mix of personal insights and observations, alongside practices borrowed from the world of software development. All of it comes together in my pilot project — Hotpot Tracker.
I hope these ideas prove useful and perhaps even inspire new approaches to organizing project management, or building your own custom systems.
Note: Hotpot Tracker is a pilot project created to demonstrate the ideas discussed in this article. It is not intended as a full-fledged replacement for tools like Jira or Linear, and currently lacks many standard features.
Table of Contents
Open Table of Contents
Multiple Boards Instead of One Universal One
In my experience, the responsibility for creating project boards often falls to the person in charge of managing the process. That might work fine in some team structures. But if your organization encourages proactive team involvement, it becomes clear that managing the process shouldn’t be the manager’s job alone — team members should participate too.
When non-managerial specialists like designers are part of the team, it’s important to remember that their workflows can vary greatly from one project to another.
Example: Creating a logo may seem like a task that fits nicely into a universal board. But redesigning a button used across an entire mobile app involves a broader set of stakeholders and calls for a non-standard process.
Cross-functional tasks inherently involve more teams, making the idea of a single “super-board” inefficient.
In such cases, tasks are often grouped by context using epics or milestones. But epics by themselves don’t enhance the process — they’re mainly cognitive aids.
My proposed improvement: create a separate board for each such project. A dedicated board allows for:
- Custom status logic tailored to the specific project — which may differ drastically from standard flows like Kanban.
- Epics still serve a purpose — a project, represented by a board, is decomposed and visible to both managers and team members.
In other words — build more boards together. Let team members adapt the tools to suit their workflows. The limitation of this approach lies in governance — it requires trust and feedback loops. Teams are free to shape processes as they see fit, but must justify their decisions.
Team Involvement
Team engagement often revolves around assigning someone a task. But in reality, we frequently participate in tasks that aren’t directly ours.
This leads to the issue described in Comments Are Evil — the context of discussions is scattered across messengers, personal chats, and missing documentation. Team engagement should be driven by feedback loops within the system itself. In simple terms: if you’re even indirectly involved in a task, the system should help pull you in and support decision-making.
Most trackers already notify users via email about updates.
A common method is the “Watch” feature. My approach adds a twist: reviewers are attached to columns (columns = workflow stages). This works particularly well when the process spans multiple boards.
This setup allows interested colleagues to focus on specific workflow stages. For greater impact, it helps to ensure:
- Managers are present on the task board alongside the team — their tasks live there too.
- Both managers and contributors can act as reviewers for each other’s work stages.
This might be hard to implement in large companies, but point 2 above shows it can significantly improve communication — which is often the core problem.
Shaping the Process Through Peer Reviews
I come from a software engineering background, and I believe our field offers valuable practices worth adopting.
Take GitHub or GitLab for example — they have a clear approval mechanic for pull requests. A developer submits changes, which can be merged only if approved by others.
If you compare code to task descriptions in trackers, they’re quite similar. Code outlines what a computer should do; task descriptions outline what a human should do. In both cases, clarity is key. Just as developers review code on GitHub, we can review task descriptions and attached artifacts in trackers.
If we agree that task content matters and should follow quality standards, the next step is to build review mechanics around that.
In Hotpot Tracker, any team member can be a reviewer, tied to specific columns. The approval rules I implemented include:
- At least one reviewer must approve the task (“one of contributors”)
- All reviewers must approve (“all contributors”)
If reviewers aren’t satisfied, the task can’t move forward.
Comments Are Evil
Every task spawns chats, emails, calls, diagrams on whiteboards — the context gets diluted. Even if comments live directly within the task, they can still pile up into hundreds of messages.
If we agree that a task should contain decisions and outcomes, it makes sense to anchor our conversations to that content.
GitHub has a great example: if a reviewer spots an issue in code, they can start a discussion on the exact line. Likewise, in a tracker, instead of comments, we can use discussions tied to specific words or phrases in the task text.
AI-First Thinking
It’s 2025. We’re deep into the AI era in tech. As a developer, I see that traditional systems will inevitably evolve.
AI’s performance heavily depends on input quality. The most effective use of GPT and agents comes from well-defined prompts. The more precise your task — the better the output.
Let’s be honest — most of our tasks today are poorly structured. As a result, current-generation AI will misinterpret context or completely fail to execute anything complex.
This means: the more structured and enriched our task content is, the better AI can assist us.
In Hotpot Tracker, there’s currently a simple AI-generated board report. If you add meaningful data — deadlines, assignees, blockers — the AI can produce significantly better insights.
Conclusion
If you can implement even some of these ideas in your own project management systems — especially using existing tools — that’s fantastic.
Hotpot Tracker isn’t trying to replace existing systems, but to gather these concepts in one place for demonstration. I truly believe we should explore adjacent domains for inspiration. People in other industries often solve similar problems much more efficiently — you just have to notice.
Thanks for reading!