My engineering team ships fast and it is making it hard for design and product

Everywhere I have been, read, or heard, the teams are struggling to meet the deadlines. Engineering is always the bottleneck. There are never enough resources and ad-hoc issues reduce the velocity.

Our team is on another level. We are short on Design and Product. Whereas, we have more than enough Engineers.

The problem is, engineering is nearly a quarter ahead of the defined timeline. They are shipping like crazy.

Product and Design are unable to cope up with that. We need our bloody time to get through things before we can finalize a requirement.

This is leading to engineers prioritizing and leading the entire product. This is leading to a lot of frustration and attrition in the Product team.

I am not sure whether anyone else has gone through this, but if you have or can suggest a potential solution, I’d be grateful.

2 Likes

You are lucky to have a high-speed delivery train already running. All you need is to help it going the right direction.

You could involve engineering in the product discovery work - show them how you identify the most relevant problems and ask their help in defining solutions and implement. You also might need data, analytics, a prototype, user research with demos, discussion on feasibility with engineers. Join forces with them on road mapping, making both technical debt items and new features visible.

After a release (prioritized by them or by you), do the verification of the outcome, show what you did and the customer results.

In general, this could help to show the value of the product work to your organization and build up good cooperation with engineering.

I wouldn’t try to slow them down or claim full prioritization mandate if you don’t have the capacity to keep the current delivery speed, if prioritization done by engineering does not create any harm for your customers or the service you provide. Don’t let your ego frustrate you, instead see what’s best for the customers. A prioritization done by someone else is possibly better than no prioritization and no delivery.

Your description shows possible signs of “we and them”, and functional silos in your organization. You could try to form a cross-functional team with product, design, and engineers, and see if you can deliver confirmed better outcomes that way.

4 Likes

it’s not the ego if entire Product and Design team is facing the heat.

Our issue is, we get blamed even when we are trying our best to do the job at their pace.

1 Like

I see. Is it the expectation that product prioritizes everything? What are you measured on?

1 Like

No, the product team is not alone responsible for prioritizing.

We are measured on the number of features we ship out per release.

And the issue is not alone prioritization but the entire PDLC.

1 Like

In my opinion, you are measured in the wrong way. If the product is measured on the number of features, then your company risks turning into a feature factory.

You could try to educate your stakeholders, and get in an alternative, outcome-based metric. If you could run a full cycle with verification at the end with customer impact, then there is a chance they will slowly turn from output to outcome metrics.

In the meantime, you could use agile for your own prioritization as well. For every sprint, show your stakeholders what items you plan to work on and what needs to wait. Show if your work items are scoped down enough, and your time is used efficiently. Have demos and show the result of the work.

Sounds like a tough battle, also might be a concern for your professional development - not gaining experience with outcome-focused product management.

3 Likes

Good point on the feature factory. Thanks for the link, will go through it.

And appreciate your response :slight_smile:

1 Like

You’re in a dangerous place to be, based on my previous experience.

Engineering leading a product is a sure way to be a full-blown feature-factory, instead of an actual empowered product team.

Leadership tolerating such a fiasco is a big warning sign, too. I’ve been part of some companies where some “key” technical guys were intangibles even by the leadership / -C-level team because they feared they might leave.

This is a bad setup & a bad product organization.

Things to consider:

  • Make a solid business case & propose a new setup in which you are all working together as a product team.
  • Get the leadership buy-in to apply the new setup & processes.
  • If either of the above bullets fails, consider a new opportunity in some other place.

The reason why I want to highlight this: I’ve been there. I hoped it will get better. I went the extra mile.

It rarely gets any better & you’ll eventually be drained of energy and make a move.

1 Like

Now I understand why everyone from the product team is leaving.

Good points and thanks for sharing your experience.

1 Like

I think you could also introduce testing and put some responsibility on the eng to develop and a/b test on product changes.

Benefits here can be:

  • If you don’t have testing infra, you have the capacity to build it
  • It can align your eng team with the business/customer goals and give them the opportunity to take ownership of those goals
  • Free up PM time from creating tests to analyzing test results an focusing on product KPIs
1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.