Agile Insider
Published in

Agile Insider

Awesome Begins When Developers and Users Meet

Photo by Greg Rakozy on Unsplash

There is often a mistaken notion in Product Management organizations that the Product Owner is in place as a buffer between the developers and the users. This could not be more wrong. The real function of the Product Owner, is to facilitate the communication between the developers and the users, ensuring that the developers are getting exposure to the users and that maximum value is being derived from the communication. Marty Cagan, Founder of the Silicon Valley Product Group and author of Inspired: How to Create Tech Products Customers Love, is famous for saying,

“If you just use your engineers to code, you’re only getting about half their value.” — Marty Cagan

This is more true today than ever before. In the ever evolving environment of software development, where Agile methodologies are taking hold in almost every organization, the benefits which you can derive from putting developers in direct communication with users is skyrocketing. You can foster innovation, inspire motivation, develop trust, and increase velocity all by putting developers in front of the users they serve.

The Road to Ruin

There still lingers in our industry an outdated notion that software developers are incapable of dealing with users. Some will say that developers will do or say something to the user which may ruin the relationship. Some Product Owners think that it is their job to protect the developers from upset users, or that by putting users in direct contact with developers it will somehow bypass their workflow and they will be made obsolete. This is of course, not true.

Thinking like this, and the resulting organizational structure can have some pretty serious consequences. Because the developers are distanced from the users by the Product Owner, information takes more time to get to them. The flow of information is primarily one way and there are limited opportunities to clarify misunderstandings. The context of “Why” we are building something can become lost, which limits the potential for alternative solutions that may better meet the users’ needs. And finally, this structure is very demotivating for the developers. They are at the end of a chain of communication and are effectively being told what to do. developers are smart people; you do not get the most out of smart people by telling them what to do.

The Road to Awesome

It is much better to present your developers with context and allow them to participate in the discovery and solutioning processes by communicating directly with the users. This will save time because clarifying questions will be asked on the spot, face to face. The developers will have more trust in the process because they will be able to hear feedback from the source and see that it aligns with the requirements being delivered. All of this will boost morale. Their is nothing more motivating than hearing from an upset user. Being able to see a user in distress, build a solution, and deliver it to that same user, is what converts a Developer from being a mercenary of the process to a missionary for it.

It is all about being able to see the big picture. When a developer is put in front of the user, they are able to learn and discover collaboratively with the user, seeing how their software is being used in the real world. The developer can notice user problems and address them dynamically with working software.

Awesome in Practice

It can be hard to start a practice of developer inclusion and collaboration in the discovery and solutioning processes. It is a balancing act. Ninety percent of the developer’s time should still be focused on building. But with that remaining ten percent, you can utilize some of these practices to work towards better inclusion.

  • Include developers in user meetings regularly. It does not need to be, nor should it be every meeting, but regular face time with users is essential.
  • Ask your users if you can record some of your more critical meetings with them. If your developers cannot be included directly in a meeting, they can at least review the recording afterwards.
  • Start a shadowing program, where your developers are given the opportunity to shadow Account Managers or Customer Service Reps, anyone at the company who is regularly working directly with the users and hearing their needs and concerns.
  • Have the Product Owner take 10 minutes a day to talk to the developers about what they’re working on and what they’ve learned that day. Even this small amount of sharing can see great results.

Final Thoughts

The notion that developers are incapable of working directly with users is outdated. Don’t fall victim to this type of thinking or you will face the consequences. Realize that allowing your developers direct access to your users will yield some pretty amazing results. You can foster innovation, inspire motivation, develop trust, and increase velocity. It’s not hard, just introduce your developers to the users they serve and watch the awesome that follows.

Sources

4 Reasons Software Developers Shouldn’t Talk to Customers

by David Altmayer

“Developers can’t talk to clients.” (or, why the project failed)

by Daniele Beccari

INSPIRED: How to Create Tech Products Customers Love

by Marty Cagan

Why Your Developers Should Support Customers

by Jun Wu

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store