• We were discussing what made some of those projects successful. I can’t remember everything I rambled on about, but one of the things we landed on was that they all had just the right balance of team members. We were not talking about the perfect balance of job roles filled (like a product manager, designer, engineer etc..) fully staffed projects. We focused more on the different kinds of people, specifically engineers, we had on those projects. It wasn’t about seniority or tenure, it was about their style. A great mix of platform engineers, engineers who just found a way to get anything done, engineers who thought deeply about scaling, performance and so on…. (View Highlight)
  • “Doubt I invented the term, but I did use it a lot. As a young discipline we’ve spent a lot of time working out « how » to build software and that’s a big focus in schools still. But once you have the foundations, you need devs who engage with the « why » actively. Engineers who have a thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences. That is what defined a product engineer in my books… Bad product engineers cut too many corners but great ones know that minimum loveable products need the right depth to be considered during the build phase.” (View Highlight)
  • Over my last ten years of product management, I’ve come to conclude that product engineers are a critical ingredient to helping you build a successful product, scale yourself and become a better product manager. (View Highlight)
  • I firmly believe that one of our key jobs as product managers, especially in growing teams, is less about doing actual day to day product work and more about building a shared understanding with our teams. An understanding of our customers, their problems, the strategy and the opportunities we have. (View Highlight)
  • Let me be very clear: This isn’t because your time is “more valuable” than an engineers time. You’re not more important than others. This is fundamentally based on the belief that if you empower others with the context they can move faster, make better decisions, be engaged and help you scale the product craft across your organisation. (View Highlight)
  • 1. Strong opinions, loosely held In contrast to an engineer who is always seeking a spec or asking for a detailed definition of what we’re building, product engineers will often come to you with an opinion on a particular item they’d like to flesh out more. Your job as a PM: Because they’re opinionated, product managers will need to do more (than usual) work to earn respect and trust. This isn’t a bad thing at all. In fact, if we go back to our job of making ourselves redundant, anything which forces you to focus more on explaining why we’re doing something and how we measure success isn’t good just for our teams and stakeholders but ultimately we help our customers (by making sure we’ve done our homework). (View Highlight)
  • . Quickly build intuition Product engineers have great instincts. They build intuition quicker than your average person. You’ll see them do this by taking a learning and immediately extrapolating possible implications for product. This, in combination with your engineering mindset of problem/solution, identifying common patterns and thinking about problems in abstraction helps them take something that might be qualitative and fuzzy and break it down to its first principles. Your job as a PM: Giving all engineers (and particularly product engineers) direct exposure to customers is the single, most effective way I’ve seen engineers build customer empathy and intuition. (View Highlight)
  • I’ve said this before, but we should never be doing customer research or interviews without our engineers. If you’re getting to the point where they’re telling you “I get it now, no need for more interviews” — you’ll know when to stop! (View Highlight)
  • Something magical happens when an engineer experiences a “light bulb” moment for themselves. These moments aren’t achieved by sharing research reports, presentations or data. They’re often achieved by getting out of the way between the engineer and the customer. (View Highlight)
  • Bring healthy conflict Product engineers contribute to creating “healthy” conflict by considering different aspects of a decision and encouraging healthy debates and challenging the status quo. They’ll often be asking “what if we don’t do this?” and “is this really the most important thing we should be working on?”. They have an endless bucket of curiosity — seeking to get to clarity on a problem which you may have thought you already had well defined and understood (but you don’t). (View Highlight)
  • Your job as a PM: Embrace this. They’re questioning the work, not you as a person. They’re helping you become a better product manager. Their desires come from the same place: to build a product that customers love. So next time this happens, listen. Ask clarifying questions. From my experience, almost every time, it’s not “them”, but it’s actually us. I’ve found these moments incredibly humbling. They’ve often pointed out a gap in our shared understanding, a better way of framing a problem, a bigger opportunity we’ve missed or a lack of clarity on a topic. Start by assuming they’re onto something, rather than seeking to defend your point of view. (View Highlight)
  • Wizards at identifying (and minimizing work) on edge-cases In contrast to some engineers who effectively see the many code execution paths and feel the urge to close them all off, product engineers often elevate the discussion to focus on the majority use case. They’re looking to spend all their efforts on the ideal journey — the path most taken. Their desire to focus on this means they spend their time on the most valuable thing. (View Highlight)
  • Your job as a PM: Building product is all about making trade-offs. The best trade-off decisions are made by someone with the sound knowledge of effort vs value. As product managers — we know zero about effort. Our job here is to bring the knowledge of the value and frequency of use cases. Working with design in journey mapping and building a shared understanding of what journeys we are optimising for and why. Equip them so they know where best to focus their time. (View Highlight)
  • Your job as a PM: Instead of spending your time trying to identify these quick wins, spend more of your time building a shared understanding of what customer value is. What’s the outcome your customers are trying to achieve? Let the product engineers, who spend most of their day living in the code, identify the low hanging fruit — they’ll do a much better job than we will. (View Highlight)
  • Seek early feedback Before writing any code, they’ll often be thinking about different ways to validate a concept, gather feedback and do a build-measure-learn loop. In contrast to an engineer who’s talking about building something robust (in terms of code), they’ll be looking to take as many shortcuts as possible to ensure the problem your solving has met its goals before entering a hardening phase. (View Highlight)
  • Your job as a PM: Empower engineers to have direct exposure to those feedback loops. Everything from quantitive to qualitative feedback. You should be spending most of your time thinking about how you can optimize your bite-size deliverables for learning first, before refining and hardening the solution. A handy tactic we’ve had a lot of success with is to empower product engineers with responsibility to triage incoming feedback. (View Highlight)