You spend lots of time writing tickets. Like, hours and hours worth of time after you already spent most of your day in meetings.
But there’s a problem when engineering delivers the goods. They’re quite a bit different from what you envisioned.
“Did the engineering team even read the ticket?!?!! ” you ask. “Are they even listening to me?!?!?!”
You may find things come back with extra scope, behaviors you wrote out to be different, or perhaps it doesn’t look anything like the wireframes. No matter what it is that they delivered, it’s definitely not like what you intended.
If this has happened before, perhaps you’ve tried checking in with your engineering team over more frequent standups. You thought that would work because things seemed to be going well mid-sprint, but when it was time to deliver the stories, there was still extra scope or missed items. You’re stumped.
You know the engineering team has the product’s best interests at heart but their tendency to do more than they have to is blowing up your roadmap and driving you up a wall.
So, what to do? How do you get them to stop delivering more than they need to?
13 things to try to get your engineers to listen to you:
- Write specifications
- Give clear and detailed feedback
- Ask the team what they need
- Include engineers early and often
- Get them closer to the customer
- Include your product designer in more meetings
- Increase the frequency of check-ins
- Conduct walkthroughs of new features
- Drill into the business need
- Include wireframes when possible
- Create engineering routines
- Write smaller (or larger) stories
- Reject stories that don’t conform to requests
Let’s dig in to each of these!
The rest of this article assumes that you already write half decent feature specifications.
If you have not done this in the past, do not pass go and do not collect $200 until you start giving your team some specs to work from. Engineers are neither designers nor mind readers. Give them a base from which to work.
Already tried specs? Onward!
Give clear and detailed feedback
Everyone wants constructive feedback, but many of us aren’t very good at giving it, especially when it is not totally positive.
However, in this
The engineering team could be clueless that the scope they’re adding is unwanted. You need to make it very obvious the impact their behavior is having.
And there’s no need to sugarcoat feedback. Try starting the conversation with something like:
The last few features you’ve delivered have come back with
See where it goes from there. Maybe it’s just a simple misunderstanding, but the conversation has to start somewhere!
Ask the team what they need
We’re often so tied up in our busy day-to-day we can forget to slow down and think about higher-level stuff. Ask your engineering team…
- How they like to work?
- What do they need before getting started on a feature?
- What level of participation do they prefer?
- How often they need feedback?
- What is their ideal meeting schedule?
- If you had an ideal relationship, what would it look like?
Similar to the suggestion above, m
Include engineers early and often
Try involving the engineering team early on in the process. This way you can nip any problems in the bud and gain their buy-in before any code is even touched.
You’ll increase trust between teams while giving them room to add their own creative ideas.
It can also help unveil problems sooner. For example, what if they’re not delivering what you’re asking because what you’re asking for isn’t technically feasible? Much better to pivot a few weeks out than a few days before the beginning of a
Get them closer to the customer
As a PM, you interact with your customers a lot. So much so that you may unintentionally assume that everyone else knows what your customers are like.
And you know what assuming does…
Don’t divorce your developers from the actual person making the request.
When writing up your requirements, add some real data from customers. Try adding language from the original feature request and supporting requests or direct quotes from customers who need to get the job done that this feature needs to do.
A little more “why” behind the work can help people feel ownership over what it is they’re about to do and know that their work will make an impact on real people.
Include your product designer in more meetings
Designers are amazing. They seem to always have a good, logical explanation for why they did things the way they did. They know why they chose that color, why this needs to pop up in a modal and that in a tooltip, and why this button needs to be on the left-hand side of the application rather than the right.
Including your designer in meetings with engineers and encouraging them
Engineers are typically very logical. If there’s a logical reason a decision was made, they’ll be more likely to understand why a feature is to be built a certain way and be OK with going in that direction.
Increase the frequency of check-ins
Yes, it may be sacrilege to suggest more meetings, but if you’ve tried the suggestions above, adding more time into your week to talk about how things are progressing may be needed.
If a weekly stand-up is not cutting it, try adding mid-week check-ins. If those aren’t working, maybe it’s time for a daily standup.
Another option is to add a meeting where you conduct walkthroughs of new features…
Conduct walkthroughs of new features
Sometimes repetition can be the solution to getting through to people.
If your engineers are on the lazy side and don’t feel like reading the specs (hey, a lot of us have a lazy bone — no judgement here), a session dedicated to reviewing the specs will ensure that you at least know that they’ve heard the specs.
After the walkthrough, leave some time for Q&A to make sure everyone is on the same page.
Drill into the business need
Unfortunately, in many organizations engineers can be treated like worker bees. They have one purpose and that is to build what they’re told to.
However, engineers can have some really, really fantastic and creative solutions to fix things in ways that no one else may have thought of.
For those ideas to be able to come to light, there needs to be some additional context around what they’re building, what it’s trying to achieve, and why that’s important to the business.
Let them in on what’s happening on a greater scale in the organization.
Maybe if they realize how fundamental this will be to the future of the organization, they’ll be better able to plan for scaling in the future or develop an architecture that allows for more extensibility.
And when you let them know what’s going on from a bigger picture perspective, demonstrate how this things they’re working on right now can help the business make more money, save more money, bring in new customers, make things more efficient, and improve things so that the company and their careers will be better in the future.
Include wireframes when possible
Reading a document is not always enough to get the design across.
A requirement can be interpreted in multiple ways — especially when what it will look like on the front end is open for interpretation.
That’s why you should include wireframes and ideally, mockups whenever possible.
This’ll help give your developers a better picture (quite literally) of what it is that they’re building.
Create engineering routines
As product managers, engineering routines may not be our area of expertise. However, the existence of engineering routes (or probably more commonly, non-existence of engineering routines) could be where many of your problems are stemming from.
Work with the engineering lead to see if there are any best practices, tools, processes, or routines that could be put in place. Are any best practices other organizations are using that you should try?
Another idea — maybe it’s time for a QA engineer who will read specs and then review code and suggest changes based on the specs.
Write smaller (or larger) stories
If your user stories are long and complex, try shortening them up. Broad specs may be open for a lot of interpretation
If they’re super short, perhaps your engineering team may feel like you’re missing things and are compensating by adding their own ideas to bridge the gap.
If you’re writing a lot before coding begins, try writing less.
If you’re not writing a lot, try giving more detail.
Reject stories that don’t conform to requests
This may sound crazy, especially when engineering time is so valuable, but you may need to reject stories if they don’t conform to what you ask for.
Be sure to include a reason why if you do this. After a few rejected stories, the team will get understand you’re serious when you say you don’t want scope creep.
Have you dealt with a similar situation? How were you able to
Also, if you liked this article, sign up for our email list below to be the first to hear about new posts like this one in the future.