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:
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.
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.
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:
Let's assume a company starts out something like this before they decide to add mobile into the mix:
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:
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.
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.
This is the first version of building a mobile SDK team that starts to give priority to mobile innovation:
As a result of having dual responsibilities, teams like this switch or split focus:
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.
This organisational model is a large investment in mobile innovation in addition to being central to the rest of product offering.
Here, the responsibilities of the mobile product team are that:
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.
The key things to do to know if you're ready to build mobile SDKs, and be successful if you do, are: