Every engineer in the team must understand the why.
Can everyone confidently answer the question:
What problem are we trying to solve with this user story?
Understanding the why is essential to the success of a project and the team's performance. A group of people who don't understand users or their problems cannot build a high-quality product.
Sure, you have well-specified epics and user stories. Still, during delivery, the team will have to make dozens of decisions that are not detailed in the ticket. There are two options. Either delivery grinds to a halt, with engineers constantly asking the Designer/PM. Or they make the decisions themselves. To make the right decisions, everyone needs to understand users, the problem, and the solution.
Everyone needs to understand the why.
Many organizations struggle with this. Engineers focus on closing the next ticket in time for sprint review, and PMs are frustrated when features suffer delays because they were subpar.
As an engineering leader, the bad news is that you are responsible for the situation. The good news is that you can turn the ship around.
🐶 Dog-food the product
What easier way to understand the product better than to use it every day?
Well... None.
Admittedly, some organizations have it easier than others. Engineers at Honeycomb use their own product to observe Honeycomb. If your product doesn't lend itself naturally to be used by engineers, there are still things you can do.
At Plot, we build a tool to help you create learning experiences like the world's best learning designer. We're running a challenge where we will all design a course using our tool. Not only will everyone familiarize themselves with the experience of using the product, but we will also collect loads of valuable feedback.
🧪 Engineers join UX interviews
Engineers who talk to users are bound to get to know them better. They can read written feedback, but there's nothing like talking to them face to face.
You can suggest they join your team's Designer on the next series of user interviews that validate the solution they will work on next. Start with Engineers shadowing, so they become comfortable. Perhaps you'll get a few individuals interested in conducting interviews themselves!
👌 The team refines together
Many teams do not refine user stories together. I am shocked at the number of instances when just the Engineering Manager, Product Manager, and Designer discuss the backlog. The Engineering Manager breaks down stories into tasks and assigns them to individuals in the team.
I cannot state how extremely damaging that is.
Firstly, Engineers only receive a piece of the puzzle, making it impossible to see the bigger picture. Secondly, they never get the chance to break stories into smaller chunks, missing out on developing a crucial skill.
Refining together is a great way to share knowledge about the system, where the pitfalls and the opportunities are.
👨🎨 Design sprints & ideation sessions
Having Engineers and other roles participate in design sprints or ideation sessions before a solution is presented to them is fantastic. Instead of thinking about the solution at hand, everyone is now thinking about the actual problem or frictions users face.
There are a couple of bonuses. One is that Engineers feel more ownership over what they build. The other one is that Engineers might identify great solutions a Designer or PM thought to be technically infeasible. Yet another classic example of why diverse teams build better products.
💬 Everyone does support!
It's typical of early-stage startups for everyone to help out with the help desk rotation. The Product Support team may not even exist yet! However, this normally stops the second the Support team assembles.
A day where the Product Development team helps with Product Support will be a true eye-opener. There is nothing like seeing raw user frustration first-hand. It puts the roadmap into perspective.
👩💻 Make Product part of the JD and interview process
If your interview process focuses exclusively on technical knowledge, you may attract Engineers who are not interested in understanding users.
Think about the questions and conversations you may have to understand better how candidates think about user problems and solutions.
⏳ Make time for it
Of course, you cannot just add new responsibilities to your team and expect nothing else to change. It's an investment. The team may move slightly more slowly initially to increase quality and velocity later.
🙌 Do you have other practices or techniques? Please do let me know!