Building a product team

There are many ways to run a development team. Some teams (especially with agency work) just have a constant stream of tickets to do, spending their day getting any many things solved as they can. Other teams work from a roadmap or backlog of features and bugs, creating chunks of work that they try to schedule out. For my money (and time), the best type of team to work on is one that has the goal of constantly improving the product they make.

Types of development teams

From my experience, they are loosely 3 ways of running development teams:

• Big lists of tickets
• Agile sprints of bug fixes and features
• Product / outcome improvement

The reason for choosing one over the other depends on many things - experience / skills of team members, type of work, deadlines, and many others. Sometimes it is because management doesn't trust the team; sometimes the right pieces are not in place to do it any other way.

Let's look more specifically at each type, why they exist, and more about how they are run.

List of tickets

This is the most basic sort of team dynamic - there are a bunch of tasks that need to be done, and people to do them. Usually, members of these teams are solely judged on how many tickets they close. Frequently, the context for why something is being done is not given to the team member.

Another problem with this setup, from the perspective of the people on the team, is that they are not given problems to solve - only solutions to implement. This kind of team will mostly be spending their time in code, will be mostly (or all) developers, and will be given little idea how one ticket affects any other ticket. Luckily, most software development teams have moved off of this model.

Agile sprints

The next most complex team organization is that of agile sprints. Management gives a prioritized backlog of things to get done, the team decides how much can be done in a sprint, and commits to getting that much done. The sprints are usually between 1 and 4 weeks long, and at the end there is a concrete set of features and bug fixes that are completed.

This is the setup for a majority of teams today - both ones I have worked on and those of the people I talk to. The team is mostly developers, perhaps 1 designer, and possibly a product owner. The product owners responsibilities tend to be keeping the team focused on the sprint and reporting to management how things are going.

Product team

The most empowered type of development team is one focused on the improvement of the product they work on. Using the skills they have, they decide what will be worked on and when the work is finished. While this is the most rare, it is the best kind of team to work on; it usually produces the best product too.

Roles on a product team

On a good product team, there are 3 main roles a team member can have. Each of them is responsible for different part of the product.

Developer

This is the role most of us are familiar with. They are the ones physically writing the code, but that is not their only job. Developers are responsible for the technical viability of a product. They must determine how technical choices they make today might impact things in the future. Will taking this shortcut now cost us too much in technical debt in 3 months? Will choosing a certain architecture or language give us benefits in the long run? How long until those benefits outweigh the costs? These are all things the developers have to keep in mind as they do their job.

Designer

The designers are responsible for making sure the product is feasible from a usability standpoint. They determine how intuitive something will be for the user to use, how to structure the UI of the application to make obvious what is happening, and what steps need to be taken to make sure the product is accessible. The designers work with the developers to find reusable UI patterns to make the product consistent, as well as communicating with the product owner about experiences the user has had.

Product Owner

The Product Owner's job is to make sure the product is a viable from a business perspective. Is there a market for this product? Will it make money? Are there things the users would like us to do better (or at all)? Answering these questions is the focus of the product owner. They collaborate with the rest to solve problems that users have had, investigate other features that could be added, and do market research on other products of this type.

Building a good product team

Now, those descriptions above sound pretty cool, and working on this product team sounds really fun. But, how do we put together a team like this?

Trust

The first thing the team needs is trust. If you are not going to trust the people you hire to do what they were hired for, just stop there and go read something else. If you think this person is worth hiring, they must be worth letting them reach their full potential!

Let them solve problems

The jobs described above involve solving problems. Let your employees solve the problems they are an expert in! Don't come up with the solutions and ask them to implement them.

Measure on outcomes

No one want to be measured on number of tickets completed (or worse, lines of code written). Is the product better? Is it making more money, or grabbing a bigger market share? If it meets the outcomes outlined for the team, don't check how many tickets were completed to get there.

Empower the team

The members of a product team are the ones most knowledgeable about the product. Let them use that knowledge to make the product better. Give them opportunities to experiment and tinker - they might just find something no one else had thought of.

A great product team will create a great product - one that will be worth offering to people. Letting your product team do what they were hired for will make the difference between a disorganized product mess and a product users will be happy to use.