As a pragmatic product manager (PM), I love simple frameworks and lightweight approaches. Engineering-Driven Development (EDD) resonates with me for that very reason. It’s a fast, direct way to create products, with engineers in the driver’s seat.
I recently read a really good article about EDD that questions the role of PMs in fully empowered engineering teams. Here’s the gist:
The rise of EDD is making PMs increasingly redundant. Engineers are taking over tasks that were once the domain of PMs.
So, it begs the question:
Once engineers dictate all aspects of a product, do we even need PMs? Are we heading toward obsolescence, or can EDD and PMs coexist?
What is EDD?
EDD is a software development approach where engineers lead the product. Engineers code and make key decisions about the product’s architecture, features, and strategy.
It’s a lean way to create outcomes as fast as possible.
Engineers are typically in close contact with customers and end-users. They translate feedback directly into the product. There’s little need for lengthy meetings or back-and-forths with other departments. With additional real-time data and deep technical expertise, EDD teams are well-equipped to make product decisions. Hence, such teams potentially fly solo.
EDD can benefit highly technical products or products in new markets where the technology is a differentiator.
EDD and Product Managers
If you are wired like me, you’ll find it both educational and fun when engineers contribute significantly to product decisions. You learn a lot, and excellent products emerge from this direct approach. I’ve spent many years with such teams. I sincerely enjoy these environments.
Nevertheless, I get the point of EDD.
In traditional setups, product managers would outline the what and why, which leaves the how to engineers. EDD flips the script. Engineers are dictating not just the how but also the what and why.
The emergence of EDD can be potentially unsettling for PMs. Teams fully embracing EDD often lack a PM. If you’re new to this, it might feel like a supporting actor suddenly taking the lead role. 👇

In EDD, engineers are becoming the sole decision-makers. They encroach on territories that were traditionally the domain of PMs, bypassing the need for such a role.
Is There Any Collaboration Possible?
So, back to the question of whether EDD teams and PMs can be complementary. I can only talk about my experience, so here is my take:
In reality, tons of different product-related tasks pile up on the side. As these tasks grow, they create more work for the team. Over time, engineers would wear a lot of hats. And my experience is that (many) engineers even don’t want to wear all these hats. It sucks a lot of time.
That’s where PMs can come in handy.
Think of supporting activities like coordination between different teams and stakeholder management, deep dives into requirements for effective discussions, internal technical training, etc.
Let’s break it down a bit:
Requirements Refinement:
PMs can help translate the bulk of customer requirements. Preparing structured content or potential tasks for team discussions can be hindering, specifically once the list of requirements gets longer. And this typically happens at some stage. Even in engineering-driven setups.
Additional Customer & Market Insights:
PMs can provide additional customer insights. This might include organizing user groups, feedback sessions, and customer demos. Engineers don’t need to organize and coordinate everything. Furthermore, PMs can support monitoring the market and competition.
Prioritization and Roadmapping:
PMs can help determine technical priorities and maintain roadmaps. There are generally tons of topics the teams can work on. Structuring the information for faster decision-making with the team helps. In EDD, it’s probably more about helping with the roadmap, not owning it.
Stakeholder Management and Alignment:
PMs can liaise between engineers and other departments like management, marketing, sales, QA, and customer support. This is a big one, in my opinion. I spend a substantial portion of my PM time on such tasks (I like it). Ultimately, this creates more focus time for engineers (they like it).
User-Centric Design Influence:
PMs can ensure user experience (UX) is a priority through usability testing, design guidelines, and user feedback. From my experience, helping engineers with all these details is typically more than welcome.
Technical Training:
Another task I spend time on is to help spread product knowledge internally and for customer support, ensuring effective problem-solving and understanding of what gets built, how it works, where details can be found, etc.
Partnerships:
Identifying monetization avenues and partnerships for expanded business models might be another task for PMs. Even if there are other people in the organization who work on it (channel partners, sales, etc.), it can be a complementary activity. I have always enjoyed investing my time in partnerships. It’s good fun and typically very interesting.
Risk Management:
PMs can proactively identify potential risks. These topics might slip from the radar when things are going well. It’s also not a super fancy topic. Think also of data privacy and security matters. PMs can put it on their list and help with that.
Communication Structures:
PMs can help improve internal communication structures. Yes, this also takes time. Engineers greatly benefit from simple yet effective structures to spend more time on the things that leverage the business outcome.
Resources Management:
PMs can handle logistical aspects, such as budgets and timelines. They can step in to allocate the necessary resources and negotiate achievable deadlines. All the “boring” stuff …
Marketing:
PMs can help craft the marketing strategy and manage SEO strategies to reach the right audience. If other marketing experts are involved, PMs can help coordinate everything, as already mentioned.
EDD and Scrum: A Short Note
This just came up for me: I wonder what Scrum advocates think about EDD. The discussed software development approach is so different from the Scrum framework. It’s obvious that a Scrum master and product owner don’t fit into the EDD concept. I am not much into Scrum, so I can’t say. My “framework” is a rather minimalist and lean one (here is the guide).
Presumably, some software projects may align well with EDD, while others are better suited for Scrum. I guess. 🤔 Anyway. Let’s wrap this up.
Wrap Up
I am unsure whether I get the EDD thing 100% right and whether the above makes sense. After writing down the list of complementary PM tasks, it almost feels like a standard list of “traditional” PMs again. 😅
Nevertheless, these thoughts stem from my years of experience within highly technical autonomous teams. We’ve never called it “EDD” explicitly, though. In my world, it’s just a normal way of creating software.
Some EDD teams might not need a PM for the listed tasks. It’s a matter of the company structure and size, the culture, the product’s stage and nature. Oh yeah, and the people involved. The personalities of the PMs and engineers play a significant role in whether a meaningful collaboration can work in EDD environments.
So, what to do now with this trend?
As a PM, I’m relaxed. It’s unclear anyway what will happen in the next couple of years with AI being on the rise and increased automation. Things are moving fast at the moment.
Yes, it’s possible that things dry out for us PMs if this gets more traction.
However, my assumption is that EDD teams can still coexist with PMs. Well, not just coexist but have good fun and benefit from each other.
The rise of EDD is just an exciting development in the tech landscape. It’s an opportunity for engineers and PMs to potentially redesign the traditional team setup. Reducing the complexity of internal processes is a good thing.
In that sense, EDD is a role model.