Mobile app - separate product?

Last post 04:26 pm October 9, 2020
by Ian Mitchell
7 replies
Author
Messages
11:26 pm October 8, 2020

Long story short, we are building a Web based product, but we also have a React Native App for that.

We have different timelines for that, so while for example the Web application is in "version 3" development phase, the React Native App is behind and we are building "Version 1".

The React Native App is just a mobile version and doesn't introduce any new functionalities, apart from being mobile App.

 

Now.. do I have 1 product here and should use one Product Backlog for that, or perhaps these are 2 separate products and should have 2 separate backlogs?

04:48 am October 9, 2020

Now.. do I have 1 product here and should use one Product Backlog for that, or perhaps these are 2 separate products and should have 2 separate backlogs?

@Bartosz Krawczyk, This is a very interesting question, and thanks for asking. Honestly, it made me think a bit. My opinion is that it is still a single Product and hence would require a single Product Backlog.

My reasoning is based on the below excerpts from the Scrum Guide particularly the areas I've marked in bold.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.

The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Based on the above, my thoughts are that the mobile app is an extension of the same product. It can be considered a feature/enhancement that will help it become competitive and useful. Hence, it will be part of the same single Product Backlog.

Hope this helps.

PS: I'm also curious to see the perspective of others.

04:58 am October 9, 2020

Identifying product boundaries can be challenging. I don't think there's one right answer, but here are some things you might want to consider (for now I'll refer to the potential products as 'components'):

  • Are the value and cost of these components being accounted for separately?
  • Can both components still represent value if the other is removed from the market?
  • How might these components diverge in the future, and how important would it be to avoid divergence?
  • Are there any shared dependencies (e.g. codebase) where changing one component will require a change in the other?
  • Would it make sense for the definition of "Done" to differ for these components?
  • How much overlap is there between the stakeholders of these two components?
  • Do you have separate Scrum Teams working on each component?

 

05:33 am October 9, 2020

Now.. do I have 1 product here and should use one Product Backlog for that, or perhaps these are 2 separate products and should have 2 separate backlogs?

Should they be inspected and adapted separately, so the value of each can be independently optimized?

10:10 am October 9, 2020

Another possible consideration is that you have 3 products. If you have a web application and a mobile application, you probably have APIs, server-side logic, and infrastructure (a back-end, if you will) that is exposed to users through either the web or mobile front-end. If the back-end doesn't support a given (functional or non-functional) user need, then it could block work in either front-end.

I think that the questions posed by Simon Mayer are good for determining if you have 1, 2, or 3 products. I'm not sure that I would consider separate Scrum Teams working on each product, though. Although it's best if each product is supported by a Scrum Team, that isn't always feasible, especially in very small organizations. From a product management perspective, though, considering the work as separate products early would let you scale the organization as you can support multiple teams.

10:23 am October 9, 2020

I like to use examples, how do you think i.e. facebook manage their service with messenger? Do you think that it is rather managed as one product with a huge backlog, or is it rather separated as different products that are exclusively tightly connected to create synergy? I do not know this, but I imagine that the second approach seems logical, that despite some connections, each of these things (facebook site and messenger) can be considered as a separate product.

As Simon Mayer said, it can be challenging to define such boundaries. IMHO even if there are some shared parts in the codebase, often taking the situation in hand as one monolithic product lead to unnecessary complication and overwhelming process, that could be avoided by treating the same situation like a bunch of products (aka companies) that wants to cooperate and create synergy. Another example may be the automotive industry, where different brands share know-how and parts, despite offering different products (cars) that also compete with each other (i.e VW Group)..

02:28 pm October 9, 2020

@Simon Mayer, you ask 

  • Do you have separate Scrum Teams working on each component?

Independent of the answer, you can also have several Scrum Teams working with the same PO and same PBL. I think the question if they are dependend is a good one, because if both use the same backend or the web-app has some transfer classes, the mobile-app is depending on what the web-app is providing and then it should be managed centrally.

 

And @Ian Mitchell asked

Should they be inspected and adapted separately, so the value of each can be independently optimized?

That can also be done with the same PO and PBL in seperate teams, couldn't it? The PO can adapt the web-interface to allow user administration, which will not be done in the mobile-App. Or he prioritizes some functionality in web while in mobile a different thing is implemented, as the usage of both apps are different. 

04:26 pm October 9, 2020

That can also be done with the same PO and PBL in seperate teams, couldn't it? The PO can adapt the web-interface to allow user administration, which will not be done in the mobile-App. Or he prioritizes some functionality in web while in mobile a different thing is implemented, as the usage of both apps are different. 

I'm finding that arrangement hard to visualize, so I'd suggest that transparency might not be optimal.