HOW TO CREATE A LONG-TERM BUSINESS WITH TECH-PRODUCTS_ Principles of Strong Product Teams_The TEAMWORK

Principles of Strong Product Teams

To continue with the principles of a strong Product team as I mentioned in the 1st Part, in order to have successful long-term business with Tech products the most important thing is to have THE RIGHT PEOPLE. And for that you must first build a strong team. Once the product team is defined the next step is to make it work.

The most important role is played here by the Product Manager who must empower the team and cascade meaning in the team. I say it again there is NO Hierarchy here, the Project Manager is NOT the BOSS of anyone, but he is the responsible to the entire product so his task is also to make sure that each team member knows WHY they do what they do. So let’s see in how this should done. The next 5 similarities about Teamwork is my conclusion based on my experience but I am pretty sure it can be applied for any project in any company.

Group II: TEAMWORK

1. Team Empowerment and Accountability
2. Team Collaboration
3. Team Location
4. Team Scope
5. Team Autonomy

1. Team Empowerment and Accountability

A big part of the concept of product teams is that they are there to solve hard problems for the business. They are given clear objectives, and they own delivering on those objectives. They are empowered to figure out the best way to meet those objectives, and they are accountable for the results.

2. Team Collaboration

A product team is a set of highly skilled people who come together for an extended period of time to solve hard business problems. The nature of the relationship is more about true collaboration.I don’t mean collaboration as a buzzword, either. I literally mean product, design, and engineering working out solutions together.

The distinction must be very clear and it’s very important for you to understand that this is not a Hierarchy.

3. Team location

I also haven’t said anything yet about where the members of the team are physically located. While this isn’t always possible, we try very hard to co-locate this team.

Co-location means that team members literally sit right next to one another. That doesn’t mean in the same building or even the same floor. It means close enough to easily see each other’s computer screens. I know this sounds a bit old school, and the tools for remote collaboration are getting better all the time, but the best companies have learned the value of sitting together as a team. If you’ve ever been a member of a co-located product team, you likely already know what I mean. How we do our work on a product team, there is a special dynamic that occurs when the team sits together, eats lunch together, and builds personal relationships with one another.

I’m aware this can be a bit of an emotional topic. For personal reasons, quite a few people live somewhere other than where they work, and their livelihood depends on working effectively remotely. I don’t want to paint this as too black or white, but I also don’t want to mislead you. All other things being equal, a co-located team is going to substantially outperform a dispersed team. That’s just the way it is.

This is also one of the reasons why we greatly prefer members of a product team to be actual employees and not contractors or agencies. It’s much easier to be co-located and to be a stable member of the team if the person is an employee. Note that there is nothing wrong with a company having multiple locations, so long as we try hard to have co-located teams in each location.

4. Team Scope

Once you’ve got the basics of a product team, the next big question is this:

What is the scope or charter of each team?

That is, what is each team responsible for?

One dimension of this is the type of work to be done, and it’s important that a product team has responsibility for all the work – all the projects, features, bug fixes (in case you develop software), performance work, optimizations, and content changes – everything and anything for their product.

The other dimension is the scope of work to be done. In some types of companies, the product team is responsible for a complete product. But it’s more common today that the product is the full customer experience (imagine a Facebook, an Apple or a Samsung), and each team is responsible for some smaller but meaningful piece of that experience.

For example, you might be working on a team at eBay that’s responsible for technology to detect and prevent fraud or tools and services for high-volume sellers. Or, at Facebook, your team might be responsible for newsfeeds, an iOS native mobile app, or the capabilities required for a specific vertical market, or at Tesla where they must be sure the car can safely be driven autonomous.

This is an easy topic for a small startup, as you typically just have one or a small number of teams, which makes it relatively easy to split things up. But as a company grows, the number of teams expands from a handful to 20, 50, or more teams in large product companies (like Samsung for example). The coordination gets harder, but the concept is highly scalable and, in fact, is one of the keys to scalability.

There are lots of useful ways to slice up the pie. Sometimes we have each team focus on a different type of user or customer. Sometimes each team is responsible for a different type of device. Sometimes we break things up by workflow or customer journey. Sometimes, actually very often, we are largely defining the teams based on the architecture. This is pretty common because the architecture drives the technology stack, which often requires different types of engineering expertise. In any case, what’s critically important is alignment between product management and engineering. This is why the head of product and the head of engineering normally get together to define the size and scope of the teams. I will tell you there’s never a perfect way to carve up the pie. Realize that, when you optimize for one thing, it comes at the expense of something else. So, decide what’s most important to you and go with that.

5. Team Autonomy

If we want teams to feel empowered and have missionary-like passion for solving customer problems, we need to give them a significant degree of autonomy. Obviously, this doesn’t mean they can go off and work on whatever looks fun, but it does mean that they are able to try to solve the problems they are assigned in the best way they see fit. It also means we try to minimize dependencies between teams. Notice that I said “minimize” and not “eliminate.” At scale, it’s just not possible to eliminate all dependencies, but we can work hard to continuously minimize them.

Why It Works

Product companies moved to this model of product team (based on TEAM BUILDING and TEAM WORK as just described) several years ago, and it’s now one of the pillars of modern, strong product organizations. There are several reasons why this model has been so effective.

1st– collaboration is built on relationships, and product teams-especially co-located teams-are designed to nurture these relationships.

2nd– to innovate you need expertise, and the durable nature of product teams lets people go deep enough to gain that expertise.

3rd– instead of just building what others determine might be valuable, in the product team model the full team understands-needs to understand-the business objectives and context. And most important, the full team feels ownership and responsibility for the outcome.

Instead of the old project-oriented model, which is all about getting something pushed through the process and out the door, in the dedicated team model, the team is not off the hook just because something launches. They don’t rest until and unless it’s working for the users and for the business. Hopefully you’re already a member of a strong, dedicated product team, and now you just have a better appreciation for the intention of this model.

On the other hand, if your company is not yet set up around dedicated product teams, this is probably the most important thing for you as a leader to fix. Everything else depends on this. You don’t have to move the whole organization there at once – you can start a team as a pilot. But one way or another, it’s essential that you create or join a durable product team.

Principles and Techniques

The product managers must clearly understand the underlying principles of WHY we need to work the way we do. When a person reaches the point that they have a solid understanding of the principles, they develop a good mental model for when each technique is useful and appropriate, and when it is not. Further, as new techniques emerge, they are able to quickly assess the potential value of the technique, and when and where it is best utilized. Of course over the years the techniques change fairly constantly, the underlying principles endure. So, while it may be tempting to jump right to the techniques, you must first consider the principles, and work to develop a deeper understanding of how to build great products.