Where does the Product Manager’s responsibility end, and where does the Tech Lead’s role begin? And what should happen when the business pushes for a deadline, the Product Manager is focused on delivering the outcome, and the engineering team sees a risk that cannot be ignored? In this episode of On the Edge by E1S, we examine the collaboration between a Product Manager and a Tech Lead through the lens of everyday decisions: defining scope, negotiating timelines, protecting the team from context switching, and building the trust needed to say “no” openly – always with evidence and a viable alternative. Natalia Szindler-Markiewicz, Senior Product Manager at Allegro, and Mariusz Batyra, Tech Lead at Edge One Solutions, explain how shared decision-making affects delivery predictability, stakeholder relationships, and team effectiveness.
🎧 Listen to the episode and discover how to build effective Product Manager–Tech Lead collaboration without creating a barrier between Product and Engineering.
Spotify:
YouTube:
Where does the Product Manager’s responsibility end and the Tech Lead’s begin?
A simple division: The Product Manager is responsible for deciding which problem is worth solving and what business outcome the product should achieve. The Tech Lead is responsible for how the solution will be built, what risks it involves, and whether the team can deliver it safely.
In theory, the division seems straightforward. The Product Manager is responsible for what should be built and why it is worth building. They should understand user needs, business objectives, stakeholder priorities, and the expected outcomes. The Product Manager’s responsibility also includes making decisions about value, the order of initiatives, and product scope. It does not, however, mean setting the delivery date or defining the implementation approach independently.
The Tech Lead is responsible for how the solution will be built. They assess feasibility, technical risk, dependencies, the impact on architecture, security, maintainability, and the team’s available capacity. The Tech Lead’s responsibility is not limited to code quality. It also includes creating conditions in which the team can work without constant disruption, overload, and context switching.
| Area | Product Manager | Tech Lead | Shared decision |
|---|---|---|---|
| Problem | Defines the user need and business objective | Identifies constraints and available technical options | Is the problem important enough and feasible to solve? |
| Scope | Defines the priority and value of individual elements | Assesses cost, dependencies, and risk | What is the smallest scope that can achieve the objective? |
| Timeline | Provides business context and explains why the date matters | Assesses feasibility and the level of uncertainty | What scope can be delivered within the available time? |
| Delivery | Protects the intended product outcome | Leads technical decisions and supports the team | How should the team respond to new information and changing risk? |
This model should not be treated as a rigid division. The Product Manager may formally own the scope, but should not define it without understanding the technical cost. The Tech Lead may own the implementation approach, but should not make decisions without understanding the user problem and business objective.
What requires a shared decision?
- the scope that can realistically be delivered within a specific timeframe,
- the order of initiatives competing for the team’s capacity,
- the acceptable level of risk,
- how the solution should be divided into stages,
- how to respond to a change in priorities,
- how the consequences should be communicated to stakeholders.
Key takeaway: do not try to separate the roles with a rigid boundary. Define decision owners, but discuss scope, timeline, and risk together.
When should a Tech Lead be involved?
A Tech Lead is most often involved too late. First, the expected scope is defined, UX prepares complete designs, stakeholders approve the direction, and only then does the engineering team receive the material for estimation. At this stage, every comment from Engineering can look like an attempt to delay the project. Expectations have already been set, the deadline has already been mentioned in a meeting, and the solution is already being treated as approved.
Problem definition
The Product Manager presents the user need and business outcome. The Tech Lead helps identify constraints, dependencies, and available technical options.
Early discovery
The Tech Lead assesses which assumptions need to be validated, which systems will be affected, and whether the team should begin with an experiment.
Refinement with the team and UX
The team analyses edge cases, dependencies, and elements that may look simple in a design but significantly increase implementation complexity.
Delivery decision
The Product Manager and Tech Lead agree on scope, risk level, delivery sequence, and how the timeline will be communicated.
Involving the Tech Lead early does not mean inviting them to every meeting. They should be involved while there is still time to change the scope, the solution approach, or the order of work.
Questions worth asking before the final designs are prepared
- Does the organisation already have data or components that can be reused?
- Which systems and teams will be affected by the change?
- Where is the greatest technical uncertainty?
- Is the deadline driven by a genuine business constraint?
- Does the full solution need to be included in the first release?
- How can the assumption be validated at a lower cost?
Key takeaway: involve the Tech Lead while the problem, scope, and solution concept can still be changed. Do not wait until all you need is an estimate.
Who should say “no” to the business?
Neither the Product Manager nor the Tech Lead should say “no” to the business alone. The Tech Lead may explain that the solution is not feasible within the expected timeline. The Product Manager may decide that the initiative does not deliver enough value. In both cases, a simple “no” rarely closes the discussion. The stakeholder still has a problem they are trying to solve. If the team responds only with a refusal, the pressure will probably return in another form — often from a higher level of the organisation and with an even shorter deadline.
A constructive “no” does not end the conversation. It explains the objective, the constraint, the consequence, and a realistic alternative.
01ObjectiveName the outcome the business needs. Do not reduce the discussion to a feature or a date. | 02ConstraintIdentify the specific dependency, capacity limitation, uncertainty, or technical risk. |
03ConsequenceShow which objective will be delayed or which risk will increase if the new initiative is accepted. | 04AlternativePropose a smaller scope, phased delivery, an experiment, or another route to the intended outcome. |
What could a constructive response sound like?
Instead of: “We will not deliver this by the end of the quarter.”
Say: “The full scope requires changes across three systems and will not fit into this quarter unless we stop the migration. We can, however, release a simplified version for the most important customer segment before the campaign and deliver the remaining scope in the next phase.”
The Product Manager brings knowledge about value and priorities to the discussion. The Tech Lead provides evidence about feasibility and risk. Only by combining both perspectives can the team negotiate a realistic path forward instead of simply rejecting the request.
“I cannot go back to the business and simply say: no, because we cannot do it. I need to know what is negotiable and what options we can offer.”
The most dangerous situation occurs when both roles say “yes”. The Product Manager does not want to disappoint stakeholders, while the Tech Lead commits to a deadline without consulting the team. In the short term, the business is satisfied. Later, the organisation pays the price through delays, defects, overtime, and lost trust.
Key takeaway: do not ask who should push back. Agree on a shared position: what is feasible, what it will cost, and which alternative best protects the business objective.
How should teams discuss timelines and estimates?
An estimate is not a declaration made by the Product Manager or a personal promise from the Tech Lead. It is an assessment of the expected delivery effort based on the information currently available. When the business sets a fixed deadline, the team still has to manage three variables: scope, available capacity, and the acceptable level of risk and quality. The deadline may remain fixed, but the scope must then be open to negotiation.
Timeline
Is the date driven by regulation, a campaign, a contract, or simply an expectation?
Scope
Which elements are essential to achieve the intended outcome, and which can wait?
Capacity and risk
What other commitments does the team have, and how much uncertainty does the initiative involve?
How can an estimate become a decision-making tool?
Instead of asking only, “How long will this take?”, the Product Manager and Tech Lead should answer the following questions together:
- Which part of the solution delivers the greatest value?
- Which elements are essential to achieve the objective?
- Which assumptions have not yet been validated?
- What could delay delivery?
- What will we consciously deprioritise if we start this initiative?
- What decision will we make once additional data becomes available?
Consider a team asked to extend a customer portal before new regulations come into force. Instead of estimating the entire idea as one package, the team can divide it into mandatory compliance changes, operational functionality, and additional UX improvements. This protects the regulatory deadline while preventing less critical elements from blocking the entire release.
Delivery predictability does not mean that the deadline will never change. It means that risks are visible, decisions are made consciously, and stakeholders do not discover a major issue during the final week of the project.
Key takeaway: estimate options and consequences, not only the number of days. A useful estimate supports scope decisions instead of merely producing a date.
How can the team be protected from context switching?
The Tech Lead plays an important role as an information filter. This does not mean that the team should be kept away from product strategy. It means that not every future initiative requires the immediate attention of the entire engineering team. In a single day, a Product Manager may discuss the current sprint, plans for the next quarter, and a product vision for the next two years. When all these topics are passed directly to developers, the team starts analysing problems that are not yet ready for delivery. An engaged team will identify edge cases, assess dependencies, and anticipate potential issues. This behaviour is valuable, but when triggered too early, it creates context switching and distracts people from the current objective.
| Level | Who should be involved? | Purpose of the communication |
|---|---|---|
| Strategy | The entire team, at an appropriate level of detail | Understanding the product direction and future problem areas |
| Discovery | Product Manager, Tech Lead, UX, analytics, and selected experts | Validating assumptions and identifying risk |
| Delivery | The entire delivery team | Maintaining focus on the agreed objective and scope |
In practice, the Product Manager and Tech Lead can discuss early-stage ideas during a regular one-to-one meeting. Once the topic has reached the right level of maturity, they can involve UX, analytics, or selected developers.
“If every topic went directly to the team, instead of focusing on the current objective, people would already be analysing work planned for the next quarter.”
How can teams reduce context switching?
- establish a regular Product Manager–Tech Lead communication rhythm,
- separate informing the team about strategy from actively involving it in analysis,
- do not introduce early-stage ideas without clearly communicating their status,
- limit the number of parallel initiatives,
- connect every urgent change with an explicit decision about which other work will be delayed,
- protect the team’s time for delivering the current objective.
Key takeaway: do not hide the strategy from the team, but separate informing people from actively involving them. Each topic should reach the right people at the right time.
How can trust be built between the Product Manager, Tech Lead, and team?
Trust within a team is not created by a positive atmosphere alone. It develops when both sides behave consistently and predictably, especially under pressure.
The team trusts the Product Manager when the PM:
| The Product Manager trusts the Tech Lead when the Tech Lead:
|
Start with explicit working agreements
At the beginning of the collaboration, it is worth creating a simple responsibility matrix. It does not need to become an extensive RACI document covering every process. It should answer practical questions:
- Who makes the prioritisation decision?
- Who approves the technical direction?
- Who communicates a change in the timeline?
- Who represents the team in stakeholder discussions?
- When does a decision require joint agreement?
- How should an unresolved disagreement between the two roles be escalated?
Three foundations of trust: explicit ownership, a consistent communication rhythm, and the ability to resolve misunderstandings quickly.
The second element is a shared operating rhythm: regular Product Manager–Tech Lead conversations, team refinement sessions, quarterly goal-setting meetings, and written records of the most important decisions.
The third element is open communication. If the way a message is phrased crosses a boundary or causes discomfort, it is better to clarify it immediately than to spend several weeks interpreting the other person’s intentions.
Trust does not eliminate conflict. It allows the team to work through conflict without losing the ability to collaborate.
Key takeaway: build trust through consistent behaviour, clear decisions, and rapid resolution of tension, not through declarations that the collaboration is working well.
What mistakes should both roles avoid?
The Product Manager accepts every requestStakeholder pressure is passed directly to the team, the backlog grows, and priorities lose their meaning. The Product Manager’s role is not to maximise the number of accepted requests, but to maximise value within limited capacity. | The Product Manager designs the technical solutionTechnical knowledge helps a Product Manager ask better questions, but it does not create a mandate to dictate implementation. “It only requires one condition” usually ignores dependencies, testing, monitoring, and error handling. |
The Tech Lead automatically blocks ideasA response such as “it cannot be done” without evidence leaves the Product Manager unable to continue the discussion with the business. A technical leader should help identify a feasible path to the objective. | The Tech Lead commits without consulting the teamCommitting to scope and a timeline without checking capacity may satisfy stakeholders during one meeting, but the team and future initiatives will carry the cost. |
A shared mistake: defending the role instead of the objective
When the Product Manager defends scope and the Tech Lead defends capacity, the discussion quickly becomes a negotiation between two competing sides. Both roles should defend the same thing: achieving the objective without destabilising the product or the team.
Key takeaway: evaluate behaviour by whether it improves the likelihood of achieving the objective without hiding the cost, not by whether it strengthens the position of a particular role.
How can delivery predictability be improved?
Delivery predictability does not begin with a more precise estimate. It begins with the quality of the decisions made before delivery starts.
One shared objective
The team should understand the outcome it is expected to achieve. A clear objective supports better decisions when the scope needs to be reduced.
Early risk identification
Dependencies, technical unknowns, and data constraints should be discussed before the team commits to a delivery date.
Explicit reprioritisation
Every urgent request has an opportunity cost. The team should clearly identify what will be delayed or reduced.
Documenting decisions
A short written summary after refinement reduces later disputes about what was agreed and which risks were accepted.
The ability to cover for each other
The Product Manager and Tech Lead should understand the context well enough to represent shared decisions during leave, illness, or a critical release.
Strong collaboration between a Product Manager and a Tech Lead does not guarantee that every initiative will follow the original plan. It does, however, ensure that problems are not hidden and that changes do not surprise the business at the final stage of delivery.
Key takeaway: delivery predictability is built through transparent decisions, limited work in progress, and early risk management, not through pressure for more confident commitments.
A five-step Product Manager–Tech Lead collaboration model
The core principle: The Product Manager and Tech Lead do not need to agree from the outset. They do, however, need to use one shared process for reaching a decision.
- Start with the problem. The Product Manager explains who is affected, what the cost of the problem is, and why it should be addressed now.
- Then identify the constraints. The Tech Lead highlights dependencies, risks, and technical unknowns without immediately forcing a final solution.
- Compare the options. The pair evaluates the full scope, a phased solution, an experiment, and the option of not pursuing the initiative.
- Make the decision explicit. The team understands what it will deliver, what it will not deliver, and which risks have been accepted.
- Communicate together. The Product Manager and Tech Lead present one position and the same set of consequences to stakeholders.
Business impact of this model
Fewer unexpected delays, fewer unplanned requests entering delivery, greater control over team capacity, and more credible delivery communication with executives and stakeholders.
Key takeaways
- The Product Manager and Tech Lead should not operate as two competing decision-making centres.
- The Product Manager owns the problem, value, and priorities, while the Tech Lead owns feasibility, risk, and the implementation approach.
- Scope, timeline, and the acceptable level of risk require a shared decision.
- The Tech Lead should be involved before the solution is approved and stakeholder expectations are set.
- A mature “no” includes the objective, the constraint, the consequence, and a realistic alternative.
- Estimation should support the choice between delivery options, not simply confirm a date.
- Protecting the team from context switching requires control over when information is shared and how much detail is introduced.
- Trust is built through predictable behaviour on both sides, especially under pressure and during reprioritisation.
- Delivery predictability depends more on decision quality than on the apparent precision of an estimate.
Summary
The Product Manager and Tech Lead are not on opposite sides of a barricade. They are looking at the same problem through different types of risk. The Product Manager sees the risk of losing value, missing a market commitment, or failing to address a user need. The Tech Lead sees technical risk, team overload, dependencies, and the long-term consequences of shortcuts taken under pressure. An organisation does not lose predictability because the two roles overlap. It loses predictability when these risks are assessed separately and decisions are made without shared ownership.
A mature Product Manager–Tech Lead partnership can:
- bring the technical perspective into the discussion early,
- separate the objective from the first proposed solution,
- negotiate scope instead of hiding risk,
- protect the team from excessive work in progress,
- provide the business with evidence and alternatives,
- resolve misunderstandings quickly,
- communicate with one voice once a decision has been made.
Ultimately, the question is not who is in charge. The real question is whether Product Management and Engineering Management operate as one decision-making system or as two competing centres of responsibility.
