Engineers Don’t Build for Product Managers
Problem
Engineers lack visibility into the customer problems and product's rationale around prioritizing one problem over another. These blind hand-offs lead to sub-optimal solutions with little interest or deep understanding of why it's important.
Symptoms:
general apathy
lack of excitement around starting a new project
low sense of ownership
phrases like “It’s whatever you decide” or “What I think does not matter ”
Proposed Solution
Create a feedback loop between the real-life user and the engineering team facilitated by the product manager.
Signs of Recovery:
follow up questions during the sprint planning
expressing counterpoints
bringing up examples from the field
Outcome
The convergence of architecture and user experience in the end product.
Having worked with 3 very different engineering teams over the years, as a product manager, I always felt responsible for keeping these teams happy and highly motivated. In larger organizations, this task normally falls on a scrum master, but if you are at a start-up you are most likely taking it on among other things.
There are a lot of courses on collaboration and team productivity that can come in handy. And some of the technics really work. One of my favorite practical concepts has always been Maslow’s Hierarchy of Needs. Encouraging my teammate’s self-actualization allowed me to build strong, respectful relationships. People unlock hidden creativity within when there is no judgment and someone believes in their high potential.
However, I soon realized that being a personal cheerleader should be used sparingly and after all will not be enough.
The apathy creeps in at any job. Coding all day long is fun but also has its boundaries.
Image inspired by one of my personal friends and and awesome back-end engineer after she’s had one too many cafecitos.
So when I saw some alarming symptoms, I started researching this matter and looking for advice. The most common problem that kept coming up was the over-the-wall syndrome. When the teams are siloed and the development train is not a bullet one, but a coal-fueled on with many disconnected cars in the middle.
My brain was boiling: “That cannot be it! We are agile AF!” Collaboration is through the roof. The product team and the business owner are never throwing anything over the proverbial wall. We share ideas, we ask for opinions, we are including engineers in brainstorming sessions. So why from time to time the spark is not there? Where is that desire to show off the fruits of their labor on Tuesday demos?
Around that time, our QA manager expressed interest in sitting in on some demos and user interview calls. After each call we would compare notes, discuss, and he would bring up examples of the user stories he heard during the weekly bug meetings. Curiously enough, whenever those conversations happened, the engineers would get lit up and start brainstorming solutions. I was surprised. It’s not like we had not had a voice of the customer channel overflowing with user feedback by then. Anyone could see randomly selected comments from real users. But this time it was different. The stories were about the areas we either recently improved or debated about.
After trying a few times to substitute the praises with what the real customers might say, I noticed a much stronger positive response. When testing or watching a demo, saying something like “John from XYZ, Inc will really love this.” or “Martha from our largest account in Maryland has been asking for this for years.” was creating new levels of engagement. The engineers were putting great value in the words of the user, after all, they were the ones anticipating to benefit from the new feature.
That ignited an unplanned feedback loop. The product and success teams started to organically involve the development department in the conversations, even if not directly. Whenever they had a valid idea on improving something, they started to ask us to validate it not just internally, but with the customer they remembered from one of the calls or notes.
I still recall one extraordinary moment during a design session, when an engineer disagreed with shaving off a business rule saying: “John from XYZ was specifically against having that functionality released without a user permission control”. By insisting on adding this spec she only increased scope by half-day + testing, but potentially helped to retain a devoted customer.
After releasing a feature, we started sharing more of the customer reactions, good or bad. Until then, the product and business team would be the ones to keep that feedback, analyze, and prioritize it, to “avoid distracting the devs”. Now, we could post it in the feedback channel and have stress-free threads that often lead to unexpectedly elegant solutions.
Risks
There is a very fine line between making this process beneficial and turning it into a chore. There is also a risk of derailing the roadmap by creating a hodgepodge of ideas and opinions. It did take a little bit of back and forth to figure out how to avoid these pitfalls. So when implemented this process should never be left to chance.
Looking back, I can say that we used to have a wall between engineering and product. It might not have been a solid brick wall, but rather a glass one, which might have made it harder to spot.
Conclusion
Adding a customer feedback loop that feels personable and non-intimidating to the engineers helps break the wall that you might not even know exists. For different teams, it means different levels of engagement. For different business stages, it calls for different processes. For anyone, it is at the very least worth trying!