I’d bet a nickel that most successful tech companies don’t have any problem coming up with things to work on, features to build, or products to launch. To the contrary, most companies probably have more of those things than they could ever have time to ever build—and RTX Platform is no exception.
Unfortunately, a backlog of things to do does not a successful product make. What a backlog does do is distract. We’ve got 50+ tickets for RTX Platform alone, and that’s just one of our products. Tickets range from the big (build a mobile app!) to the minuscule (bigger buttons!). While we’d love to get to do all these things at once, it simply isn’t feasible. Building new features always takes a backseat to issues that affect our partner relationships, our core functionality, or our bottom line.
So, with a surplus of features and a deficit of time, what is one to do?
There are a number of methods we use to prioritize new features at RTX Platform, but ultimately every method boils down to three key questions:
User Experience
Ashley, our Community Manager, logs every feature request we get and categorizes advertiser support tickets by topic. Every week, she presents those records to the Product Team. During that presentation, the team is looking for two things:
Any significant increase in support requests is extremely valuable information. Oftentimes, they mean we’ve introduced some kind of ambiguity or confusion into the platform and that we need to reconsider recent changes and search for where they might be misinterpreted.
When we get these requests, we add them to a list of features to investigate, and we keep track of how often we hear them. After all, the easiest way to to find out what our users need is by listening to what our users tell us they need.
The next step in the pipeline is executed by Bernie, our Lead User Experience Engineer, and Jack, our Product Manager. Bernie and Jack write user stories that suggest how a feature will be used by a particular user of our platform. In a previous post on the 50 blog, Jack wrote about personas. User stories are written with a persona in mind:
“As Max, I want the capability to quickly view my least profitable campaigns so I can effectively allocate my funds.”
or
“As Bob, I want to know exactly when to use server-to-server tracking and when to use JavaScript pixels so I can track conversions and optimize my campaigns with the most accurate data.”
The user stories are written directly on the issue ticket, so when we consider the feature further down the line, we know exactly who it will benefit, how it’ll be used, and why users might need it.
Business Impact
Once a potential feature has a user story, it’s time to consider a “business story”. Will adding the feature help one user, but hurt another? Will the feature increase revenue? Could the feature cause a security risk? How does the feature fit into the overarching product roadmap?
It is important to remember that one particular persona is not the only persona affected by a new feature. Take this user story, for example:
“A new affiliate marketer would like very detailed, multi-page, wizard-type campaign-creation functionality, which explains each step of the campaign-creation process along the way with examples, recommendations, and tips.”
When evaluating this, Bernie and Jack may realize a couple of things: First, this might be great for a new user, especially when they first join the platform. Two, this could be beneficial for Ashley and the Account Managers because it would ideally cut down on support tickets from new advertisers. Three, this has the potential to be quite frustrating for a more experienced affiliate marketer because that user might make several campaigns a day, and a multi-page creation process would slow them down. It also might become frustrating for the new marketer after the first dozen or so campaigns that they make once they’ve gotten the hang of things.
So, Jack and Bernie might decide to re-write the ticket in a way that makes more sense for all stakeholders, or they might decide that the ticket doesn’t make sense for the product right now.
Feature Cost
Once users’ needs have been considered and the business case has been analyzed, it’s time to think about what the feature will actually cost. What needs to happen for this feature to be complete? Almost always, these costs extend far beyond the initial development. On the engineering side, costs include installing or upgrading any third-party libraries necessary to build out the feature, refactoring existing parts of the codebase to accommodate changes, and, of course, long-term maintenance costs. Other expenses might include building onboarding or support documentation, training Account Managers, or communicating new changes with partners and users.
Finally, there’s also a hidden cost associated with each and every feature added to a product: Complexity. Even seemingly benign additions contribute to the learning curve and complexity of the platform. This alone isn’t a reason to not build something, but it’s definitely a cost that must be considered with every addition.
Pulling It All Together
At this point, features in consideration have been broken down and examined in terms of the user experience, the business needs, and the feature cost. More than likely, some potential features have been thrown out along the way because they’d detract from the user experience, wouldn’t have a compelling business justification, or would have cost too much. Potential features have also been broken down into subtasks detailing every step that needs to happen before the feature can be released.
Now it’s easy to put all of this information into a matrix:
|
Feature
|
User Experience
|
Business Impact
|
Cost
|
|
Feature A
|
…
|
…
|
…
|
|
Feature B
|
…
|
…
|
…
|
Unfortunately, this is where the framework ends. The next step, of course, is sorting each feature by a score that incorporates each of the categories described. The weight of each category, though, depends on company and departmental missions and goals. Consider, for example, the following two mission statements:
Opera Software:
“We strive to develop a superior Internet browser for our users through state-of-the-art technology, innovation, leadership, and partnerships.”
AutoNation:
“To be America’s best run, most profitable automotive retailer.”
Clearly, Opera and AutoNation would put very different weights on different categories—and rightfully so. And, because each company defines product success differently, a one-size-fits all approach would inevitably lead to failure for one or both of them.
Getting It Built
What remains after prioritization is finding time in a given sprint to accommodate the top tickets—and following up. Every new feature that’s added should inform future features: Was the cost estimation accurate? Did users use the feature as much as we expected? Did the feature affect the bottom line? Checking back after implementation to verify assumptions is important because those same assumptions can (and should) be used again to inform future features. If an assumption is wrong for one feature, it will probably be wrong for subsequent features, too.
So, let’s review: When prioritizing features, listen to your customers. Find out what they want and what they’re saying. Evaluate how features can affect their experience, and then consider how those same features will affect the business as a whole. Is there a compelling reason to build something? Next, look at all of the new feature costs, including the hidden and long-term expenses. Using that information, sort issues according to your company and department goals and objectives. Finally, build the feature and verify your assumptions so, next time, your prioritization is as effective as it can possibly be.
Interested in working for RTX Platform? Check out our Careers page for our latest openings.