Should feature teams be specialized by business stream?

Question

For context, The company provides a subscription for goods to both B2C and B2B markets. The B2B's distinctive aspects is that client require billing to be a lot more detailed, they oversee a lot more delivery locations and have multiple account managers. Their product is basically a reduced version of our backoffice, so that we can give as much flexibility as needed. The B2C get their own separate platform, which is focused on design and simplicity.

I'm new on the job as a Product Owner ; before I joined, there was this idea of dividing the developers (<10 people for now, albeit growing) and Product Owners (2) into two feature teams. The foremost proposition at the moment is to specialize the teams according to these two business aspects. The specialization wouldn't be absolute, but it's not clear how strongly it would be applied.

I think that's a better idea than component teams, since at least each feature team would be focused on customer value rather than technical requirements.

But I'm not really convinced top-down division like that is necessary. The work in progress is never perfectly balanced between B2C and B2B features, in fact the roadmap for the end of the year is almost 100% B2C. The developers' skillset and areas of interest don't neatly divide like that either, most of them have the most practice on the more complex B2B product. Internal tools, which broadly share the same components as the B2B product, do not feature in that division and could make the workload even more lopsided.

I'm not very familiar with feature teams best practices, but are they supposed to be specialized ? Versatile / agnostic feature teams, which would work on whichever feature they pull from the roadmap / backlog, make more sense to me. As long as each team keeps on working together on the long run, I feel like that's the part that would make the biggest difference.

Answer 1

The situation you are describing reminds me of a something Sir Ken Robinson said in a TED talk:

I saw a well-meaning policy statement that said 'College begins in Kindergarten'. No it doesn't, Kindergarten begins in Kindergarten. A friend of mine once said 'A Three-Year old is not half a Six-Year old'.

Seems the company has a vision of increasing their business and imagine how they will look like in some number of years. That vision means more people and splitting the B2B and B2C services. But they decided to start the split now, instead of later when it would be necessary (if at all). Basically they want to start college in kindergarten.

You have a small feature team. The team might contain all the necessary skills to do the work but most likely individuals have some specialization, like back-end developers, front-end developers, QA, designers, etc. Their contribution may overlap, but this specialization exists in most teams. If you split things in two, you will need all the skills in both places. I doubt you can do that with less than 10 people.

So you need to hire more people with particular skills to fill in vacant places. If your roadmap is almost 100% B2C then one of the teams will just have to sit idle. Companies don't usually like idle employees, so they will make them help the other team until they have something to do in their own area of expertise. And now you are back to square one, in the same format, but with more people.

This looks like a premature attempt to grow. I've seen this happen before and the result leaves much to be desired. The better approach is to grow organically, when needed. If at some point it makes sense to split the teams then do so, but don't force it before it's actually needed.

Answer 2

Based on the context you have shared, I agree that having separate teams for B2C and B2B might not be the most effective configuration. On the other hand, I would also not recommend "feature-agnostic" teams, as you put it, because they'd effectively function like project teams, and that's now recognized as bad for knowledge retention, architectural integrity, etc.

It looks like there are underlying, long-lived, business capabilities common to B2C and B2B. I'd explore the feasibility of organizing teams along those capabilities. The referenced experience report has some examples.

Answer 3

As you mention, I would question if any specialization is really necessary. Every situation is different, but in most cases, a product being maintained by less than 10 people probably isn't so diverse that you need teams that specialize in one part of it or another. Ideally, they would all be able to pull whatever work is most important.

Answer 4

TLDR: B2B/B2C split won't work for you. You'll need to work closely with the other PO.

---

So, let me just see if I've grasped the situation correctly:

• Your company has both B2B and B2C business.
• The B2B and B2C are not always anywhere approaching balanced
• Your department has 10 developers and 2 Product Owners (and 0 QA?).
• Someone (upper management? the team?) suggested to split the team in halves
• Someone (upper management? the team?) suggested to split along B2B/B2C.

Did I get that right?

---

Given the second point above, it's clear that splitting along B2B and B2C is not going to work in your situation. That being said, 10 people is kind of large for a team, so the idea to split itself has merit.

You worry about

The developers' skillset and areas of interest don't neatly divide like that either ...but honestly, in my view, that's not really a problem. Teams should be cross-functional and developers should be T-shaped. You could even consider periodically swapping around membership of the two teams, to facilitate knowledge sharing.

If you had only one Product Owner, it would be simple (if a bit high on workload for that one PO) - have the PO direct both teams, making sure they both have an appropriate amount of work that suits their skillsets and recent projects, without paying particular regard to whether the work is B2B or B2C.

But you have two POs. Given that you're one of them (and, being new, the more likely one to be removed), I don't suggest changing that.

But you will have to coordinate closely with the other PO - The two of you will nee to effectively function as a single entity, at least for deciding how to split workload. Exactly how it's split doesn't matter nearly so much as the fact that both of you must agree to how it's split.