Before the specs, the Jira tickets, the sprints, and the briefs, there are agile tech companies. These are the startups built by people hacking away at problems their customers talk about online. Engineers aren’t in a corner with noise canceling headphones, they’re listening in on customer calls with their support team. They’re joining customer-facing events with their marketing team. They’re meeting the people who pay their salaries and building what they ask for.

This is engineering-driven development. It’s common in lean teams and startups because of the rapid motion from understanding a market need to shipping a solution. And it’s back in full force. From startups to FAANG companies, tech culture is talking about a world where there are fewer PMs and more engineers that can both code and strategize.

We’re here to tell you why, how it can work for your organization, and to set you up with the tools to get it right.

What is Engineering-Driven Development

Let’s start from the top. What is engineering-driven development (EDD)? EDD occurs when your product and its features are initiated, defined, and executed by your engineering team. Your engineers are both deciding what to build, defining scope, building, and looking at the impact of product updates.

In general, this looks a lot like engineers taking on core product tasks and removing product managers (PMs) from an organization. This is separate from engineering-led organizations which put a focus on the engineering department. EDD instead puts the product development process (concepting through retrospective) in technical hands. There’s always variation on how EDD can be implemented, but the core idea boils down to fewer to no PMs while engineers stay much closer to the product and customers.

Here’s how to think about organizations that are product-led, engineering-led, and focused on engineering-driven development.

Why EDD over other models?

By and large, the push toward EDD comes from a desire for leaner, faster, smarter development.

For some, “engineering productivity is the capacity to measure if your engineering teams are doing the right things, with the right investment, to achieve a specific business outcome.”

This parallels nicely with Hiten Shah’s recent thoughts on the topic. His current company, Nira, has no PMs. The thinking here is to keep engineers closer to “the solution.”

“Even when we hear things from customers who are still in trial or a prospect, we will ship a feature that they want. Not because it’s on the roadmap or eng wants to work on random things but because when we hear something good that everyone can benefit from, we’ll build it as fast as we can. The only way to do that is to cut the product function out of non-eng hands” he told us.

EDD means product engineers spend their time talking to customers, looking at usage data, and researching the competitive landscape while also testing and experimenting. This is a much broader role than a traditional engineer who is focused on writing code, testing, and maintaining.

But what’s removed from this process is arguably more important than what’s added to an individual engineer’s workload. For the company as a whole, gone are meetings, docs, and crossteam duties that scope and prioritize. Forget Jira tickets, cross-team alignment meetings and those even rarer retrospectives, monthly reporting, and OKR alignment sessions.

This is a larger shift than what meets the eye. Engineers have always been focused on speed of development but with EDD, engineers are focused on finding the right solution as well. The speed up comes from the whole company moving (hypothetically) faster even if individual engineers have more on their plate.

It’s no surprise then that EDD is common among startups and lean companies. They might not even label themselves as EDD; it’s just something that happens when a small team is building a company together and in tight communication. You can argue that most startups are EDD by default since many software companies only come to be when an engineer has an idea and puts fingers to keyboard to code a solution.

This is true of almost any company going through an incubator like YC, tech stars or another. The idea of funding marketers without an engineer is incredibly rare.

The current market favors engineering-driven development

There’s historical context for this arrangement. In their early days, Stripe was known for not having PMs.

“We don’t have any dedicated product managers today. Or, more accurately, engineers manage products themselves,” Patrick Collison, a Stripe cofounder, told Forbes.

Today, Stripe’s known for hiring product engineers, or people who can code but also understand what solution must be created. Stripe’s not alone. Meta recently announced “a more optimal ratio of engineers to other roles” as it looks to “keep technology the main thing.” Even more drastically, AirBnB eliminated its product managing function.

It would be remiss for us not to mention that leaner teams are no surprise given recent layoffs and financial instability in the tech market. One reading about Meta’s strategy sees how this as both a play for budget cuts and innovative thinking (which tend to go together). If you’re a startup trying to raise funding in 2023, it’s tougher than it used to be. It follows that if you can find a way to hire one product engineer instead of an engineer and a PM, you’re going to do it.

In fact, we liked the symmetry between the origin of the term engineering-driven development and the funding market. For example, earlier we talked about Stripe’s zero-PM strategy, which was printed in Forbes 2010. The internet’s current definition for engineering-driven development heralds from a 2017 medium post. Even Hiten mentioned that the rise in this term and thinking was a “swing” back toward what led the conference circuit around a decade ago.

We see there being a strong correlation between strapped cash and the necessity for EDD, especially given that today’s investment market certainly is in ways reminiscent of that in 2010.

Engineering roles are expanding in scope

Asking a specialist to, in fact, own two specialties is nothing new. It’s something designers and marketers are quite familiar with. The boom in the startup scene gave rise to the technical marketer and the unicorn designer who could design and code. Arguably, projects move faster when the person who understands the problem and solution is the one implementing it.

Notion is famous for recruiting designers that can code. Stripe for engineers who can do product. And many solopreneurs or first hire marketers are communicators just dangerous enough with HTML and CSS to make their own low-code products. Perhaps we’re simply in a world that now asks engineers to empathize and prioritize in much the same way their non-technical counterparts have been for years.

Intercom’s known this for years and known for hiring product engineers who are expected and encouraged to do more than just code.

“Product engineers are experts at identifying, understanding, and solving problems. But the problems you tackle – and therefore the impact that you have – don’t have to be limited to the work you do within a text editor or integrated development environment (IDE),” Intercom says.

The demand for engineers who can do both right brain and left brain work makes sense given the recent advancements in AI and the popularity of Chat-GPT. Robots can be trained to do complete tasks, check code, and get you to your substack answer faster but they’re not able to listen to a customer, decipher what they meant to say and develop a product solution from a thirty minute interview.

How do you make EDD work for your company?

Things aren’t as simple as turning to your engineers and asking them to start building…whatever. Throughout every post and interview about EDD is a similar message: it’s successful when you’re talking to your customers.

In companies with a successful EDD culture, engineers are communicating with prospects and paying customers, reading or implementing surveys, building and then listening for how their work was received through qualitative and quantitative feedback. Without this, you’re shooting yourself in the foot.

Let us repeat, EDD is not about building whatever, or what would be neat, or what would be cool. It’s about hearing a customer pain point and then rapidly developing it without a middleman between customer and builder.

For example, in Hiten’s engineering-driven org, engineers may be driving product development but whether or not it passes the customer sniff test is an external process.

“Who owns the solution? We want engineering to own that. But someone has to be responsible for ‘did it meet the customers’ needs.’ I know that sounds weird because they own ‘the solution’ but to determine if that solution passes to the customer… that’s the people’s job, the ones who understand the problem deeply,” Hiten said.

This requires an information feedback loop between the customer and engineers, which is the rub between engineering-driven development and an engineering-led organization. The research aspects of product development are still there, they’re just being internalized and digested by engineering.

Put crisply, “We don’t hire people and make them product people, we hire engineers and give them the information and ability to prove if they did it or not,” Hiten said.

Analytics for engineering-driven development

On that note, customer data and information comes from many places. Both Hiten and Ben Williams (who we interviewed previously) are heavy proponents of getting on a call and talking to your customers.

We’d add quantitative customer data to the list of ways product engineers can understand and empathize with your customers. Product and lifecycle analytics tell you how customers are thinking and feeling at scale. See a drop off on your signup page? You better find out why your customers are bouncing. Build a new feature that no one’s engaging with? Sounds like you need to figure out why? Usage on a popular feature down? Is there a bug? Keeping smart data accessible in EDD organizations is key to making informed decisions, and it empirically pointing engineerings to high-priority problems.

With that in mind there are a few June templates that work out-of-the-box that to give context to what’s going on in your business. The best part is that engineering doesn’t have to do the work to build, create, or support these reports and dashboards. We pride ourselves on providing key analytics out-of-the-box to save everyone on your team time.

If you’re curious where customers are hating your signup flow, look where they drop off:

Another key metric is feature adoption. Once a feature is shipped, engineers can use this report to understand whether users are getting value out of it or if an iteration is needed.

In Hiten’s words, “You have to build a product that customers love. Be customer obsessed.”

Of course, when you use June, we auto-generate key product reports and metrics out of the box. So when you get started with June, you’ll see insights from day one. From there, it’s easy to add reports and create what Ben suggests in this post.

Listen to The June Podcast with Hiten Shah