I joined Gliffy as the VP of Marketing 9 months ago and was immersed in new sights and sounds, just like the first time you see NYC from the top of the empire state building. The most amazing of these new sights was the initial development of Gliffy Project. During my interviews and meetings, Gliffy Project was an abstract discussion. However, during my first day on the job at Atlassian Summit that abstract discussion quickly became a tangible product. Here I was demoing a prototype and things became real, feedback from attendees was positive, and a product launch was in our future.
That is where we are today, launching Gliffy Project. As of this morning, Atlassian approved our app, and it is now available for immediate trial to Jira Cloud users through the Atlassian Marketplace. Of course, we have been using it for several months now and I want to share a few of the things I appreciated about it while planning this product launch.
I have always used diagrams and other visual formats to design and express business plans. My first exposure to Gliffy back in 2010 was through the Google plug-in when I was consulting for Sugar CRM on a update to their sales lead management process. I needed to map a complex collection of data and human connection points. This diagram was critical for the technical team to coordinate the systems and their communication, but it was never linked to their work. It was an artifact of the planning process and a nice piece of reference material. Today, Gliffy Project would have put that diagram to work by mapping Jira tickets to the plan for faster and more organized product development process.
Here are my observations running an important project using Gliffy Project. In this case, it was a product launch, but what we learned could apply to any project:
- Meetings: Starting with a planning visual gave the entire team an anchor point allowing our conversations to be focused on the outcome rather than the order of operations. Just like that, spending half our meeting ordering and assigning tickets was gone. Instead, each individual or sub-team could do that on their own as they knew visually which portion of the project they owned. Moreover, by using the visual as a reference point with the work tickets attached, the plan was imprinted on our memories. By launch day, today, any of us can share a verbal representation of our product launch plan with anyone at Gliffy or beyond.
- Communication: Listening in on the side conversations around the marketing desks was fascinating. There was more discussion of content, graphics, order of messages, audience then I had heard in the previous few months. These are the conversations that contribute to the success of the launch as opposed to the conversations where folks are trying to sort out confusion and organization. The visual plan, which was not a sexy graphic (as you can see), became the plan and the work flowed off of it.
- Forgetting Stuff: “Who has done XXX?” The dreaded question. We didn’t have it except once. I have reflected why this was. Gliffy marketers and supporting cast have put together 117 tickets worth of work (have tickets become a unit of measurement?), yet we did a great job documenting the work that needed to be done. My analysis is that because we created our tickets directly on our visual plan (think direct translation), we were more complete in building out our Epics and associated issues. If part of the plan was missing Jira tickets, it was obvious we had a gap that would come back to haunt us in the future.
- Status: I have always struggled with understanding status on large projects using Jira. Small projects are easy – just scan the number of done tickets. I figure that my brain hits a dissonance point at about 20 tickets. Remember, that we were dealing with 117 tickets split across 3 epics. This was way beyond my mental capacity to calculate where we were and whether we were ahead or behind. Being able to see the number of tickets completed compared to total on our visual plan gave me feeling of safety and allowed me to more accurately do my mental risk calculations. As the manager, it gave me context to guide our weekly and then daily meetings. I knew where to focus and how to give direction.
This is a just a bit of what I observed during an intense three months in Gliffy Project. Our beta program customers have explained to us other interesting behavior change with Gliffy Project. For example, one product manager guessed their time writing Jira tickets had decreased by half because she had to write less in each ticket. The user flow visual explained the concept she was trying to convey to the engineers. Instead of repeating herself in tickets, she could simply refer the team to the diagram. The same was true for a complex screen mock-up that was being worked on by different engineers. By grouping tickets by engineer and area of build onto the mock-up, she had to write less in each ticket because the engineer could easily look at Gliffy Project to see which colleagues were working on an affiliated part of the screen. The problem with wordy tickets is that you are assuming the person working on them takes time to thoroughly read them. There was also some tangential evidence that the build was more accurate and to spec using Gliffy Project. The assumption is that the engineers better conceptualized what needed to be built from the visuals instead of getting lost in or ignoring the often lengthy details in the tickets.