Never disappoint customers: 3 essential rules to build better software features
What is the desired outcome for a software product team?
Completing as many tickets as possible? Or shipping a feature that your customers want and move the needle for your business?
The answer, I’m sure, is the latter.
Today, more software updates are being shipped than ever before. Unfortunately, only a few have an impact.
Features you ship need to make an impact and be frequent enough to build relationships with hard-won customers.
That’s a lot riding on the quality of the software you ship. And not many teams realize that.
If you want to avoid underwhelming your customers, be sure to follow these three rules when building software features.
Rule 1: Building features is not about checking off tickets
It shouldn’t come as a surprise that building features aren’t about checking off tickets and tasks in your issue tracker. But you and I end up obsessing about it anyway. And get disappointed when the software you ship isn’t up to the mark!
It’s why 56% of managers are looking to switch their project management tool every year.
At Zepel, we don’t start by assigning tasks. Doing this gives each member only a disconnected piece of the entire feature. It’s the equivalent of micro-management.
Building with tickets and tasks gives your team only a disconnected piece of the feature.
We think software teams do their best work when they have the whole picture. And not with isolated tickets.
Instead of giving small isolated chunks, the team is given a feature document. It contains a detailed spec with user stories on what the feature should or shouldn’t do. That way, the team knows what the user is trying to accomplish with the feature.
From here, it is up to the team to decide how they build it. The developers and designers know the details and have all the information they need about what the feature should and shouldn't do. They're in better position to make the right decision.
After all, the development team is the one doing the real work.
A manager may come up with what looks like a solid plan with assigned tickets and issues.
However, it rarely matches the reality of software development.
Rule 2: Progress of the feature is more important than the task
Far too often we miss the forest for the trees.
On one end you have people obsessed at getting every pixel right. And on the other end, you have folks whose focus is shipping as quickly as possible.
*Our velocity chart is dropping. We need to find a way to ship faster!*
Both are dangerous. And they’re both a consequence of thinking in outputs instead of outcomes.
At Zepel, we look at building software features as a balancing act between the known and the unknown.
Work items in the known bucket are much more reliable. You’ve already figured them out or you have experience doing it. These are the ones you can ship quickly. The unknowns require more research and have questions that need to be answered.
The realities of software development is rarely straightforward. There are far more unknowns than knowns when you build software.
So, if the unknown work item isn’t going to move the needle and you’ve spent considerable time doing research, it’s important to keep it aside.
And when you’re faced with a situation where you can’t make a decision, ask yourself: what new information is needed to make a decision. If you’re unable to identify it, it’s best to move on.
It's normal to feel like you’re making a compromise at this point. A good approach is to ask yourself: is what you're building a step up for your customers from what they're used to? If the answer is yes, then you shouldn’t sweat too much about it.
Rule 3: People over processes and tools
It doesn’t matter if you’re following agile methodologies. It doesn’t matter if you’re using a sophisticated scrum tool or a kanban software. If your team members are unhappy, your processes and well thought out charts are as good as an air cooler in Antarctica.
Designers and developers want to do their best work. They care about having a consistent design language, great experience, and having a cohesive code base that covering all edge cases. They take pride in their work and that’s important.
The best development teams keep the broader purpose of the feature in mind while focusing on the finer details.
The reason why most teams aren't productive is because these processes are too rigid. They hinder them from gaining complete context for them to do their best work.
Instead of trying to fine-tune the process further, it helps to shift the focus towards people. In practice it looks like this:
- Clarify goals frequently and realign people towards the goal: It’s easy to get caught up in completing a task and the finer details, forgetting the goal — ship a usable feature.
- Set and reset expectations: Most of us set expectations at the beginning. But it’s equally important to reset them after a checkpoint. Every time you set and reset expectations, it’s an opportunity to reinforce and steer the team towards the goal.
- Consistent check-ins: Check-ins do not only mean daily scrum meetings. Just asking a colleague if they need an outside perspective can go a long way in helping them do better work.
Product development: Focus on the result
Product development by its nature is different from issue tracking. People agree that the idea of building features by tracking one single ticket at a time is absurd. And yet, you still do it day-in and day-out.
This comes when you focus on outputs instead of outcomes. And when you’re limited by the tools you use. They make you put processes and tools over people.
There was a time when simply checking off tasks was all that mattered. It’s important. But in a demanding market with demanding customers, shoehorning developers into ticket-movers isn’t nearly enough to build solid products.
Instead, focus on the result. It enables you to think of the different ways to achieve the outcome and the multiple cases you would’ve missed had you spent time by thinking in tickets.
If you liked what you read, I think you'll love how we're re-thinking how project management tools and issue trackers should work at Zepel. Have a peek over here.