Search for a command to run...
Head of Engineering @Thndr. Passionate about managing teams, growing leaders, and building products that matter. Husband. Father. Madridista. Opinions are my own.
No comments yet. Be the first to comment.
How much money does your application need per month to give users the services they need at the right standards of performance and reliability? And what is the least amount of money your team would need when scaling the system down and just keeping t...
ازاي تقيس انتاجيتك وكفائتك في الشغل حتى لو شركتك/الفريق/مديرك مش مهتمين انهم يوضحوا ده أو مش مهتمين يعرفوا؟ الأرقام اللي من نوع "كام ticket خلصتها في أسبوع" وغيرها من الأرقام المشتقة من مبادئ الـagile بيتم استخدامها بشكل غلط طيب ازاي أحدد انا باشتغل ...
![[Arabic] Productivity and Performance Metrics that you should measure](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2FJKUTrJ4vK00%2Fupload%2F9d80779c869f5b24eb0ca09c98243aae.jpeg&w=3840&q=75)
One of the great takeaways from Andrew S. Grove’s “High Output Management” book, which I read a couple of years ago and am reading again now, is that it sheds some light on the common similarities between production or assembly lines and software eng...
هاتكلم النهاردة عن The Cobra Effect, Parkinson's Law وحاجات تانية: في واحدة من الشركات اللي اشتغلت فيها، كانت فيه مشكلة كبيرة وهي إن معظم المشاريع اللي بنتفق اننا نسلمها في مواعيد محددة بتتأخر، وأسباب التأخير وقتها كانت متنوعة بين ضغط الشغل والوقت مش...
![[Arabic] How can good intentions to solve a problem cause bigger ones?](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2FY0I5DEbx8ck%2Fupload%2Ff1423c237b01589581b68a42fb976116.jpeg&w=3840&q=75)
من الغلطات المعروفة اللي بيقع فيها أي حد بيروح شغل جديد انه يكون مستعجل على انه يعمل impact/تأثير على الجزء اللي بيشتغل فيه.. ده مش غلط في المطلق ولكن ممكن يسبب شوية مشاكل تحصل بدري ومن غير ما ياخد باله ولا يبقى مستعد، هاتكلم على كام نقطة شوفتها بتحص...
![[Arabic] Navigating the early days of a new Job: Mistakes to avoid and Details to pay attention to](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fstock%2Funsplash%2FwNz7_5EvUWU%2Fupload%2Fdb11679e01703020094ed6406d29777f.jpeg&w=3840&q=75)
Have you ever found yourself in one of these team retrospectives, where everyone tried to figure out why everything went wrong? missed iteration goal for the second time in row, last-minute changes, unstable releases, and a hell of ad-hoc requests. Frustration and confusion were all over the room. I believe you have, and I also think you were fortunate to be in a place where positive vibes were the theme of a retrospective, when your team felt productive and happy to deliver impactful stuff. A lot of aspects affect team efficiency and morale, one of which is product managers.
Over the past nine years, I’ve been working almost every day with product managers and owners on numerous products that are meant to help people, give them the right value, and make their lives easier. As an engineer, I always find it challenging for product managers to keep the right level of dedication and focus on many areas like product discovery, stakeholder management, roadmapping, setting product vision and strategies, release and GTM planning, competitor analysis, and, of course, enabling and empowering their engineering teams, the real product builders!
I’ve witnessed a lot of missed opportunities for teams to produce timely and quality outcomes and results for the products they worked on, despite the fact that these teams had plenty of great talents with solid experience under their belts. They had the same goals and ambitions, but what kept them from reaching their potential? I would say there were different reasons that led to this, but at the top of the list was the inability to devote enough time and attention towards crafting solid processes and building teams with high momentum and autonomy.
In fact, one of a product manager’s main responsibilities is to work closely with the engineering teams. Effectively doing this contributes to the PM’s success in the organization. Being unable to handle it might introduce some complications, like frequent missed iteration goals or being such a bottleneck that the team always needs them there to make a decision. In this article, I will talk about these issues and many more. I’ll also list 10 key characteristics that I’ve noticed in some of the fantastic product managers I’ve worked with as a team member and leader of many engineering teams. These qualities have helped their teams unleash great acts of efficiency and deliver results that immediately impacted their products.
Note: This article is packed with some cool stuff taken from the fantastic Dilbert Project. I hope you like it.
Most of us had the chance to work with those product managers who were so busy that they rarely came to our stand-ups, replied back on Slack threads, or even attended retrospective meetings. They prepare just enough for other scrum events like pre-planning, backlog refinement, and sprint planning meetings, and that’s fine. The problem is that, in many cases, it is necessary to have a responsive product manager who can give the team answers and guidance as needed during the sprint. We never assume that within two to three weeks, we’ll have a well-defined scope with clear acceptance criteria. The best product managers always make time to participate in ad-hoc calls or to respond to a thread in which the front-end and back-end engineers argue about something.
Product and engineering teams may find themselves frequently asking, “What do we need to build next?” as they have numerous boards piled high with features and requirements waiting to be picked. However, product excellence is not determined by the quantity of items delivered; it is determined by the value these items add to consumers and other stakeholders. That’s why it is essential to take a breather every so often and switch from asking “what?” questions to “why?” questions whenever possible.
Experienced product managers never present their teams with solutions but rather with problem statements. For instance, instead of being asked to implement a user provisioning feature using CSV sheets, the team working on the B2B product should instead hear about the problems that the users are having when it comes to onboarding new corporate customers. Clear problem statements let the team use their creativity, product knowledge, analytical and critical thinking skills, and other skills to solve problems and come up with good ideas. Delivering features alone won’t solve issues; providing value will. Because of this, it is a product manager’s responsibility to conduct appropriate discovery and requirement gathering in order to enhance the conversations they have with their teams. That should lead to a list of possible solutions that can be put into action to solve the problem that was already mentioned.
A “feature factory” is a product or company that measures output over outcomes. It’s a story point machine where the company only cares about how much is being shipped. The company celebrates the work done, and it feels like a conveyor belt going in one direction. No one is thinking about the question: is any of this really working? No one is thinking if any of this complexity is adding business value.
A “feature factory” is a place where the outputs are celebrated rather than the outcomes. Teams can’t be sure that their work really helps customers, so during sprint planning, they only focus on shipping the feature asked for by the product manager. There is no impact analysis, success or failure metrics, or even a plan for what will be built on this feature after it is released.
Occasionally, in feature-factory types of teams, feedback on the deliverables is provided without the participation of the individuals who worked on them. Customers, stakeholders, and product managers all participate in the feedback loop. A good product manager will ensure that their team is kept in the loop at all times. It’s always important to make sure that engineering teams can see the organization’s goals, the metrics used to measure how well the results are working, and the direction that each of us should be going. Whenever they see a benefit from including the engineering teams in stakeholder discussions, they make sure to do so without overburdening them.
They keep giving feedback on what the team did, celebrate when things went well, and give the team the credit they deserve. Additionally, they are eager to discuss concerns and errors the team has made in order to improve in the future.
No matter how well a team plans its activities, there is always going to be some unexpected stuff popping up in the middle of the sprint, and the product manager and the team need to find an efficient way to deal with it. Unplanned work comes in many forms, such as emergency production bugs, data corruption, a small change in a requirement that stops us from launching a new feature, or an angry customer or stakeholder that we need to do our best to keep.
As you can see, there are countless possibilities, and the product manager is the team’s first line of defense. He or she should be able to effectively communicate with the issue or request reporter, prioritize, evaluate the urgency, and consider how to push back if necessary. They should also communicate with the team about whether to incorporate the item into the current sprint or substitute it for something else. Finally, he or she should be doing so cautiously to make sure that the team’s focus and morale won’t be affected.
Being a technical expert with hands-on experience is not one of the many skills needed for product management. The ability to read between the lines, take in the information at hand, and lead productive conversations with engineering teams is, however, indispensable. Without it, it would be hard for product managers to figure out why the team needs two sprints to show or hide buttons on a screen that has been there for four years and hasn’t been touched since then.
Product managers must work to gain a thorough understanding of the system architecture, how each component interacts with other services, and the technologies and tools the team is using. By doing this, they will have a better chance of getting involved in the team’s technical threads and knowing what system limits we need to work on or avoid until we deal with the team’s technical debt.
Understanding various software development processes and terminologies is essential. A good product manager is aware of the team’s process for releasing new features, how production bugs are fixed, and what the evil term “CI/CD” is all about.
There are a lot of ways to define the word “stakeholder.” From my point of view, a stakeholder is someone who is interested in the product in different ways. This could be a customer, a shareholder, someone who has a say in the product’s direction and strategy, or anyone who will be affected directly or indirectly by changes to the product. Based on this definition, managing stakeholders has always been seen as one of the hardest jobs anyone could have, and product managers can’t avoid doing it.
Stakeholders will always want to have their requested, urgent features in the product as soon as possible. This is where product managers’ skills in negotiating, refining the scope, setting priorities, and keeping everyone in the room convinced and happy come into play. It is essential to provide the engineering team with a sufficient amount of time to discuss requirements and evaluate feasibility. After that, it is the responsibility of the product manager to vouch for the team’s decisions and estimated delivery timelines. Most of the time, product managers are dragged into conversations where they have to commit to a timeline. If they do this without making sure their teams are on the same page, it could lead to unnecessary pressure, a lot of context switching, and a lower level of quality in the end result.
When it comes to numbers, we’re talking about the right ones, because if we measure the wrong things, it’ll only make the situation worse over time.
I’ve known product managers who gauged product success based on the number of contracts won and the number of new features released each quarter. These numbers are ineffective because they indicate nothing other than a lack of product vision. Better metrics and measures should pay attention to aspects like customer retention and acquisition rates, user satisfaction and reported complaints or crashes, the impact of delivered features, etc.
It is always difficult to convince a competent engineering team that asks the right questions about features or requirements that are supported by nothing but a product manager’s sense of urgency. The team should have the freedom to contest the necessity of a feature, asking for the impact in numbers and supporting data. The product manager should be ready for these talks and have put in the time and effort to gather these numbers and data for their teams, not to mention the market and user research that should have been done before this step.
The ability to create excellent documentation is one of the abilities I’ve observed in every reliable product manager I’ve worked with. How well a product manager can communicate concepts, problem statements, product vision, and a variety of other things to the rest of their team will largely determine how effective they are. It’s helpful to be able to articulate ideas and document them so they can be shared with engineers, sales reps, business stakeholders, etc.
These documents could save a ton of time and effort in explaining product things and instead give the readers the chance to absorb the information and work on it asynchronously, which is more efficient, especially for engineering teams. Everyone should always look to well-written user stories and PRDs (Product Requirements Documents) as their source of truth, not just the engineering team that is working on the implementation of the feature.
Every problem that a product manager brings up shouldn’t always be solved by a technical solution. No matter how technical the ideas or solutions are, a team’s level of excellence is always determined by how well it can come up with good ideas and solve problems. Team members should be able to challenge problems and modify the existing system to meet requirements with minimal technical modifications. Not only should they lead the “How?” phase, but they can also suggest changes to the scope that would result in greater value. Product managers who are smart allow their teams to participate in all phases and do not just see them as executors who arrive late to the product evolution phases.
Additionally, confident product managers give the team the room and degree of autonomy required to make tactical decisions and manageable scope changes that benefit them but don’t detract from the project’s overall deliverables. By doing this, the product manager won’t become a bottleneck who needs to be consulted on even the smallest changes.
A go-to-market plan, also known as a GTM plan, is an important step that needs to be taken in order to guarantee that the users you have in mind will be aware of the launch of a new product or feature. This plan should cover a wide range of topics, including who will use this feature, which platforms should be used, what are the prerequisites, how should we notify the users, what are the expected outcomes, how will it be managed and handled for potential issues and onboarding requests, etc. It should also contain a clear set of action items with their respective owners.
The team needs to be aware of what is expected of them during the development, release, and launch phases, so this plan needs to be open to changes as we go forward and visible to all stakeholders. This gives them confidence that they’re working to a plan and won’t be surprised by unplanned tasks like user provisioning or technical support.
It always takes time to build a strong team that performs well and whose members are confident in each other’s judgment and the decisions they take. Product managers should receive the utmost support because they are the ones who carry the flame and light the way for their engineers. In addition, it is their responsibility to ensure that the team is focusing its efforts on activities that are beneficial to them and the organization as a whole.
