How the WSJ iOS Team Promotes Cross-Team Collaboration Through OKR-Driven Feature Requests
Earlier this year, some colleagues on the Wall Street Journal Revenue team found the perfect tool to help them ramp up their advertising efforts, but they needed the WSJ iOS team (my team) to implement the tool’s software development kit (SDK).
While it seemed like a simple request, we soon uncovered multiple red flags, including a potentially huge performance hit to the WSJ app due to the massive size of the SDK.
After more than three months of back and forth between our teams, we concluded that the SDK did not have to be implemented in its entirety. One very basic function included in the SDK was all we needed.
Both teams were happy with the results, but it took an unnecessary amount of time to reach this simple solution. While we enjoyed the extended span of collaboration, our team wondered the age-old question: “How can we get to the same result faster?”
In an effort to improve cross-team collaboration, the WSJ Product, Design and Engineering (PDE) group has been implementing Objectives and Key Results (OKRs) — a popular methodology that encourages measurable, team-oriented goal setting by which individuals set objectives that support team objectives, which ultimately help drive company objectives.
To give some context on the scale of these PDE OKRs, below is a rough diagram of the overall PDE group at WSJ.
While OKRs were proving to be extremely successful in terms of overall PDE, there was a lack of translation to the feature level. My team and I recognized the intention of the Revenue team’s request, but didn’t fully understand its value or why it was important.
Acknowledging this lack of focus on feature-level details, my team began experimenting with using OKRs on a product-level for feature requests. Since then, we’ve seen some fantastic benefits, including better collaboration across teams, easier objectivity in prioritizing feature requests, and better-vetted features.
Now, when another team wants to collaborate on a feature, we ask that team’s product owner to align the request with the PDE-level OKR, as well as the objective and expected key results of the specific request and how they be measured.
By addressing these questions:
- Teams ensure that they’re considering department-level goals
- Everyone involved in the feature request (from Engineering, to Design, to Product) understands why the feature is desired through the defined expected results
- All of PDE can better brainstorm alternative options to meet those same results
Still unclear? Let’s look at a hypothetical scenario: A product owner asks the WSJ iOS team for a specific feature, namely, to “Add a new intro video that shows where notifications live in the app.” Our template would look something like this:
Feature Request: Add a new intro video that shows where notifications live in the app.
PDE Objective: Make the readers experience engaging.
PDE Key Result: Increase the number of readers who have at least one notification alert for either the iOS or Android app, from 10,000 readers to 12,000 readers by the end of the 3rd quarter.
Feature Objective: Encourage readers to sign up for the notifications that they care about.
Feature Key Results:
- Increase the number of readers that have at least one notification turned on for the WSJ iOS app, from 5,000 readers to 6,000 readers by the end of the 3rd quarter
- Increase the number of readers who have visited the notification settings in the 3rd quarter, from 10,000 readers to 12,000 readers
- Reduce the number of customer service tickets requesting help with notifications in the 3rd quarter, from 200 to 100 tickets.
When we bring these OKR-driven feature requests to the wider team, a beautiful collaboration unfolds. The designer may say, “If we want to get more readers to the notification section, it would help to update the icon to be more noticeable and intuitive.” An engineer might then speak up and say, “Since we want to target certain readers, we can make the app show the notifications onboarding screen again for those readers without notifications on.”
By promoting OKR-driven feature requests, we’ve started to encourage a different perspective so that teams collaboratively consider the underlying value of requests instead of just the requests themselves. Feature request discussions become concise and directed, and the mentality of “throw the feature request over the fence and wait for it to be complete” becomes obsolete.
We plan to continue to iterate on this method so we can make our cross-team collaboration even better in the future.