One Weird Trick For Focusing Product Development

The life of anyone trying to manage product development feels like standing in front of a firehose: there’s a constant stream of requests from customers, technical support, sales, and other stakeholders, which often arrive in the form of specific requested solutions or features. I’ve found that if a development team is asked to implement a specific solution, it’s often met with one of two reactions: they throw up their hands and say, “That’s crazy. There’s no way we can do that!” or, worse, they go to heroic efforts to deliver exactly what you asked for, even if it’s not the optimal approach.

If, instead, you tell the team the reason behind the request and make it clear what it is that the user needs to be able to accomplish, they’ll often come up with an innovative solution that both solves the problem and fits within the architectural and technical constraints of your product. As the new Technical Program Manager for TextNow, part of my job is to help everyone see beyond the tactical requests — I need to teach them to ask why.

How I prioritize a backlog

The first step in understanding the bigger picture is to have a picture to start with. Our teams use various iterative processes to manage incoming requirements — a product backlog. A backlog consists of a combination of bug reports, necessary technical work, and user stories describing features that different stakeholders believe will bring value to the product.

In my role, one of my responsibilities is to make sure that the backlog is prioritized and clear, so the development team can focus their time and energy on our most critical needs. User stories are supposed to be short, simple, and focused on needs and wants. When story authors cover these points, their stories are easy to evaluate and rank.

But sometimes authors and stakeholders leave out critical information. As an owner of the backlog, it is in my interest to either fill in or make the stakeholders fill in these blanks so that weak suggestions are weeded out of the development process and good ideas don’t end up at the bottom of the list.

Look for the why

There are lots of resources out there where you can learn how to create small, demonstrable, testable user stories that implement vertical slices of shippable software. I want to focus on something else, here. A good user story describes a problem area and explains why it needs to be addressed. Too often stakeholders leave out this information and jump into the mechanics of the feature (the how/what part). When this happens, I have to ask the right questions to dig deeper into the needs, so that I can work with everyone involved to agree on a description of the feature that explains why it is needed.

The archetypical user story looks something like this:

As a [role], I want [feature] so that I can [reason].

Many story authors skip the reason, resulting in user stories that describe features or functions, without giving the implementing team any indication as to the problem they are trying to solve. Focusing on the why forces me to think critically about the value of a request — I must either come up with a statement that is easy to prioritize, or conclude that a story idea really might not have much merit. Either outcome is a plus for the person who is planning or managing a development sprint.

What this process looks like

Problematic stories often express an idea using implementation or requirements language. For example, imagine that you were a developer working on Google Sheets. You may have a requirement that

The user can save their changes.

This could also come in as an implementation request, like

The view should have a blue save button in the toolbar.

Neither statement gets to why. If I rewrite the statements into our desired story format, it looks like this:

As a user, I want to be able to save my work so that I don’t have to worry about my changes getting lost if my browser crashes.

This statement both identifies the problem and explains why the user cares about this problem. By leaving out the how part, I can allow the development and design teams to do what they’re good at: use their expertise to come up with an optimal solution for saving changes.

One solution might be an explicit save button, but it also could be an auto-save function similar to the one that Google Sheets actually provides. Giving the team the freedom to problem-solve generally leads to better results, as long as they genuinely understand the problem.

So… don’t ignore the why!

When you don’t answer the why, you can easily fall into any number of development traps, including: accepting more stakeholder requests than can be accomplished during a particular sprint or changing direction based on feedback that really has little value to the organization. Even if the product doesn’t go completely off the rails, staying focused on “why?” helps avoid ending up with a backlog that focuses on delivering features that aren’t really solving problems that anyone cares about.

So remember, a good backlog, with a well-understood purpose, is essential for keeping development work on track. Ignore the why at your product’s peril.If you want an inside look at how we solve problems and build products that help people communicate, check out TextNow’s engineering job openings. We’re growing in both San Francisco and Waterloo.