This is a guest post written by Mac McConnell, VP of Marketing at Gliffy, creators of visual planning apps on the Atlassian Marketplace – Gliffy Project and Gliffy Diagram.
“That is not what the ticket said to build. How could that paragraph of text be misunderstood? It is so clear. ” -Any Product Manager, Anywhere
Any product manager will tell you miscommunications are the bane of their existence. While developing a brand new product from scratch is one of the most exhilarating things a software team can do – it comes with a healthy set of lows (mostly due to communication mishaps). Gliffy just experienced these peaks and valleys while building a software tool to help teams add a visual element to Jira. We learned a thing or two along the way that we thought could help others and wanted to share them with the Atlassian community.
One glance at the doom and gloom stats — 70% of software projects fail, 75% of respondents lack confidence in project success, the average cost and time overrun is 27%, but 1 in 6 projects have a cost overrun of 200% — and it’s easy to feel like giving up. But then again, if it were easy, succeeding wouldn’t feel so darn good.
Here is what we’ve learned.
What do developers want?
If you got a group of software, product, and UX developers in a room together (we did) and asked what they wanted in an ideal software development process, their answers would not surprise you. Each group needed more details on the project and the process. When we completed our debrief, we discovered three themes, all starting with the letter C:
Confidence, that we’re working on the right thing, in the right way, at the right time, and our efforts will get shipped instead of scrapped.
Clarity on how decisions are made, what’s happening, what’s coming next, and on what other teams are working on and why.
Connection to the big picture of the project. Teams need to understand how the work comes together, which dependencies we’ve overlooked, and what kind of progress we’re making as a team.
Sounds simple enough, right? There is nothing new in these discoveries. They have plagued cross-department projects my entire career
Is there a better way to build software?
The three Cs above are not a crazy pipe dream. They don’t require magic, and yet somehow they are frustratingly hard to achieve (as we ourselves found out).
Atlassian has a whole slew of awesome playbooks that help teams recognize and overcome common problems, however, these problems are common because they are hard to fix. As our team worked to build our new product, Gliffy Project, we too asked ourselves the cause of the everyday issues tanking our momentum and bleeding our morale. We found these culprits.
Poor Communication
Every new product starts with a vision. But even people who house ideas in their skulls have a hard time communicating them perfectly. And it only gets more jumbled from there.
Product people communicate the vision to stakeholders, UX designers, and engineers. Those people have to then communicate down the ranks to the people actually doing the build. By the time the game of telephone is over, what was built is different from what was imagined. Everyone is frustrated. Work is wasted. The weakness here is the words, whether in text or audio. Visuals (images, videos, diagrams, whiteboards) are the key to accurate product development.
We build visual communication tools because we know pictures are less ambiguous than words. That’s why we decided to build a tool centered around visuals. Gliffy Project connects with Jira and allows users to map Jira issues to a visual plan such as a whiteboard drawing, a wireframe, UML diagram, product roadmap, or a combination of all of the above.
Users can then create hotspots and either pull in existing tickets or create new ones directly from the visual. Having everyone’s Jira tickets connected to a visual plan representing the project, allows different teams to see who is working on what, and gives a quick overview of dependencies, allowing anyone to quickly gage project status.
Having this agreed-upon visual as a reference point greatly cuts down our team’s communication breakdowns, both at the beginning of the product build and throughout the process as the product (and visual) evolved.
Information Fragmentation
We all get dozens of documents from different places throughout our careers. Keeping track of them is difficult and once you find them figuring out how the information relates to what you’re currently working on can be even more tricky.
One of our main goals in building this new app for Jira was to have both the big picture view and the smaller puzzle pieces all living in one place. We wanted anyone to be able to quickly see overall progress, know who’s working on what, and understand where the work fit into the greater whole. Because our new tool is connected to Jira, and every other type of document was attached, we spent less time searching for things or having to make sense of them. It took a few months to get into the habit of sending and storing things in one place, but in the end, it was well worth it.
Faulty Memory
Everyone forgets things. Having a visual plan ends up being a big help in remembering things accurately since 65% of humans are visual learners. Now you’re no longer just relying on words, but on pictures too. In addition to helping you remember better, it’s a great way to record things to jog your memory later.
We found using Gliffy Project, we had more specific and shorter conversations. Rather than relying on our memories, we pulled out the visual plan and referred to things directly in the diagram. Instead of wondering when that drop-down menu would be ready, anyone could pull up the wireframe and check to see the ticket assignee and status.
Side note: We saved a TON of time writing tickets. Instead of having to write lengthy paragraphs describing what we were referring to, we would just add a hotspot and say “fix this thing here.”
The feedback from engineers was that the image, whether a diagram, architecture, UML, screenshot, or other visual, was more helpful in determining their next course of action or piece of work. The two images below are of the exact same Jira epic. Which one is easier to understand?
Option 1:
Or options 2:
So, Is There a Better Way?
A single tool on its own has no chance of solving complex issues and giving teams the clarity, confidence, and connection they need to build products in a better way. During the process of building a product to help others build products was that pictures (diagrams, screenshots, photos of a whiteboard etc.) were the key to overcoming the three Cs mentioned earlier.
Having to come up with an agreed-upon visual earlier in the build process made us work together more effectively. It forced us:
- To ask better answer questions about the product earlier, because we couldn’t hide behind the vagueness of words.
- To get more specific when asking and answering questions because the broad strokes were documented in the visual.
- To get into the habit of updating the visual and noting the changes as soon as they were agreed upon because people were expecting the visual plan to be the source of truth.
Were we able to improve our product-building process? Absolutely.
Was it solely thanks to the new tool, Gliffy Project? Absolutely not.
There is a better way to build software, but it has to start with a better way of working together as a team. So whether you check out Gliffy Project or find another way of getting your team aligned, do it soon. Those scary stats aren’t going anywhere, but there are too many amazing, game-changing new products to be built to ever give up trying.