Confessions of a Product Manager: Developers Are Not the Problem

Erin Clark
4 days ago
3 min read

When TEC Consulting Director Erin Clark took the stage at West Tech Fest, she opened with an apology.

Not to founders. Not to executives.

To developers.

After more than two decades working on technology projects across organisations of all sizes, her confession was simple:

Developers are rarely the problem.

More often, they are absorbing the cost of unclear thinking, unrealistic planning, and weak product discipline elsewhere in the system.

Developers build. Product teams create the conditions

There is a persistent myth in technology delivery that building great products is simply a matter of “getting some developers” and letting them get on with it.

In reality, developers do their best work when they are given clarity, focus, and space to think. What undermines that is not a lack of capability, but a lack of decision-making upstream.

Building tech products is not a casual activity. It requires deliberate planning, active product management, and conscious protection of developer time and attention.

Without these, even the most capable teams will struggle.

Confession #1: Roadmaps built on wishes, not capacity

One of the most common failures in product delivery is the roadmap that assumes infinite energy and zero constraints.

Features are stacked end to end. Timelines are compressed. Trade-offs are avoided. The roadmap becomes a wishlist rather than a delivery plan.

From a developer’s perspective, this feels like an ultra-marathon disguised as a sprint. No recovery. No margin. No room to do quality work.

Strong product leadership starts with constraints. Capacity, not ambition, defines a roadmap that can actually be delivered.

Confession #2: Assuming developers can infer requirements

Unclear requirements are often treated as a development issue rather than a product failure.

Briefs are vague. Edge cases are unstated. Processes live in people’s heads. Frustration follows when the output does not match unspoken expectations.

Developers are not mind readers.

Wireframes, process maps, acceptance criteria, and clear decision rules are not bureaucracy. They respect the people building the product.

Requirements aren't supposed to be interpreted through dance

Confession #3: Changing priorities without protection

Developers are frequently exposed directly to organisational noise. “Quick changes” arrive mid-sprint. Priorities shift without context. Flow is constantly interrupted.

This is not agility. It is erosion.

A core responsibility of product leadership is to act as a buffer. To manage volatility, make trade-offs explicit, and protect developers so they can focus on building great things.

Building tech products is a discipline

Great products do not emerge from heroics or raw technical talent alone. They are the result of disciplined decisions, clear ownership, and continuous stewardship.

That stewardship means:

planning that reflects reality
clarity about what is being built and why
leadership that actively manages the delivery environment

Developers solve complex problems. Product leaders must ensure those problems are worth solving and clearly framed.

When projects go off track

Many of the organisations TEC Consulting works with come to us when a development project is already under pressure. Timelines are slipping. Teams are frustrated. Confidence is low.

We provide project and product rescues for technology initiatives that are off course.

Our role is to: