Aspects of A Well Oiled Product Team
How to go from “Good” to “Great”
It’s funny how your professional maturity takes you to see things differently over the years. Going back 13 years, my product team standards were based on pure performance supported by absolute metrics; more ‘output’ than ‘outcome.’ Fast-forwarding to the present day, my standards lay heavily on holistic, empathic, and value-driven approaches.
Over the last decade, I had the pleasure (and luck!) to work with exquisite people who built not only great products but also great relationships that brought their teams to the next level. In some scenarios, I was in the line-of-fire as a member (Developer, Business Analyst, Product Owner); in others, I had/have a supporting role for their accomplishments (Portfolio Manager, Head of Interactions).
Being “in” and “out” these teams brought me a 360º view of key aspects for a well-oiled product team. For the sake of this analysis, I’ll keep a stronger focus on Agile teams, mainly using Scrum on software development. Nevertheless, these aspects are ultimately universal, applied to any other framework trending.
Let’s take a look at what such teams do better to succeed:
#1: They foster diversity
Regardless of the ecosystem, diversity is pivotal for success:
- Diversity on gender: I participated in teams with a fair share of women at a time when we didn’t have the “Women on Tech” movement. They broke the stereotype of only having men on IT by bringing not only the skillset but also new product design perspectives and strong critical thinking.
- Diversity in culture: From being part of 100% co-located Portuguese teams (my home country) to cross-located around-the-clock teams, I have to say having a culture mix fosters quicker innovation. The same culture may facilitate the team members’ onboarding, but in the long-term, you start to see a trend in how they think and behave due to the exposure to the same social phenomena. With different cultures, you see how world-a-part backgrounds influence different narratives, which generates a positive clash of ideas.
- Diversity on skillset: multi-disciplinary teams bring to life better products. I’m not talking about getting a ‘Backend’, ‘Frontend’, or ‘Fullstack’ Developer to the mix. I’m talking about setups in which the customer and the end-user are part of the team, bringing the needed business knowledge on which the team supports their decisions. This also builds on top of other capabilities that do not rely solely on development capacity, such as Architecture, UX-UI Design, Business Analysis, Quality Assurance, Copywriting, etc.
- Diversity in behavior: outspoken persons usually clash with introverts, the same way reactive & enthusiastic ones clash with reserved & patient. And such clashes are great! They leave the team less comfortable and bring them out of their comfort zone. When this happens, they plant the seed to understand opposite views better. After a while, the team looks for a balanced state in which they understand the benefit of ‘disagree and commit,’ leading to better critical thinking.
- Diversity in business areas: Working all of your life in the ‘Telco’ sector is great, but too much time in the same area stalls your brain from thinking differently and leads you to engage the same person’s prototype day-in-day-out. On a personal note, going through 4–5 big business areas over the last decade (HR, Telco, Bank, Insurance, and Autotech) brought me mental elasticity to promote better digital solutions plus robust design thinking.
#2: They don’t see seniority as a rank; it’s an enabler
In an ideal world, if I would give you the possibility to set up a product team with no limitation on resources, would you peek more junior elements or senior ones? If you want faster results, you may grab the best senior team money can buy. Whatever their area might be, senior professionals bring knowledge, experience, and trust in what they do. In the ‘real’ world, we know it’s impossible to have such setups (yes… not even Tesla or Apple have them). We have mixed teams, ranging from junior to mid-level, then to senior.
A small twist: if you would have only seniors in your team, wouldn’t you compromise our first aspect, “Foster Diversity”? Some junior professionals with strong potential but less domain maturity may still be the extra flavor your team needs. This is when the usual “Junior Vs. Senior” discussions go sideways: what is exactly a “Junior” or a “Senior”? Which are the metrics to appreciate the person? What common attributes they might have for us to establish a fair comparison? And so and so on…
I see it the following way: juniority and seniority lay on proficiency. Your proficiency is the sum of previous experiences that brought you the knowledge and, as a consequence, built on you stronger competencies. Depending on the context, you may be senior on given domains (e.g., very proficient in Java development) and junior on others (e.g., not so proficient on . NET).
Nevertheless, when looking into today’s world, we may find a pattern on soft and hard skills a given professional should have. Context frames the output but the outcome may result from different competencies. From a proficiency evolution standpoint, it is expected for the professional to:
- Master technical skills by being a reference in the domain;
- Exhibit strong autonomy while performing tasks without close supervision;
- Foster great soft skills like effective communication, critical-thinking, problem-solving to engage others efficiently and achieve better solutions;
- Be emotionally intelligent so that emotions can be used in favor of a better work experience;
- Share acquired knowledge to enable a network of expertise and consequently harnessing his/her team;
- Influence the surroundings supported by a rich and valuable background;
- Understand the value of sensing, probing, and adapting responses in the presence of complexity since there’s no magical solution to manage it;
- Mentor/coach more junior elements, so they grow alongside (when one teaches, two learn);
So when someone asks me, “How a senior professional looks like?” I answer with the previous points. Junior elements are still going the long run, exploring and maturing the previous attributes. Well-oiled product teams understand this difference and leverage their senior professionals to build better products and build better people.
#3: Talking about problems is Ok
Something so simple yet not always put into practice.
By problems, I don’t mean business/product problems the team usually discusses on refinement sessions. I’m talking about internal & external issues that create frictions between people or lead them to a demotivated, lethargic state, which reduces their performance. I know frameworks like Scrum create dedicated events to address those — like a Scrum Retrospective — but people usually hold back on providing honest and concrete feedback, especially in real-time and face-to-face. This usually happens not because everyone is introverted but rather missing a team’s safety net to transparently express their opinion without fear of personal clashes or being seen as a conflicted person. Remember: being confrontational is different from being conflicted — your feedback shall target facts and skip personal attacks; when you give it, keep a constructive focus on getting things better, not destroying one’s ego.
#4: They cope well with unclear and unforeseen demands
“How innovative your solution may be if you know how it would like from the beginning?”
Powerful question. If any product team would know from the start, ‘Why,’ ‘What’ and ‘How’ they need to build their product, probably we wouldn’t need agile frameworks to cope with uncertainty and complexity. This would lead us directly to a ‘waterfall’ mentality in which all requirements should have been known beforehand. But that’s not how today’s VUCA world works. The beauty of engaging in such design and development approaches is to have continuous inspection & adaption to guarantee the team is always focused on the maximum value delivery. A well-oiled product team embraces unclear and unforeseen demands because they know there’s a chance of the next-in-line request may generate a better solution overall.
Note: Please do not confuse seasoned unplanned demand with constant disruptions. Mature teams also know how to say “No” and avoid constant working model interruptions with futile or non-valuable topics. When this happens, the team should apply critical assessment mechanisms and proper trade-offs to juggles priorities.
#5: They feel action is better than no action
If well-oiled product teams had to choose an anthem, it would be for sure “A little less conversation, a little more action, please” from King Elvis. Overthinking topics or exploring them to infinite-detail levels usually creates confusion, unmanageable complexity, and wasted time-to-market opportunities. These teams cope well with little information but just enough to start drafting solutions and submit them to customers & stakeholders scrutiny. Pareto’s 80–20 Law serves the team’s argument since the full commitment finding a perfect solution creates a complex network of dependencies, discussions, and misunderstandings that usually lead to no action.
“For many outcomes, roughly 80% of consequences come from 20% of the causes “
Meaning, 20 % of your original effort usually yields 80 % of your results. 80% is already a fair percentage of the solution’s value, considering the team's original commitment. Going the extra mile looking for that final 20 % of results usually do not justify the 80 % of team investment. So it’s clear why these teams make everything actionable: limited effort looking for a quick return on investment.
#6: They promote a full-stack mindset
Specialized teams are different from teams with specialized elements. It’s common to have team members with different flavors, but keeping key information under just one individual may create a silo-ed mindset. Some scenarios of under-performing Scrum teams:
Scenario #1 (Enter here a stressful moment):
- Developer X: “Production is down! We need a quick-fix on the frontend component!”
- Developer Y: “Well… Developer ‘Z,’ our Frontend specialist, is absent today… We have 2 options: lets all deep dive on product documentation & Google for answers, or let’s wait for him to come back tomorrow…”
Scenario #2 (Enter here a Scrum Refinement moment):
- Developer A: “To avoid future technical debt, I truly believe this business logic should be implemented on the backend side. What do you think?”
- Developer B: “I have no idea about what happens on the backend…”
- Developer C: “Me neither… Cannot support a decision like that.”
These are exaggerated scenarios but the idea is to bring you a scene where knowledge sharing & acquisition across team members could have helped solve the issues. We don’t want a Backend Engineer to deep dive on Frontend topics and create a new (and largely extensive!) skillset. We want him/her to learn the basics from other colleagues. Hence, he’s able to 1) contribute on issues in a more thoughtful and valuable way and 2) build a sense of belonging since their product is not just backend or frontend — it’s the sum of all its parts, which all the members should be acquainted, so they better react and plan for product growth.
This is pretty much different from expecting several hard skills to be all in one person. I’m not advocating this. I would prefer a ‘T-shape’ professional, with a strong core on a given competence and knowing other domains' basics.
Although I set the tone for these aspects under the digital product delivery, I truly believe that can be extrapolated for other domains outside the software ecosystem. More than recipes for technical engagement, I focused on mindset changes that work for any professional in any business area.
If you need help on getting any of these aspects right, please reach out in the comment area.
