Why issue trackers and generic project management tools can’t help you build products
I’ve been watching our team build Zepel for several months. And I also happen to have a front-row seat to see how others build their products using Zepel.
If there’s one thing I’ve learned after multiple conversations over Zoom calls and chats and observing how teams build their products, it’s this:
The road to shipping anything that isn’t a bug fix is filled with distractions, diversions, and speed bumps.
If you think about it, product development is a lot like a criminal investigation — when viewed in retrospect, it’s a simple, linear narrative that appears to be a series of if-then-else logical steps.
But inexplicably random, messy, and a gruelling process when experienced in real-time.
A million and a half questions need your attention from multiple disciplines that comes with different levels of context and at every phase of the development.
What can seem like small or trivial questions at first, ultimately ends up becoming the difference between a product that makes people cringe, and a product that makes people want to come back.
“That's why there's Agile!”
I’m certain you’d be inching to tell me all about Agile, so let me dive straight in.
Luckily, a good chunk of businesses are able to streamline their product development efforts with processes, tools, and workflows. But that’s hardly sufficient.
In the book Actionable Agile Metrics for Predictability, Daniel S. Vacanti states we spend only 15% of the time doing the actual work and the rest on waiting.
That just doesn’t sound right.
If a greater part of your time doesn’t involve coming up with killer product strategies, building creative mockups, or creating magic inside terminals and code editors, there is something fundamentally wrong.
Not with the processes, but with the fundamental assumptions that issue trackers and generic project management tools are built upon.
So what’s the problem with using issue trackers for product development?
Issue trackers are great when you want to track, well, issues. The only three things you need to keep track of an issue are:
- Steps to reproduce,
- What you expected to see, and
- What you saw instead.
The moment you know the above three, issues then go through a sequence of steps that boils down to a binary answer of “is it fixed or not”.
Today’s issue trackers and other generic project management tools are built with only this knowledge at their core, when product development, by its very nature, is the exact opposite — non-linear.
You see, when you’re building a product, it has possibilities for being interpreted in many ways. It includes obscurities and involves interlaced relationships across multiple disciplines. And to top it all, this happens at an unpredictable scale.
It’s one thing to track and fix issues, but it’s a whole different ball game when you want to build products.
If you’re thinking, “You can configure your tool to meet your needs” I hear you. The fact that you have to go through a steep learning curve and configure it just the right way, speaks a lot about the fact that issue trackers weren’t built for product development.
This mismatch between the fundamentals of today’s tools and the needs of the team building products has created havoc even to track progress.
At the surface level, it seems like a simple problem with a simple solution of knowing who is doing what by when. But the reality is far from it.
Of course, assigning and setting due dates is a step-up from completely sitting in the dark. But when you have members from multiple disciplines working towards churning out chunks of work piece by piece, just knowing it’s “in progress” is hardly sufficient.
The below illustration by Intercom is a great way to visualize how things can quickly become chaotic as more people get involved.
An issue tracker or a generic project management tool works just fine as long as you have 2-3 people. But when you bring more members from other disciplines to build your feature, that’s where things get out of hand. Because your needs evolve by infinite levels as more people get involved and the development progresses.
Sure, you might only need to know where a task is sitting when your team is just getting started with the development. But when you’re only a week away from the deadline, just to get a grip of what’s happening, you need to make sense of everything everyone has done, how much work is pending in each and every discipline involved, and how it all fits together.
To think you can get all of this context with fancy charts is ambitious at best.
For a product manager, for example, this means she would want to know:
- Who is doing what and when,
- What are the different disciplines involved in building the feature,
- Where the work stands in each of these disciplines, and
- How all of this connects to the overall progress of the entire feature, across disciplines, in real-time.
See how her needs vary?
And if you’re a developer building the product, your needs, a lot of times, are completely different.
Because at different phases of the product development process, people have unique priorities and needs that require different and sometimes multiple contexts to be efficient.
The greatest trick issue trackers ever pulled was convincing the world you could do all of this and streamline your entire product development process.
So, how do you capture and track this non-linear nature of product development?
Get the fundamental building blocks right and be process agnostic. Because slapping even the most efficient and finest processes on a broken foundation will get you nowhere.
But what does this mean?
Now, imagine if you could plan features and capture actionable chunks of work on a word document. And what if this piece of document connected to the tracking aspects of your development? To your Kanban Boards. To Sprints.
And ultimately allowed you to track the progress of your feature in every discipline. At every phase of the development process. Without the clutter or messy configurations.
We’ve built Zepel with exactly this in mind. It keeps all the building blocks of agile you already love and use while allowing you to build products with your team seamlessly.
This keeps the tool light-weight and you don’t have to go through a tedious learning process and tweak multiple settings just to get started.
Here’s a quick glimpse of how it looks:
1. Spec, plan, and capture in seconds
Zepel's document-like interface to help you quickly plan a feature.
Planning and building features are hard enough already. Zepel’s document-like editor removes all the friction and distraction, so you can quickly plan every step and aspect of your feature effortlessly.
Capture user stories, tasks, subtasks, enhancements, and bugs in seconds. And when you want to assign, set due dates, or estimate, it’s all just a / command away.
The best part?
What looks like a simple document at first, quickly becomes the single source of truth for everyone about this feature - from showing who is working on what and when, to the different disciplines involved in building it.
2. Track feature progress in each discipline
Track progress in each discipline involved in building the feature using multiple Boards.
When you bring members from design, dev, and QA, you need to be able to see where their work stands. And more importantly, everyone should be able to seamlessly handover work from any discipline to another (say, design to dev).
Zepel lets you add a board for each discipline, so everyone can easily move work around within the board and update statuses. When you want to handover work, you just have to move the item to another board. And it’s as simple as changing statuses!
This allows everyone to focus on just the things they care about and move work around without having to set anything up.
3. Align everyone on the big picture
Keep everyone aligned on the same goals and watch your feature come to life.
When you collaborate with members, the Progress view gives each member a holistic view of the entire product development plans and updates.
Team members can see how each update from multiple disciplines effects a feature’s progress. With the Kanban view, product managers use simple drag-and-drop cards to prioritize features and plan for the road ahead.
Now, I can continue to tell you about how you can run Sprints, see reports, and all the integrations we’ve got in Zepel.
But this article isn’t about features. It isn’t about speed. And it isn’t about agile either!
It’s about the fundamentals of product development. Fundamentals that aren't tied to simple issues and tasks, but to people who come with unique context and have varying needs.
Most teams understand this and are already tweaking processes to meet their team’s requirements. The tools, however, haven’t evolved.
At Zepel, we’re just getting started with tackling this problem.
But if you’re looking for a tool that lets you streamline your product development efforts, lets you minimize unnecessary overheads and side-effects of a rigid process, you should give Zepel a shot!
