The Idea That Started Backlogic

In practice, project management tools often end up cluttered with half-baked items. It’s easy to lose track of duplicates, relationships, and—frankly—everything you need to stay in control.

As a project manager, this persistent “pebble in my shoe” made me rethink how we work. I wanted a system that naturally led to structure—a tool that didn’t just store tasks but provided the necessary guiderails to keep projects clear and actionable.

Coming from the age of waterfall project management, I saw both its pitfalls and the improvements brought by Agile. I liked how it introduced a lightweight, flexible approach that focused on delivering business value over process-heavy documentation. Even the most basic rules—like properly structuring a user story and clearly defining the key aspects of the outcome—could significantly improve a project’s relevance and success.

Add a few extra rules, self-managed teams, Agile ceremonies—spice to taste. Stir, and Agile perfection is served! Or is it?

It felt a little awkward to abandon the tools and structures of waterfall entirely. At times, Agile seemed like an excuse to stop planning simply because people found it difficult.

Still, I decided to give it time—the benefit of the doubt. Maybe a simpler process would lead to better results if more people could actively participate.

But over time, I realized that even with its lightweight rules and easy-to-follow frameworks, Agile often failed to deliver. Not because the methodology was flawed, but because people still struggled with it.

The Structure Problem in Agile

Despite its simplicity, Agile projects often lacked structure where it mattered most. Many Agile teams I worked with struggled to maintain insight and oversight due to a lack of structure in their backlogs.

I love how Agile prioritizes business value and separates target groups at the core through user stories. But I saw many teams struggling to describe these clearly. And since most project management tools presented backlogs as nothing more than a big, unstructured bowl of text, the following issues - among others - kept popping up:

1. Was the benefit described?

Too often, people would write:

— and then either leave the last part blank or repeat the benefit in vague terms. This made both the benefit and feature unclear, turning the user story into an unnecessary formality.

Over time, teams stopped writing stories altogether, defaulting to actions instead of outcomes. Without realising it, they were abandoning the foundation of Agile development. Many projects that did this—and there were many—gradually regressed into uncontrolled waterfall projects disguised as Agile.

2. Was this benefit already described elsewhere?

The same business value might be written in different words, a different order, or slightly rephrased—leading to

3. Were the role and feature parts of the user story properly defined?

Many teams defaulted to using “user” as the role in every story. While that’s sometimes fine, it often caused confusion. A feature can appear multiple times if it serves different roles or benefits, but if the role isn’t clearly stated, it’s hard to track its true purpose. On the other hand, if the feature itself is missing, too generic (“component”), or described inconsistently across stories, teams lose the ability to prioritise effectively—making it much harder to deliver maximum value within time and budget constraints.

This lack of consistency made searching, filtering, and—most importantly—prioritising stories incredibly frustrating, if not outright impossible.

What If Structure Came First?

So, I started thinking:

👉 What if the elements of a user story were structured first, rather than distilled later?

Instead of asking users to write free-form text and then trying to extract the important elements upon reading (neither of which, let’s be honest, is the core strength of most development teams), the tool could:

• Prompt users to enter the role, feature, and benefit explicitly

• Guide them with help texts and validations

• Automatically generate a properly structured user story

• Store the underlying data in a structured way, making search and filtering dramatically better

This would lead to more uniform, complete stories while preserving the flexibility Agile teams love.

And I saw even more possibilities. For example, by tracking relationships between elements, users could find everything related to a “visitor”—including “first-time visitor” and “returning visitor”—without duplication or confusion.

A Simple Idea, But Not Without Its Challenges

The concept seemed straightforward, yet no existing tool did this effectively. Even the leading project management tools failed to deliver on this need.

• No tool had structured input at this level.

• No tool provided enough flexibility to add it as a template or plugin.

I got the impression that while the idea itself wasn’t overly complex, it would require a complete rebuild for existing tools—something they weren’t prioritizing. Instead, they focused on other features while leaving backlog management in the same cluttered, text-heavy state.

But I was convinced: Without data at the core—rather than just text—backlog management would always remain a struggle.

So I decided we needed a new tool, built from the ground up with structured data as its foundation.

Prototyping & The Language Challenge

Several prototypes were built and tested, and the core idea was validated quickly. But then I ran into some roadblocks:

• Language was a challenge. I wanted the tool to validate verbs and nouns, ensuring that stories were properly structured. But this turned out to be incredibly difficult—especially across multiple languages. Handling singular vs. plural, word order, and glue characters for different languages was nearly impossible.
• Different teams and companies had their own ways of structuring stories. While the system enforced better structure, some flexibility was still needed.

• Users still had to think in a structured way. Even with prompts and guidance, not everyone naturally worked that way.

• Managing data relationships was critical—without it, structured input wouldn’t deliver its full potential. But this partially brought us back to the original problem:

👉 People still needed the time and discipline to maintain lists of text.

Even with better organization, someone still had to manage it all, ensuring that relationships remained useful rather than just another layer of complexity.

A Good System, But Not a Game-Changer—Yet

The early system was promising. It solved key problems and introduced real benefits. But it wasn’t going to revolutionize project management—not in its current form.

It still demanded a highly analytical user—someone who had the time and mental space to keep things structured on a regular basis.

And for most teams, that simply wasn’t the reality.

It needed something more.

Then Along Came LLMs…

That’s when large language models (LLMs) changed everything. Exactly at the right moment.

With AI, structuring input no longer had to be an explicit process—the tool itself could help users frame their ideas correctly. Instead of forcing people to think in rigid structures, AI could:

It opened a plethora of other new possibilities to help structure and refine a project as well.

And so, Backlogic was born.

An AI-native project management tool that thinks with you, guiding you from rough thoughts to structured execution—without the clutter, frustration, and endless scrolling through unstructured backlogs.

From Concept to Reality

Over time, Backlogic became an essential part of our everyday project management workflow.

• Bugs were fixed
• Functions were optimized
• Concepts were refined and validated

All the while, we focused on developing a modern tool with a great UX—one that not only solves real problems but feels intuitive to use. Along the way, we uncovered even more powerful ideas that we’re excited to bring to life.

And we’re just getting started.

This is only the beginning—one that we’re incredibly proud of.

We hope you’ll love using Backlogic as much as we loved creating it.