The product team 1/3: Working with the internal team.
I’m starting a course of articles on interacting with the development team. This is an important reason, since the product manager has to interact with his own team, with the external development team, and with related development teams from day to day. The first article will focus on the internal team.
- Find out what functions each team member performs.
- Let’s see what types of teams there are.
- Let’s find out what difficulties there are in working with a team.
- Let’s talk about the sprint lifecycle.
Main roles in the team
You are a product manager, you need a team. Now I will tell you who it can consist of in web development. There are different sets of teams. These may depend on how complex the product is, how many users are in your product, and how the business processes in your team are built. Of course, there is also mobile development, but I think that after reading this part, you will not have any difficulties to assemble your team for it.
What does a backend developer do?
To put it very briefly and clearly — they programm everything that you don’t see on the screen. Applications, your website, program, project, etc.
In a more detailed way, it goes something like this:
- Transfers business logic to code.
- Works with frameworks.
- Writes in: C#, C++, Java, Python, Ruby, Node.js, PHP.
- Responsible for the “server” functionality.
- Creates the product API.
- Works with SQL and NoSQL databases.
This person is well versed in at least one programming language — the one that your project is written in. It can transfer business logic to your code and understand the context in which it is executed. They can write integration to suppliers, such as a logistics company or bank.
They can work with databases, write queries to these, and program stored procedures.
They work with the server part of the code, deploys the code to production — put the executable code on the “combat” server where your application is running.
They write technical documentation, if necessary. Unit tests, integration tests, and others are also their responsibility.
What does a frontend developer do?
A frontend developer handles everything you see in your app or program. Everything you interact with with your hands: buttons, drop-down lists, clickable images. They create the client part of the application. A frontend developer deals with the layout of the website, creation of user interfaces.
Sometimes they do part of the backend logic in the frontend, such as programming the cart logic in an online store: recalculate the number of products, apply a discount, add a delivery address.
They interact a lot with the designer, as they need to transfer the layout that the designer drew to the programmable template.
As a rule, frontend developers are much happier than backend developers, as they deal with beautiful layouts and design. If your job is to spend the whole day looking at female models on the site, and not just at the numbers on the screen, you will be happier.
Front-end developer also works with frameworks — sets of ready-made tools that are already created by other programmers. This allows you to save time and make projects faster.
What does a full-stack developer do?
Everything you need to know about the full-stack developer: it does the same thing as frontend + backend, only worse. Of course, there are exceptions to any rule, but this is usually the case.
A full-stack developer can save you a lot of development time at the beginning of a project, but then you will want to share this role anyway, as you will need deep expertise.
What does a system analyst do?
The main task of a system analyst is to reduce uncertainty for the team. It should proceed from the “how can I help?” paradigm.
This specialist works with three levels of abstraction: user, code (business logic), and data.
They create artifacts in the form of user documentation, technical tasks, user stories, diagrams, and any other documentation. They keep it up-to-date: makes timely edits, supports the versioning of the project they are working on.
As a rule, a system analyst works ahead of the curve: if the team does tasks in a sprint, the system analyst prepares the development of features for the next sprint. They can quickly answer questions about the current functionality of the app, as it is very well versed in it.
They can and should conduct customer interviews, create check-lists, to rank the priorities of the tasks. They can analyze the situation and offer the best solution. In many ways, they complement and facilitate the work of the product.
What does a UX / UI designer do?
The first thing they do is create the design of your app. A UX / UI designer draws layouts, prepares presentations (if necessary), for example, a presentation of a new feature. They are well versed in user interaction and usability. They can tell you where to place the button in the app or how best to implement the new functionality.
They work a lot with prototypes and a CJM map of consumer interaction with the product.
A UX/UI designer works a lot with front-end developers, since the layout doesn’t get into the design almost ever, and this is normal.
What the tester does (QA)
The tester tests your product for bugs and errors. They check whether the program is doing exactly what it should be doing.
As a rule, a tester, especially an experienced one, is very well versed in your application, since they are constantly testing different blocks of its functionality. They can tell you where, how, and what can be improved. This is the second most important person in the team after the system analyst.
The tester works in manual or automatic mode. The tester can simply go through user scenarios, noting errors in the checklist, or write an automatic test in which the machine will do it repeatedly for it.
What does a Scrum master do?
The main task of the scrum master is to help remove obstacles to the normal workflow.
They help you organize a sprint — a two-week development cycle, conduct stand-UPS, demos, and retro events. They are engaged in facilitation (conflict resolution) of meetings. It is based on the paradigm “not to find who to blame, but to solve the problem”. A scrum master updates the statuses of offline and online boards (Scrum/kanban).
They ask the right questions in meetings. For example, “What key opportunity do you want to get this week?” or “What exactly is the question?» They help the team stay focused on the task at hand and not get carried away.
They help you evaluate tasks and divide them correctly into atomic, i.e. smaller pieces.
A scrum master creates the sprint goal.
What roles can replace each other
The main thing to understand is that a single employee can have multiple roles combined. The larger the project and the more expertise required on the project, the more you will split roles between people, making them more narrow specialists. And vice versa: the smaller the project, the more different functions can be combined in one person.
A common situation is that programmers have already completed all the tasks in the sprint, and they have moved to the “testing” column. Can programmers test their tasks to help the tester complete the sprint goal in time? Of course!
Especially if they take tasks for testing that they didn’t do themselves. Let the piece of code that John wrote be tested by Alex, and vice versa. It is quite a feasible task for the development team to click the functionality on the checklist and mark the items that did not work.
At some point, you may find that you need to fix something minor in the code, the specialist is on vacation and is not available on the phone. The edit is usually minor — change the variable name, delete something, or add something to the database field. That is a trivial task, but critical right now. This can be done, for example, by a frontend developer in the backend and vice versa. It can be a DevOps or Linux administrator. You don’t need to be afraid of this and assume that this is some kind of rocket science.
The analyst can replace you for an interview with the customer. And the tester can draw a top-level layout of the feature. And this is absolutely normal! Get people out of their comfort zone sometimes. The main thing is not to turn this into a permanent rule.
What types of teams should you aim for?
There are two main types of commands.
The Growth team
It is responsible for testing and developing hypotheses. Usually, it is very small. It must include the roles of designer and frontend developer.
It’s like a personal mini-product team. This is your main area of influence. By creating such a team, you can speed up hypothesis testing up to 10 times. You should always strive to create a growth team within your business unit.
Core team
Usually, you start a project either without a team at all (a startup), or with an existing stack of employees. It can include all types of specialists.
The main goal of this team is to keep the product in working order. It implements already proven working hypotheses in the production code. It is aimed at working with technical debt — something that needs to be corrected, but there are always other tasks. This team can be very large, from 20 to 100 specialists, and is managed mainly by the head of the development Department or CTO.
Always strive to grow a separate growth team. It may consist only of freelancers, but its usefulness will be invaluable.
The life cycle of a sprint
So, you have assembled a team, and now you need the team to solve problems, but how will it do this, because its resource is limited by time. it is important for you to find those borders where the team will not be bored without work, and from the other side it will not burn out.
A sprint usually consists of several stages. You already have some kind of backlog. You created it from somewhere, for example, from tasks in Jira, plus you added your stakeholders ‘ wishlist and your own hypotheses.
It all starts with the team discussing issues from the top of the backlog. This is called planning poker. You remove the task from the top, and each team member (usually programmers and analysts) votes on how much it can be completed in business hours.
Then those participants who named a lower or higher number explain why they gave this rating. The total number is set by the General vote. For example, we have options 4, 4, 6, 8. Set the average-5.5 hours.
This is how the total capacity of the team is filled. It is taken from the calculation of 1/3 of the working time in a sprint. For example, we have a sprint of 2 weeks and 4 team members.
It turns out 320 hours: 4 people * 40 working hours per week * 2 weeks.
You only take a third of that time to sprint, which is about 106 hours. We usually take 112.
Each task that you discussed takes a certain number of hours from this amount. When there is no time left, the sprint is scheduled.
The remaining 2/3 of the time:
application maintenance: you can’t just cut features, you need to fix bugs;
other refactoring tasks — rewriting code fragments, optimization.
Believe me, developers always have something to do to make the code even better and the application more productive. If you don’t do this, you will have a very functional application that either doesn’t work at all or works very poorly.
Every day you gather at the same time for a General meeting (stand-up) and take turns answering three questions:
● What did I do yesterday?
● What will I do today?
● What difficulties have I encountered?
The Purpose of these meetings is not to hide problems and to know what the current state of the tasks of the entire team is.
After the sprint is completed, a demo is conducted of what has been done: finished functionality or code snippets. Everyone can come and ask questions about the sprint goals.
After the demo, a retro session is held. It involves only the members of the team. The goal of retro is to understand what was wrong in the last sprint, what can be improved, and what engineering solution can be devised for this. For example, we have no place to store documentation. Engineering solution: buy confluence.
After a day of demo or retro, it is advisable to take a one-day break. Just work on current tasks without sprinting. This allows the team to exhale and not burn out. And then everything repeats again.
What are the main difficulties?
For example, you join a new team and get ignored by one or more of its members. The best approach is to try to talk to each specialist individually in a calm, comfortable environment and find out what exactly you don’t like. Usually everyone has their own opinion on this matter and a person simply lacks some little thing in the work: a comfortable chair, an extra day off, it is pushed in the service, etc. Try to listen calmly and help your colleague solve this problem. Then you will have a full moral right to demand a more reasonable and constructive attitude towards you in return. This way you can quickly and easily identify the saboteur.
Not enough people
You always come to a new project where there is no team yet. You can use the services of freelancers for the first time and do some of the work yourself. Once the project starts growing, you can justify the need and start hiring a team. Most likely, the first one will be the backend developer.
A member doesn’t know to do something
It’s simple. If there is time and opportunity, teach. Send them to advanced training courses.
If not, look for an expert to help you and hire them for the project.
One of the members hides the problem
To avoid this, we need stand-ups. Try to create a comfortable, eco-friendly atmosphere in the team, where people are not afraid to speak out on any issue, are not afraid to make mistakes.
Nobody believes in the idea
Try to implement not the whole idea, but only a piece of it. Perhaps the idea is so cool that no one else understands its potential and scale. If you move in small iterations, followers will also appear.
Pressure from the CEO or other stakeholders
The advice is simple. If you are a beginner, resist, but not too much. You also need to gain experience and pass a trial period.
If you are an experienced specialist, then defend everything in numbers. The best argument is the financial result from a particular feature. If you can prove that backlog grooming is done correctly, you will most likely be heard. But even if you don’t, don’t get too upset. Sometimes you have to implement something that you don’t agree with at all. It’s part of the job.
The main goal of management
Artemy Lebedev said:”Solve the problem in the best way, without losing the meaning on the way.” Your task is to get from point A to point B by any means, without burning the team, because it is your most valuable and strongest asset.
You must practice a caring and eco-friendly management style, and people will pay you back with loyalty. They will stay an extra hour at work if necessary and offer much better solutions than if they work from under the stick.
You are the coordinator of your team. You must be a 3% psychologist, have a keen sense of the mood within the team, and do not pass by if you see that someone from your team is sad or walks around with a frown on their face. Look at everything from the human side, because we are all human and sometimes we all get into trouble.
If you haven’t subscribed to my telegram channel yet, now is the time to do so by clicking on the Product Monkey link. You can find a lot of interesting things there.(https://t.me/productmonkey). Every day I make posts about the most important things in product management.
If you want to learn more about team interaction, here is my course on Udemy. I created my own course on this topic, based on the fact that I believe that the product is built, including on relationships in the team.(https://www.udemy.com/course/interaction-with-the-product-team)
