Mathew Cropper

Operating models for mobile teams

Operating models for mobile teams

Building great products is hard. Translating your understanding of your customers' needs into a solution, and then delivering on that idea, can be tough. Along the way you'll make trade-offs because of the constraints you live under.

This post is about some of the typical operating models and constraints that teams building mobile SDKs encounter. It's all about how product teams are structured within a company, how they decide what work they do, and what they're responsible for. It's how we choose to work.

These constraints impact the team's ability to act autonomously, understand their customers, move at speed, increase headcount, and feel satisfaction in their work.

In this post:

  • Investment
  • Before mobile SDKs
  • Operating models for mobile SDKs
  • Trickle down
  • Embedded
  • The switcher
  • Core product
  • Set up for success
  • Next

Investment

Deciding how much to invest in a mobile SDK depends entirely on the outcomes you want to achieve and the [potential] value of it to your customers and company. It also depends on how willing you are to live with the constraints that your level of investment brings with it.

On several occasions I've seen, both personally and through discussions with other Product Managers, that teams feel that they see something in mobile SDKs that the rest of the company is missing. They feel there's under-investment.

It's as much an understanding problem as it is a communication problem.

Having a clear mobile strategy is key to getting to the right operating model, organisational structure, team scope, and level of investment.

  • Understand your current operating model for mobile; how are you organised, how do you operate, what does it cost?
  • Build a strategy for mobile that includes:
  • The value that mobile SDKs provide to customers and the business today. Attribute revenue to the mobile SDKs.
  • A detailed understanding of the unlocked potential; customer needs, market opportunity, competitive analysis etc. Good strategy, bad strategy is a great read on this topic.
  • A clear north star goal or metric based on the strategy. Check out Amplitude's North Star Playbook for ideas on this.
  • Review your operating model based on the north star goal and strategy. Are you set up for success? What changes would improve things? What do you need to see to invest in those changes?

With that in mind, let's take a look at a few high level operating models for mobile SDKs and the constraints that come with them.

Before mobile SDKs

I'm looking at this from a very particular point of view; the impact on teams that build mobile SDKs. I'm also thinking about three main factors:

  • A team's ability to focus on customer needs.
  • A team's ability to focus on unique opportunities/needs for the platform they're building for. For example, you can do things on the web that you can't do in a brick and mortar store. There are unique limitations and needs associated with that. Mobile is no different.
  • A team's ability to actually build a solution for the needs they identify.

Let's assume a company starts out something like this before they decide to add mobile into the mix:

  • There may be several product teams. Imagine that a product team is autonomous; they have all the Product, Design, and Engineering skills that they need.
  • Each team has a clearly defined area of responsibility. It could be a whole product or a distinct feature of one.
  • They're all building with the web in mind. That's where all of their customers live at the moment.
  • Each team sits in the middle of the Venn diagram in the image above:
  • They understand their customers' needs.
  • They understand how building for the web impacts those needs or creates new ones.
  • They have the knowledge and skills needed to build solutions for those needs.

Operating models for mobile SDKs

It's not uncommon for autonomy to be the thing that mobile teams lack the most. It's not the first thing people think about, particularly if the need for the product is pressing.

There's a relationship between the level of investment in a mobile SDK and a company's organisational structure. There's no right or wrong here, necessarily. Investments and priorities will change over time. These structures often look something like this:

  • Trickle down: Product teams adding to a mobile Engineering team's backlog. A feature factory. Cheapest.
  • Embedded: Product teams gain autonomy by each having Engineers with mobile skills, but mobile-specific opportunities are neglected.
  • Switchers: Mobile SDKs as a first class product team, but with joint responsibilities; changing focus between mobile-specific opportunities and a feature backlog. Slow and reactionary.
  • Core product and capability: Mobile SDKs as a first class product team, driving the mobile SDK roadmap and direction, and other teams have Engineers with mobile skills. Right in the middle of the Venn diagram. Ex-pen-sive.

Trickle down

In my experience, this is hands down the most common way that mobile SDK teams operate. The team is an engineering team, not a product team, and they inherit a backlog of features from other teams. They're focused on shipping those features.

Why do this?ConstraintsIt's the cheapest option. The smallest version of this may be 2 Android Engineers and 2 iOS Engineers. Let's guess and say that's ~€280,000 a year in salaries.

It's the quickest to spin up. Hiring skilled mobile Engineers takes time, but not having to also worry about a Designer and Product Manager speeds things up enormously.

It's the least disruptive for existing teams. They can largely continue to operate as they do, translating web designs into mobile ones.The pace is slow. It's easy in this scenario for a large backlog of work to accumulate quickly. As a result, it's more likely that the mobile SDK will be immature and features will lag compared to the web product.

Solutions are unlikely to have been designed with mobile users/customers in mind. Expect 'web with a hint of mobile' in the product offering. The team lacks the time and skills to research and re-design every solution from a mobile point of view.

Quality is likely to be a lower (but not unimportant) concern. The team will take shortcuts in order to build more features more quickly.

This kind of team is unlikely to be focused on outcomes (ie. the value that was unlocked for those who use the feature). The team is, instead, a feature team.

Team turnover is likely to be high. This kind of work is stressful, unsatisfying, and people in this situation often feel undervalued. Hiring into the team is difficult. There is a clear human cost to this way of working, as well as a drag on the progress of the team.

Embedded

Some or all product teams get mobile Engineers of their own. There is shared or unclear ownership of the mobile SDK, and all teams contribute to it.

A mobile guild structure may form when people begin to step on each other's toes, but it's uncoordinated and more informal.

Why do this?ConstraintsMobile perspectives inform the understanding of customer problems and the design of new features. Features are likely to be more well rounded and appropriate.

This approach builds strong and deep understanding of customer problems and the limitations of building for multiple platforms.

Web and mobile can ship in sync with one another. Customers get a consistent experience and can rely on features being there across all platforms. The company benefits from being predictable.
This represents a significant investment. Following the same assumptions as the previous example, this would take our example company up to €840,000 per year in salaries.

SDK adoption is likely to grow linearly in line with web adoption. Without a driving force behind innovating for mobile-first customers and increasing adoption, it's possible that the cost of creating mobile features will outweigh the calculable business benefit.

With multiple people contributing to the same SDK, there's an increased likelihood of inconsistency and bloat. This becomes a more difficult product to use over time.

Depending on each team's plans, there may be times when working on features for mobile may not make sense.

The switcher

This is the first version of building a mobile SDK team that starts to give priority to mobile innovation:

  • A team with Product, Design, and Engineering skills.
  • A mobile-focussed strategy (innovation).
  • Dual responsibilities; execute on the strategy, enable other teams.

As a result of having dual responsibilities, teams like this switch or split focus:

  • If they switch, any one time they'll be doing something that contributes to the mobile strategic goal, or they'll be working on a new feature based on the work of another team.
  • If they split, they'll effectively run two teams. A strategically focused team, and a tactically focused team. They'll deliver features that originated in the team in parallel with features that originated outside the team.

Why do this?ConstraintsThe mobile SDK team has autonomy and direction. They are able to focus on outcomes, driving much more value for their customers.

There's a strong understanding of mobile-specific customer needs.Being responsible for outcomes is fantastic, but not being able to fully focus on that is disempowering. It can feel like an uphill struggle to see results.

It can negatively affect customer perception of the product when a team regularly switches between innovation bets and closing feature gaps. From their perspective, this option is actually worse than the 'trickle down' model; useful features come more slowly, and the company appears to be prioritising new features instead of the ones they've been waiting for.

Balancing time spent on mobile opportunities vs other feature delivery is challenging, particularly if the team is trying to course correct the SDK to align more closely with their strategy. Product feature gaps are no less important, but there's now an added scope. Sometimes they align, and sometimes they don't.

Features from other teams continue to be web-focused, and the team will fall prey to the same constraints as the 'trickle down' model when they're focusing there.

The core product and capability

This organisational model is a large investment in mobile innovation in addition to being central to the rest of product offering.

  • A mobile product team with Product, Design, and Engineering skills, and a mobile-focussed strategy (innovation).
  • Mobile Engineering skills embedded in other teams as well.
  • A guild, guided by the mobile product team, that unifies efforts, gains alignment, and shepherds development in line with the strategy.

Here, the responsibilities of the mobile product team are that:

  • They define and drive the mobile-focused strategy and vision.
  • They influence the direction of mobile work that goes on outside the team, in a similar way to a Design team. Designers might be embedded in teams, but they're also working on the company's ongoing design direction and incorporating it into their day to day work.
  • They own the mobile SDK, and set the tone for quality and user experience.

Why do this?ConstraintsYou get everything. Strong mobile direction, innovation, product consistency, all at speed.

Teams have clear ownership and focus on outcomes.

Most likely to lead to a mature mobile product.

There's a fully rounded understanding of customer problems.

The mobile product team takes on additional work to coordinate the direction of the SDK and ensure quality.This is an expensive model. To do this for the small company in the example would conservatively cost over €910,000 per year.

Set up for success

The key things to do to know if you're ready to build mobile SDKs, and be successful if you do, are:

  • Understand why you want to do it and what value it brings.
  • Be clear on the outcomes you want to achieve.
  • Be honest about the level of investment you want to make.
  • Design your operating model so that the team has as much autonomy as possible.
  • Openly acknowledge the constraints of your operating model, and take steps to mitigate them.