garyfleming / product-engineering

A talk about getting engineers and product people to work better together.

Perfect Patterns For Product Partnerships And Engineering Excellence

Product x Engineering: A Guide To Organizing Patterns

Description/Abstract

Product people make decisions, engineers do the work, right? Wrong!

Increasingly, companies who make software have fallen into anti-patterns around how Product Management and Engineering interact. We see engineers treading Product as business analysts, product managers acting like project managers, and a whole lot of other dysfunction.

There's no single way to manage the collaboration required between Product and Engineering to maximise success, but there are a number of patterns we've seen that have helped ensure good outcomes - as well as those anti-patterns that rarely work.

We'll talk about how you can improve your product and engineering relationships, and use agile techniques to help bridge the gaps.

75-80 Word Summary

Increasingly, companies who make software have fallen into anti-patterns around how Product Management and Engineering interact. We see engineers treading Product as business analysts, product managers acting like project managers, and a whole lot of other dysfunction.

There's no single way to manage the collaboration required between Product and Engineering to maximise success, but there are a number of patterns we've seen that have helped ensure good outcomes - as well as those anti-patterns that rarely work.

Actionable Takeaways

After this session:

• You'll understand how to spot some of the anti-patterns around product and engineering relationships,
• You'll know how to design your organisation to achieve better results,
• You'll know when to take different collaborative stances depending on the outcomes required,
• You'll feel more confident in shifting your partnerships towards more productive patterns to maximise your chances of success.

Session outline (reviewers only)

I'm going to start by covering a number of the anti-patterns I've seen where product and engineering aren't collaborating in healthy ways; where product are telling engineering what to do, where engineering aren't listening to product etc and the natural consequences of doing that.

I'm then going to move onto the idea that there are no easy answers and that what we should do is dispositional: it depends highly on the kind of products being created. Is it for internal customers, or external? Is it in a new market? Is it disrupting an existing field? Each of these change the focus of the collaborative relationship.

Having explained the dispositionality, I'll then move onto giving the attendees the patterns that can help them in each situation, as well as agile tools that will help them refocus their product/engineering relationships to be as productive as possible.

I'll end by reminding them that these are just patterns, but that they're helpful - and necessarily incomplete. I'll encourage them to use them for as long as they're helping, but to not hold them to close. Every pattern has limits, and we should be constantly asking when we're done with our current techniques.

History

TBD