{"slug": "the-3-product-battles-84-of-ems-lose", "title": "The 3 product battles 84% of EMs lose", "summary": "A survey of more than 950 engineering managers by Manager.dev found that 84% are barely involved in product decisions, with only 16% reporting high involvement. The article outlines three product battles engineering managers must win to improve outcomes, citing an Unblocked benchmark showing Claude Code with a context engine runs up to 83% faster and uses roughly 40% of the tokens.", "body_md": "~80% of my \"hands-on\" time is now waiting for agents. The worst part is that when they finish, the results are often wrong, and I waste time correcting them.\n\nIt's almost always a context problem, and a pile of MCPs doesn't solve it. Each one searches its own silo, but the answer spans a PR, a Slack debate, and a Jira ticket marked won't fix. So your agent tries to do the stitching (on your token bill).\n\n[Unblocked](https://getunblocked.com/?utm_source=managerdev&utm_medium=email&utm_campaign=contextengine) ran the same task through Claude Code with and without a context engine. Up to 83% faster, at roughly 40% of the tokens, and actually the **right** answer. You can use their [open source benchmark](https://github.com/unblocked/context-engine-simulator?utm_source=managerdev&utm_medium=email&utm_campaign=contextengine) to see the differences on your own repos.\n\nIn my first couple of years as an engineering manager, I took my PM’s word as given. They told me what to do, and I made sure the team did it. Nothing felt weird about it - they know the customers better, they understand the product better, and they have good ideas, right?\n\nIt took a few terrible calls by the PMs before I stopped working that way. Once I got into the details, I understood that in many cases [product management is broken](https://www.manager.dev/newsletter/product-management-is-broken-and). So I slowly started to involve myself and my engineers on the product side: offering ideas, challenging decisions, and demanding to be heard.\n\nOver the last 12 months, I asked more than 950 EMs:\n\n*“How involved are you in product decisions and the business side of your company?”*\n\nI was very surprised by the results:\n\nI expected <5 YoE EMs to be less involved in product decisions, but I didn’t expect 45% of experienced engineering managers to be barely involved.\n\nIn too many teams, the mantra is still: “The PMs decide **what** to work on, the EMs and engineers decide **how** to accomplish it”. If you want your team (and yourself) to succeed in the upcoming years, you have to do better. ** **\n\nHere’s what happens when an **e****ngineering manager focuses solely on engineering:**\n\nWasted effort - the team is releasing features that are not used or end up being rolled back.\n\nInvisible impact - your team works hard, but nobody sees or appreciates it.\n\nHard negotiations - you need to constantly protect your team in roadmap talks, fight for headcount, and so on.\n\nConstant surprises - there are reorgs and decisions you are not part of.\n\nDisconnected engineers - your engineers don’t really care what happens after they finish a task.\n\nOnly 16% of the EMs surveyed answered that they are very involved in product decisions. If you are among the 84% majority (like I was for most of my management career), making that jump is easier than you think.\n\nThere are 3 battles you need to win:\n\nLanding a feature vs launching it (awareness of basic metrics)\n\nWatching user behavior\n\nTalking to customers\n\n## Level 1 - Land vs Launch\n\nThe first level consists of being aware of the metrics your team impacts. It starts with basic access to them - Mixpanel, Amplitude, PostHog, or whatever product you use. Have a dashboard that shows usage over time and make it **very accessible **to your team. I use PostHog, and they have a ‘subscribe’ feature, allowing me to easily push the relevant dashboards to our team’s Slack channel.\n\nI learned the importance of this one the hard way.\n\nAt my last company, we built tools for drone pilots flying over crop fields. One day, the ops team told us pilots were wasting a lot of time driving between fields in the wrong order ([the traveling salesman problem](https://en.wikipedia.org/wiki/Travelling_salesman_problem)!). So we built a phone-friendly route planner that did it automatically.\n\nWe launched it, announced it, and moved on.\n\nTwo months later, I checked the metrics: only **six pilots** had used it (out of ~200). Turns out, someone from ops had mentioned it once, and most forgot or ignored it. We tried again - this time with a personal message to each pilot. Over **60** started using it.\n\nHaving those metrics available is the difference between ‘launch’ and ‘land’. Launching is the fun part for engineers - solving a problem, writing code. Landing is boring and non-technical - but **without landing, your launch is useless.**\n\nThis is relevant not just for client-facing features - here’s [a great post](https://www.linkedin.com/pulse/launching-versus-landing-carlos-arguelles-vc2jc/) from a Principal Engineer at Google covering his own experience.\n\nDid you release something? Schedule a reminder in a week or two to look at the data.\n\n**Level 2 - Watching user behavior**\n\nIn almost every company, there are session recordings where you can actually see how your users behave. Usually PMs watch them - but nothing stops engineers from doing so. You can start with a ‘movie time’ meeting, 30 minutes where the whole team watches chosen recordings together.\n\nToday, it’s also easy to feed those recordings to agents and have them analyze the pain points - but I’d still argue there is a lot of value in seeing how people use the products and what they are stuck on. Seeing a real human encounter the frustrating part of your product is an important experience.\n\nA second part of this level is to watch recorded discovery calls with customers, even just one every few weeks. In the pre-AI-meeting-recorder days, I used to take the videos, cut the relevant parts, and add them to the matching tickets for a bit more context (or just send directly to the engineer).\n\n## Level 3 - Talk to customers [boss]\n\nMost organizations are not structured to encourage direct conversations between engineers and customers. There are many layers between them: PMs, designers, customer success, account managers, user research.\n\nAt my last company, it took me 3 years to actually go visit a customer:\n\nOur customers were farmers in the United States, so I had to fly across the ocean. And farmers are super busy, and don’t really want to talk to engineers…\n\nOur CS team got me in touch with one who was really enthusiastic about our latest release. They mentioned that an in-person meeting would be more effective, as usually on Zoom he turns the camera off and doesn’t have a lot of patience. So **I drove 10 hours each way from our office in Indiana to that customer in Iowa**, for a 1-hour meeting.\n\nIt was definitely worth it!\n\nI saw how he used our app in real life - on an iPad! Turns out in one of the critical flows, he switches to another app to get some data, and returns to ours. That’s not something we knew. I asked him about it, and he mentioned it’s very annoying, but he got used to it (who knows how many other customers it cost us!).\n\nThere was also a question I asked that he couldn’t answer - so he just called an intern into his office - and it turned out that intern was a super enthusiastic (and technical) user, who of course is never invited to Zoom calls because he is not senior enough (and that encounter led to multiple useful meetings).\n\nAnd while in-person works best, there are many easier ways to meet customers:\n\nPiggyback on existing meetings - ask to silently join customer discovery calls run by PMs, sales, or CS. Promise not to interrupt - just learn. If you have a question, you can just send it internally in Slack during that meeting.\n\nReach out via Support - find a user who recently complained, or someone whose ticket you fixed. You’ll be surprised how receptive customers can be. Recently, I had a good experience with Supabase. I had a bug and reached out to support, and they told me they escalated. Then an engineer fixed it, and reached back, asking if there was anything else I needed. If they had offered to jump on a call to understand my usage, I would have happily agreed. Works in both B2C and B2B!\n\nWork with customer success/account managers to identify a power user (or just look at the data). Send a short, respectful email: “I’m an engineer on the team that built X - I’d love 15 minutes to learn how we can make it better for you”. Customer Success teams are often delighted when engineers take this initiative, because the usual mindset from engineers is “don’t waste my time with useless meetings”.\n\nIn the second and third methods, we go for the edges - the people who either love us, or need us but are annoyed. Those are the people who are already invested in our product, so they won’t need much convincing to jump on a short call. If someone opens a ticket, it means they need our product.\n\nHere are 3 questions you can start the meeting with:\n\n**Feature context**: “How do you currently solve X?”** Usability feedback**: “Can you show me how you’d use this new flow?”** Pain validation**: “What’s the most frustrating part of your workflow right now?”\n\nBut I mainly try to just shut up and listen to them. I also highly recommend reading [The Mom Test](https://www.goodreads.com/en/book/show/52283963-the-mom-test) if you’d like to learn how to do such calls properly.\n\n## Your product is used by humans\n\nThere is no way to truly understand your product without understanding your customers. Every single level here is about being more in touch with the human behavior of the people who use your product every day.\n\nEngineering managers who stay purely technical, without any empathy toward their customers, are missing a critical aspect of their jobs.\n\nAnd in addition to being able to influence the product roadmap, being closer to your customers makes your work much more fun.\n\n## My favorite reads of the week:\n\n[Before you delegate, ask yourself these 6 questions](https://newsletter.weskao.com/p/before-you-delegate-ask-yourself). I’m almost always forgetting at least one of the aspects.[What if you’re not supposed to have a long-term plan?](https://www.lennysnewsletter.com/p/what-if-youre-not-supposed-to-have)On*emergence*, a process that occurs in nature when multiple parts come together to form a complex whole without a clear plan or intention. Could definitely relate.[What nobody tells you about writing agent skills](https://newsletter.posthog.com/p/what-nobody-tells-you-about-writing). Some very useful tips, and a cool prompt at the end!", "url": "https://wpnews.pro/news/the-3-product-battles-84-of-ems-lose", "canonical_source": "https://managerdotdev.beehiiv.com/p/business-oriented-em", "published_at": "2026-08-11 06:01:00+00:00", "updated_at": "2026-08-11 07:15:55.106386+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools"], "entities": ["Manager.dev", "Unblocked", "Claude Code", "PostHog", "Mixpanel", "Amplitude"], "alternates": {"html": "https://wpnews.pro/news/the-3-product-battles-84-of-ems-lose", "markdown": "https://wpnews.pro/news/the-3-product-battles-84-of-ems-lose.md", "text": "https://wpnews.pro/news/the-3-product-battles-84-of-ems-lose.txt", "jsonld": "https://wpnews.pro/news/the-3-product-battles-84-of-ems-lose.jsonld"}}