Outcomes Over Output

Most Internet products are omnichannel, i.e., they operate websites, iOS app, Android app, publish on social media, etc. Yet, often teams are organized based on skill, channel, or sub-products.

For example, the Android app team, iOS app team, and website team are all separate. They have no direct connection with the editorial team. Similarly, the social media team is distinct from the push notifications team.

Everyone is responsible for a different part of the business. Product managers and editors don’t have teams of their own, but they lobby to gain resources from various teams to move their individual mandates.

Is this the most effective way to structure the team? This post argues not and proposes an alternative.

But first some terms

• Output is the stuff teams make to deliver value to customers; for example, the iOS team builds features in the iOS app, and editorial teams publish stories.
• Value is defined by how does an output help customers achieve what they want to do.
• An outcome is a change in customer behavior that drives business results.

Examples of desired outcomes for businesses include users logging in, sharing an article, and up- or downvoting a post. Customers can benefit from reading an article, saving time, and reducing inconvenience. Business results may include a higher Net Promoter Score, customer retention, increased revenue from existing customers, launching a new product, and decreased costs.

Why we structure teams by skill, channel, and sub-product

There are reasons why we prefer such an organizational structure.

First, it provides a sense of order. For example, one could draw a block diagram of the business. Each of these logical blocks – iOS, Android, Editorial, Website, Push Notifications – have a lead and a team. Additionally, people with similar skills are grouped together. All iOS engineers, for instance, sit together, separate from all editorial staff.

Secondly, operationally, it provides a sense of certainty. Each team specializes in producing output. The daily edit meetings focus solely on stories that will be published, without any other distractions.

Finally, leads create the entire roadmap or calendar in terms of outputs (features or stories). Each week, there is a ^^feeling of accomplishment^^ as these teams deliver outputs (features or stories).

Problems on this organization structure

• Managers with different mandates often compete for the same resources. For instance, each product manager or editor is responsible for a different part of the product, so they must all vie for the same developers, designers, writers, social media staff, and website space. This structure creates a zero-sum game between peers.
• With no means of unblocking the jam, gatekeepers get introduced into the system to bring order to the process.
• Negative feedback loops take effect. In a resource-limited environment, product managers and editors have to wait a long time for their requests to be processed. This leads to them packing their requests with as much as possible, causing other teams to wait even longer.
• Over time, roadmaps often become nothing more than educated guesses, as outputs require real execution by people and the availability of people can become uncertain.

An alternative way to structure teams for subscription products

Divide everyone into two teams. Each team should focus on one business result. The first team is responsible for acquiring new users, while the second team is responsible for retaining them.

The main benefit of this restructuring is that engineers, designers, and writers can now link their daily work directly to business results.

This structure requires each product manager and editor to focus on only one business result metric and consider how their skill, part of the product, or channel will affect this metric.

The roadmap is no longer a backlog of outputs (stories and features) with the hope of achieving business results. Instead, each output (story or feature) is an intervention or hypothesis to reach a milestone in the annual operating plan.

Let’s look at an example.

Business Results

It would start with the business results — an increase in acquisition or retention.

Mapping business results to outcomes

Let’s say we know or hypothesize that engaging people one-on-one increases the likelihood of them buying or renewing a subscription. From an analytics perspective, we can observe and measure this human behavior (attending events) and correlate it to acquisition or retention.

Mapping outcomes to customer value

The next obvious question is what kind of events would we cover? The answer to this question will vary for the acquisition and retention teams, as the value they offer customers differs.

The acquisition team would approach such events as a book launch: the event itself should be captivating, but customers would buy the book for more. Revealing everything from the book would make it redundant. Instead, the event should provide a primer on the topic, followed by a call to action to subscribe and read/listen to more articles.

In comparison, the retention team would use events to make subscribers rely even more on the brand and product. They could offer exclusive access not available elsewhere, such as revealing how an investigation was conducted, or providing Q&A access to star columnists. Alternatively, the event could be a listening session, where editors can hear what subscribers would like them to cover, or answer queries about a nuanced topic.

Mapping customer value to outputs

Finally, based on the value, the outputs for each of the teams — editorial, iOS/Android/Website, marketing, sales, operations — would vary.

—

In conclusion, this restructuring can transform the zero-sum game for resources into a team that observes and argues at the systems level.