Stop complaining that Developers don’t build what you want, Communicate Better!

Tami Reiss is the founder of The Product Leader Coach where she works with product leaders and teams to realize their potential by focusing on their strengths.

Many product managers get frustrated when the dev team doesn’t build what they thought they requested. Rather than blaming the engineers, look at how you are communicating and make adjustments.

Properly deciding what level of detail is right for your audience and what to show them can ensure successful impact of your message.

Below are options for how to share your vision for a feature and suggestions for when to utilize them. They are in a chronological order that should become a cycle.

• Sketches: A rough hand drawing of what you’re trying to accomplish is often all that’s needed to spark a conversation and clarify confusing topics. Always start with a sketch when designing new screens or flows.
• Wireframes: More detailed than a sketch, but still not a full fledged view of what will be built, a wireframe is a great discussion tool when getting high level effort estimations from developers and for receiving feedback from potential users to ensure you’re headed in the right direction with your design.
• Screenshots: After validating the basic wireframes with users, creating a pixel perfect representation of what the designer thinks is correct will allow for more accurate estimation and more detailed conversation with developers and customers.
• Prototypes: Thanks to Invision, generating a clickable tangible mock version of your site or application is super easy. Allowing prospects and team members to play around with one of these will surface where things are confusing and when the functionality is well understood.
• User Stories: Writeup of the goals of the feature and acceptance criteria so that the design and development team have a clear understanding of what’s included and what isn’t. Attaching a screenshot or prototype for the team to review will add color to the written description. The set of upcoming features’ user stories should be reviewed in regularly scheduled sprint/iteration planning meetings.
• Product Briefs: Sometimes grouping the features together and describing the overall value they deliver is helpful. This can be written up as an epic or one page document to share with internal stakeholders. Marketing and sales teams love these documents because it helps them anticipate what they’ll be able to promote in the future. Customer support teams appreciate them accompanied with prototypes so that they can familiarize themselves with upcoming features.
• Roadmaps: These overviews for the long term strategy of your product are excellent to show investors, exec teams, and occasionally employees, but generally let your internal team focus on the immediate tasks at hand. Make them more specific in for the upcoming months and hazy in the future, everyone knows you aren’t going to stick to it perfectly, so why pretend?

Each organization will utilize the above in slightly different fashions, and sometimes whole steps are skipped. Do what works for you and your team, but when process starts breaking down, return here to see what you might be missing.

Hi! I’m Tami, the founder of The Product Leader Coach where I work with product leaders and teams to realize their potential by focusing on their strengths.

If you enjoyed this post, I am available for product leadership coaching or team training. Learn more about my services and upcoming children’s book.