In the realm of product development, collaboration between product managers and engineers is the cornerstone of success. As the two sides of the same coin, they are meant to complement each other: product managers ensure we solve the right problems while engineering ensures we solve the problem right.
I had the opportunity to delve into this symbiotic relationship with Bart Hemmeryckx-Deleersnijder 🔗 a seasoned engineering lead at Showpad 🔗, a market-maker for sales-enablement since 2011 grown now to 500+ employees reaching 1200+ customers in 50+ countries. Before Showpad, Bart worked as Product Manager at Nokia which makes him a great product friend to talk to. While we focused here mainly on the delivery process, make sure to check out Bart’s earlier research paper at Alcatel on applying qualitative UX research techniques on social media applications 🔗.
Our conversation unearthed valuable insights into the dynamics, challenges, and strategies that underpin effective collaboration between these two crucial roles:
- What does an engineer expect from a product manager?
- Can we keep distinct responsibilities but converge on the success metrics?
- Solution design: translating the ‘why’ and ‘what’ into the ‘how’
- Why is ‘technical debt’ not only an engineer’s problem?
- Bonnie & Clyde: the risk of going rogue in the absence of other product friends
- A product manager’s guide to an engineer’s operating system
Key Attributes of a Product Manager from an Engineer's Perspective
Bart’s motto is ‘everybody is product’ and, at Showpad, they build software solutions with impact in mind. He fosters a culture that helps engineers feel motivated by the broader meaning and encourages everyone to understand how the solutions they are invested in deliver impact in a person’s life. This is where product managers lead by example and put the spotlight on the importance of empathizing with users to understand the broader implications of an engineer’s work beyond technical implementation.
Another privilege product managers have is to delve into aspects such as a company’s financials or strategic growth. However, they might get persuaded to back up unrealistically high expectations in response to business needs. At that point, collaboration with engineering becomes vital to stay grounded and constantly weigh the value against the investment. A good reality-check with your engineering counterpart can help in finding lessons before shifting strategy or persevering until success.
Capacity planning at Showpad is done using SWAG (Sweet Wild Assed Guess) 🔗: a combination of effort estimate and willingness to invest, based on open dialogue between product and engineering. Product managers should use this opportunity to get engineering’s buy-in since it feeds into their subjective estimates. Do not be surprised to get a high effort estimate if you don’t manage to convince engineering the request is a problem worth solving.
“Software engineering is complex; we rationalize but no matter how scientific we try to make it, there are always unknowns.”
Another form of lowering the risk of investment is through budget awareness. Before you drain everyone’s energy with over-engineering, as a product manager you must keep your development phases in check both for customer value and business viability (talk to your finance friend). The more budget you have, the bigger calls you can make but iterate before you find yourself going in the wrong direction.
Play to Your Strengths but Align Your Success Metrics
Empathy and understanding of each other's roles help foster collaboration, but maintaining a distinct separation of responsibilities ensures accountability and efficiency in product delivery. The foundation is: product managers focus on value and viability, while engineers focus on feasibility. However, getting things done is hard, and constant discussions on ‘is it good enough’ or ‘should we further tweak it’ do not help if there are too many decision-makers.
In larger organizations, you’ll find Enterprise/Solutions Architects: a relationship a product manager needs to invest in. Architects are product’s partners in strategy to create ‘architectural runways’ and ensure alignment with business goals. Showpad uses a quarterly-based delivery mechanism, with architects working on new features six months before their implementation.
Testing is a shared team responsibility, but I always found it useful to have another team member take a leading role in quality assurance (see George Dinwiddie's **‘three amigos’ 🔗). Especially when product and engineering disagree, this trio ensures built-in quality with approaches such as Behavior-Driven Development. 🔗
At Showpad, engineers learn about the product from the end users’ perspective during their onboarding process by getting familiar with personas, attending interview or looking into usage metrics together. But an engineer’s performance evaluation often comes down to effective delivery (aka ‘it works’ + bonus for clean code) while the tech lead is the one accountable for the delivery’s date/budget based on how they guide their team in their technical choices.
The success metrics for a product manager are highly influenced by those of the product itself (adoption, customer delight, sales, etc.). So, given the pressure we receive on the scope, we are more inclined to believe more is better and risk to fall victims of scope creep.
If we strictly look at the business/functional vs technical analysis as an output, the input remains distinct for each role (the ‘why’/’what’ vs. the ‘how’). So, as long as those are clear, each is accountable for their own ingredients in the mix paving an individual contributor’s career growth path. But if we want to ensure outputs feed the desired outcomes, it makes it that much easier if product and engineering have a common denominator in the leadership team, having them part of the same department so metrics can ultimately converge. At Showpad, the CPO (an engineer by education with a long track as a PM) is responsible for both which helps elevate everyone’s perspective and better understand progress towards common goals.
Solution Design: Why → What → How
With experience comes the ability to see patterns, but product managers should avoid overly prescriptive solutions. It is sufficient to have a fair understanding of the technical constraints of your product's architecture to set upfront more realistic expectations. Requirements should focus on problem hypotheses, allowing for discussion and exploration of different approaches.
An engineer doesn't appreciate getting a premade solution just as much as a product manager doesn’t like getting one from other business stakeholders. We know this can be restrictive and disengaging for the team, but we should at least hear them out. Not only is there a fine line between functional and technical, but the solution they ask for teaches us how to present our proposal in return. The more non-technical people feel like co-creators, the higher the chances they become product evangelists, which is essential for adoption.
So, as PMs, list the solution(s) you have in mind but don’t be reluctant to different approaches. Keep your humble hat on and state your thoughts transparently. Most engineers want efficiency, especially in a complex business context, but you might put them on the wrong path with wrong assumptions, so make sure they feel empowered to come up with a better solution as one emerges. Use the value of the team; let other people explain the solution back to you to validate that you’re aiming for the right business outcomes.
“The more we can think along, the better. There are many subtleties in translating the ‘why’ into the ‘how’. The more an engineer goes towards the ‘why’, is the easier it is to communicate as the language aligns.”
In Bart’s opinion, Domain-Driven Design (DDD) comes into play here so make sure to check out Eric Evans’s book “Domain-Driven Design: Tackling Complexity in the Heart of Software”🔗. In short, engineering and product experts collaborate to create an abstract model that accurately represents the core business concepts and processes: the problems the solution solves represented in a shared language, developed in bounded contexts that distinguish between core domain and add-on services.
For instance, architectural concepts such as ‘micro-services’ have allowed companies like Amazon to create isolated systems for different parts of its business, such as inventory management and order processing allowing these systems to evolve independently and scale efficiently. For a quick read on DDD, make sure to check out this Medium article. 🔗
Technical Debt and Roadmap Planning
The term “technical debt,” as defined in Kruchten’s report 🔗, refers to delayed tasks and immature artifacts that constitute a “debt” because they increase the future cost of change during evolution and maintenance.
Without technical excellence baked into the product, technical debt will accrue, and not at a linear rate. This will create friction between a software development team and getting a new feature developed, decreasing the rate of value delivery. If you’re always inclined to choose the expedient solution and accumulate too much technical debt, it will not be long until you will no longer be able to sustain a steady delivery rhythm and reduce your ability to plan ahead.
Bart and I agree that we should plan a roadmap to be delivered with less than 100% of the capacity. At times, empowered teams might plan only 50% of their capacity for new feature development, but there is no magic formula. For this, it is important to have a clear product vision encompassing engineering’s assessment of the product’s technical debt.
How much you deliver and when also depends on the direction you want to steer the product in. With a decoupled system, you can choose not to invest in reducing technical debt if there’s no plan to further evolve a certain product area. In areas in which you want to grow next (not everything can be a priority), you want to back up features. Because adoption takes time, you can give the perception to the market that you are growing while preparing new strategic moves.
The way Showpad gets ahead of the curve is by investing two quarters upfront and making bets with a 6-week model (an explicit agreement and a signed-off ROI investigation), using the other 6 weeks of the quarter to work on what remained ‘undone’ (check out Large Scale Scrum (LeSS) 🔗 Overview).
Find the framework that works for your organization (don’t rely on momentum, it fades) to cut the roadmap into pieces so it’s easier to estimate effort and relatively predict what you can build. But do not exclude that you might not be able to grow organically fast enough (time for an M&A?) or if you’re at the stage where your product is not worth further investment, you may just need to maintain your technical debt or even sunset.
While engineers make estimates on the effort for the requested features, it is ultimately the product manager who’s required to have the ‘when’ expressed towards the business: a responsibility engineering is happy someone else can deal with. We never know for sure if the moment is right, oftentimes not even in retrospect. While there’s a benefit to iterate on the product, we see a lot of energy wasted when we fall victim to perpetual optimisation on roadmap planning and delivery iterations.
If you try to make it more flexible than quarters, you run into complex process situations where we can no longer explain it and it will not scale in companies with say more than 150 people (Dunbar's number 🔗).
Team Collaboration and Communication
Engineers appreciate when product managers are curious about how the product is technically built, so, as a PM, try shadowing or even being an engineer for a day; go through the whole flow of coding something like a small string change and push it to production. You cannot imagine the level of empathy you gain.
At Showpad, there’s a three-flight team structure that helps clarify responsibilities when it comes to working together at scale (The 3 Flight Levels 🔗) :
- Level 1: Team members are not accountable for the delivery, but they set acceptance criteria and have a certain level of leeway to make calls.
- Level 2: People are less involved in the day-to-day, but they do more coordination and look ahead to prepare the next iteration.
- Level 3: A purely strategic role having the communication skills to understand high stakes, they have more cross-functional interaction.
This three-flight structure applies to all roles. Level 3 representatives from different departments team up to form AMPED clusters (Analytics, Marketing, Product, Engineering, Design): multifunctional teams who streamline decision-making and make informed product bets.
For instance, a feature’s Definition of Done (DoD) includes Marketing’s input on release communication to ensure clear value increments. Observe the process through which customers adopt new functionality and identify the right moment for optimal release timing (commoditizing markets may need to grow a platform). If the customer’s perception is that the product is evolving, they’ll believe in it. While internally you may be reinvesting in platform improvements, you can still create customer delight.
Do not skip the opportunity to translate a technical narrative into a business context assuming the business wouldn’t care. Get creative on the format/language to get their attention but do communicate about the hard work done even if not everyone understands it. It’s enough to get one person rallied to get people to talk about the good stuff and you safeguard yourself from having the work being taken for granted. You can then split the audience and only present the implementation details to the technical community (helps with street credibility).
Operational Insights from Engineering
As product managers, we should be mindful about taking up responsibilities that are not part of our role. To prevent this, be aware and transparent of what you should or should not do and find ways to express that. Don’t get stuck into the habit of picking up the slack where you see a gap just because you know it needs to be done. Get your priorities straight so you can find that strategic flow.
For recurrent things like release communication, documentation or troubleshooting, the only way to scale ourselves is by getting them implemented in the team. After establishing how to do something, get out of the way and let the team handle it. This makes the full definition of done clear to everyone: it ensures the features are truly done before deploying and helps reflect on the undone work and, therefore, evolve as a team.
As engineers, it doesn’t matter how much code you write but how much is used, the value that it brings. Go beyond the archetype and open up the world of engineering: get a dev out of their coding world and put them next to a customer success agent. Bridge the gap between doing a commit in the main branch and understanding how the software meets those customer needs with frameworks like jobs-to-be-done or Design Thinking processes.
For a harmonious relationship with engineering we should all remember their job is focus-driven and requires an environment conducive to deep work. As a product manager who’s more likely to tolerate context switching, try to understand your developers’ flow; it is basic, but it will take you far. That doesn’t mean they stay secluded in their world since we all have diverse backgrounds and skillsets, but the frequency of switching activities should have a stable rhythm.
At the end of the day, don’t make too many assumptions. Some engineers hold the product role and are PMs who don’t have an engineering education but can intuitively use low/no-code or generative AI tools and become ‘makers’. Other PMs excel at the commercial side of the business and bring more value by staying close to the customers while engineering is more autonomous in their day-to-day. You’ll find a spectrum of business-savvy technologists and technology-savvy businesspeople so just get to know the people behind the function and avoid working in isolation.
Key Takeaways
Here’s our insights. Share your viewpoint for a richer conversation.
- What does an engineer expect from a product manager?
- lead by example in understanding and empathizing with users
- balance ambitious business expectations with practical engineering constraints
- Iterate on your budget to deliver customer value and business viability
- Can we keep distinct responsibilities but converge on the success metrics?
- Distinct separation of responsibilities ensures accountability and efficiency
- Partner with architects for ‘architectural runways’ aligning with business goals
- Before product trio became popular, remember the good old ‘three amigos’
- How tech leads guide their team in their technical choices is key to delivery
- Product and engineering need a common denominator in the leadership team
- Solution design: translating the ‘why’ and ‘what’ into the ‘how’
- Avoid overly prescriptive solutions; allow for emergence in delivery
- Use Domain-Drive Design to represents the core business concepts and processes
- Why is ‘technical debt’ not only an engineer’s problem?
- Technical debt decreases the rate of value delivery when scaling a product
- Prioritize areas where growth is planned to manage tech debt where needed
- Back up features for a healthy growth perspective on the market
- Bonnie & Clyde: the risk of going rogue in absence of other product friends
- The 3-flight structure helps clarify responsibilities across different levels of involvement
- The AMPED clusters help streamline decision-making and make informed product bets
- Translating technical narratives into business contexts demystifies the engineering work
- A product manager’s guide to an engineer’s operating system
- Be aware of what you should or should not do and find ways to express that
- Foster customer-centric engineering with JTBD or Design Thinking
- Minimise context switching to maintain a stable working environment for engineers
The collaboration between product and engineering is a multifaceted endeavour that requires clear communication, empathy, and shared accountability. By understanding each other's perspectives, leveraging diverse skills, and embracing a culture of collaboration, product development teams can drive innovation and deliver value to customers effectively.
