The short answer is yes. Let me explain.
I’ve been working with developers and designers my entire life.
I’ve built a couple of products, worked at a young startup, and I’m now at Zepel helping development teams build better software.
I’ve spoken to 1000+ development teams while at Zepel alone. And it's evident that the way we build products is broken.
There’s so much disconnect between how you and I talk about building products and how our teams actually build them.
For all the talk of scrum and agile and getting feedback quickly, there’s so much that’s broken in how we act on the feedback and build the feature.
Teams spend so much time and effort getting a deeper understanding of customers’ needs. And yet distil everything down to a simple two-line ticket and a couple of lines of markdown description.
This is hurting your developers. And it’s hurting your business.
Nothing is more frustrating than having to understand what an entire feature should or shouldn’t do from a two-line ticket filled with ten bullet points of acceptance criteria.
*Here are five prioritized tickets for the upcoming sprint. We have to ship them on time!*
On the other hand, you have teams who are able to build top quality software. They’re the ones who can concentrate on the fine implementation details without losing focus on the broader purpose of the feature as a whole.
Everyone wants to get to that level. But instead, teams do the exact opposite.
Teams think in issues and tickets, instead of the feature as a system.
Development teams are not ticket movers!
Today, everything is about moving a ticket from “Todo” to “Done” as quick as possible. And watching burndown charts. And customizing the tool to the extent that the developer only views a single ticket.
*“What’s the velocity of our team?” is simply another way of asking how quickly can my team move an issue from “Todo” to “Done”.*
Pieces of that stuff are important for productivity and shipping on time.
But seriously, how is your team supposed to ship anything of value if you narrow their focus down to the smallest unit of work without any context of why it’s needed or how it connects to the whole feature?!
Overall, we’ve lost our way. Product development today has become more about checking items off a list as quickly as possible.
It isn’t enough to write multiple user stories and share a Figma link if you want to ship quality software.
How software product teams really build software together
Development teams build better software together when they have the complete context of what and why something is being built.
To achieve this, the foundational elements need to change.
And it starts with getting the right abstractions and naming conventions.
The names you choose determine the perception and the quality of conversations you have. It’s why top developers spend time obsessing over names for classes, functions, and variables.
When you open up a VS Code and see a function called send_signup_email, you have a certain sense of what’s going to be inside and why that’s there.
The right abstractions can drive the team towards asking the right questions. And this is critical.
Because when you’re tracking issues and tickets in isolation you have no choice but to measure only outputs.
And teams today don’t want to measure only the outputs. They want to measure outcomes.
What’s the right abstraction?
The right abstraction is the one that prioritizes people over processes and tools. It's the one you and I use every day — it's Features.
When a squad creates a Feature and opens it, they’ll get to look at the entire feature as a unit. A user story inside it might describe a specific functionality. But the difference is, now each developer and designer know how it connects to the larger scheme of things for the entire feature.
A feature forces inept managers to stop focussing on output-oriented questions like “how can we work faster”.
And shifts the focus on outcome-oriented questions like “why should we prioritize this feature” and “how does this feature tie to the OKR”.
Miscellaneous tasks and incoming bugs can be tracked on a separate “List”, so high-priority bugs don't get missed out. And of course, when it comes to tracking them, they can all be tracked on a Sprint or on a Kanban Board.
Feature as an abstraction is the right middle ground that lets you focus on the output as well as the outcome. It lets you zoom in and track what's happening today. It also allows you to zoom out and track a feature's progress across multiple disciplines. And it enables you to see how a feature moves from a feature request all the way to prioritization and development.
Simple issue trackers and project management tools have shoehorned teams into ticket-movers and have made them think in outputs. Metrics get feigned to show productivity. Thinking in outcomes has become ridiculously hard. And it's hurting businesses.
It's time for tools to reflect the reality of product development. It's time to remove the disconnect between development teams and what your customers really want.
It's time to stop thinking in isolated tickets and start thinking in features as a system!
If you liked what you read, I think you’ll love what we have in store for you. Go ahead and try Zepel for free.
Top comments (0)