How to get developers excited about product work

  • 26 August 2022
  • 5 replies

Userlevel 3
Badge +2

Hello lovely product community!

I am currently at a point in some medium term product planning that provides an opportunity for developers to get involved in (voicing tech work that needs to be done alongside feature work, aiding in the sequencing and estimation and prioritisation of these pieces of work).

Our developers have been asking to be more involved in the planning process and we as a product team are taking every possible opportunity to do this in an organised manner.

However, this is resulting in developers not voicing their opinions or gripes in an open (safe!) forum, and a huge lack of engagement.

I would love to know what techniques folks here use to get development teams more engaged in the planning phases of the roadmap and sequencing of work.

Happy to provide more context (but don’t want to write a blog post 😂)

This topic is closed for comments.

5 replies

Userlevel 4
Badge +2

Following this to see what better ideas there might be.

I like the idea of anonymous polling, and then force-ranking the problems/technical debt items to a shortened list. Then in a short developer-only meeting just ask people to take ownership and champion a topic and just try to get them to make any kind of artifact that gets the point across to other leadership teams

Could be

  1. A brief research summary from online articles,
  2. a Proof-of-concept piece of code, program, script, 
  3. Mock-up

Use the artifacts to guide the discussion with a larger group thus making the artifact, and not necessarily even the champion or owner of that artifact, the focus of discussion.


That said, if you are asking to do this even during a fully loaded sprint, I wouldn’t expect much.

Good luck!

Userlevel 4
Badge +2

Oh - that said - I wouldn’t expect “excitement” 😁

Userlevel 6
Badge +12

I usually have a pretty close-knit working relationship with developers in any company I’ve been at (since I was a previous engineer in another life). Something I’ve really taken a liking to, for numerous reasons, is to schedule a sprint or two to tackle tech debt - tend to do a “round-robin rotation” where one dev gets to either take up a hobby project that will fix tech debt or a proof of concept based on ideas that have circled around the company. 

@Mmcclain really had some pretty solid ideas, frankly. Developers want ownership and autonomy when it comes down to it. Hackathons are also pretty fun to get involved in (pair up product and engineers to conceptualize and implement a PoC of something unique - you never know if you come out of it with a great feature/product offering!). Then you can have that PM and Engineer be the leads for it if there’s time and aligns with the product/market strategy if they win the hackathon. 


Overall, I agree with the “not expecting excitement.” Not all developers are going to be on the pulse of the product, with as much investment as product managers are going to have. Some are just “doing their job/putting in time” and have other passion projects outside of whatever deliverables we’re throwing at them. But the more creative freedom you give developers/engineers to implement a feature/function, the healthier that relationship will be. 

We follow an ad hoc version of Basecamp’s “Shape-Up Methodology” where we do have a session between product management and engineering/development to cover potential rabbit holes, understand/validate technical direction, receive feedback from stakeholders from the initial “ideation/concept,” and get into the nitty gritty of the “Why” (Product Management) and the “How” (Engineering/Dev). It helps PMs learn more from the technical side (if it’s not their strengths) and helps the engineers contribute through exercising solution building skills (and knowing the value of what they’re building to the product). 

Userlevel 5
Badge +2

Just to reinforce some previous points and add some personal experience …

Not everyone wants to play

As others have said, not every engineer wants to collaborate. In fact, a good portion like their job because they can hole up in their private space and just create cool code. These types often have some great insights, but they expect their lead / manager to bubble that up to the business for them.

Don’t fence in contributors

Those who do want to be part of the collaboration game shouldn’t be scoped down to “tech debt” issues. If you want to bring in a larger group, ask for their help in addressing big picture goals. What opportunities and challenges are you trying to solve? Ask the engineers to participate in addressing those needs with a broader group. Good engineers who regularly keep up on tech developments will bring a unique perspective on what’s possible. And they use lots of other products that give them a unique potential on what tech should do.

I also encourage the engineering team to use our insight submission process to get their ideas in the queue along with everyone else’s (including customers). When anyone has something to share, it should go through the same process.

Keep the trio together

Your most fruitful engineering collaboration is still going to come from the senior engineering leader as part of the PM / Designer / Engineer trio. That’s the person who should have the greatest interest and highest level of engagement with shaping the backlog. That role is tasked with representing the rest of the technical team. 

If you aren’t there yet, you’ll probably end up with multiple trios as your product matures. I like bringing all the core teams together at least quarterly (I prefer monthly) to make sure insights are spreading as much as possible.

Userlevel 5
Badge +2

Regardless of jargon or frameworks and just to put it simply, the earlier important stakeholders like Engineers are involved the earlier collaboration and real problem solving starts. I think that should always be the aim for any product team.