How we come up with new app ideas - 3 tested prompts for Jira Cloud app developers

[#1]

The article was originally written by Magdalena Korgul - Senior Content Specialist in Deviniti

There are over 4000 apps and integrations on the Atlassian Marketplace. You may think that all the best ideas are already taken, but somehow the platform is constantly being filled with new applications that come up to gain multitudes of users. But how to find this one in a million idea that will turn into a successful app? We've reached our development teams and asked them what inspires them and how do they come up with new concepts - sometimes for brand new apps, sometimes for new features. Let's find out how Jira app development works behind the scenes.

Come up with ideas during hackathons

We love to create new apps that help our clients, but sometimes we also like to challenge ourselves - that's why we organize our internal hackathons and also try our hand in external events.

This year, our Atlassian Apps team organized Pimp your Cloud, a hackathon open for ideas from all Deviniti employees. It differs from our previous hackathons, and other external hackathons that we know - this time, organizers didn't require a product, but an idea. It allowed non-technical employees to let their imagination run wild and think of a solution they would love to use. Here's what Klaudia Schon, Pimp your Cloud organizer, says about the thought behind this event:

This year, Pimp your Cloud gathered 18 participants from different departments (Atlassian Apps, Atlassian Services, Applications Development, and Marketing) with 15 projects. Teams and individual employees submitted ideas including: simplifying the process of searching for a given task in Jira using bookmarks, mapping issues in Jira, and gathering all the necessary information concerning a project in one place in Jira.

The jury found 4 concepts especially interesting:

• Jigma - Jira and Confluence add-on allowing for browsing, adding, and editing comments in Figma from the Jira and Confluence level,
• My Mentions - an app improving planning and effective work management thanks to collecting all the Jira mentions in one module,
• Public Roadmap - Jira add-on enabling for sharing a public roadmap with the customers, and therefore, helping them stay up-to-date with our products development stages,
• Smart Profiles - this app can be a real game-changer because of the usage of SLAs and allowing for connecting a task to the assignee based just on an employee's competencies.

All of the hackathon's participants received feedback from the jury, including the pros and cons of their ideas and prompts that can help to improve the idea and possibly put it on the market.

We get inspiration and gather knowledge at Codegeist - an Atlassian Cloud Hackathon

Owners of one app that especially appealed to the jury - My Mentions for Jira - decided to challenge themselves, improve the application, and join the Codegeist hackathon. But how did they come up with the app idea in the first place?

The primary app clients are people working on many projects, such as managers, project managers, support specialists, and cross-project employees. The team wanted to improve their work and give them a simple tool that would help them reduce the time necessary for scrolling through Jira in search of tasks that relate to them.

How does My Mentions app work? The main panel gathers all the mentions that concern a given person. Here, in the Glance view, we can see all the issues and projects where someone has mentioned us. What's important is that we don't necessarily have to leave the panel and go to the given Jira issue, but are allowed to answer the mention right in the My Mentions panel. That way, we don't have to distract but answer all the mentions sequentially. However, if we would like to be transferred to a given issue in Jira, the application also allows it. Also, Issue Glance comes with several filters that help in finding a specific mention: Read, Unread, Author, Text, JQL.

There's also a bulk comment option, allowing us to write one comment in several issues at once. Mentioning other users, as well as writing a custom comment is also possible. Navigation in the app is simplified thanks to the JQL filtering - we can easily filter the mentions from the oldest to the newest and conversely, as well as mark them as read/unread. This way, we'll keep an eye on all the Jira notifications we need, without having to look for them in the depths of Jira.

The Bulk Comment option

Rafał Janiczak, the app's product owner, shared his thoughts on Forge, a new app development platform for Jira Cloud:

We don't have to start from scratch

Assignment Rules for Jira

The second concept is brilliant in its simplicity. And we're sure that the majority of development teams do the same. The idea is to improve the tools that we work with because there's nothing better than making your team's life easier. Our Atlassian Apps teams have an advantage - they know how to write addons for the Atlassian software - the same they use in their everyday tasks.

The Assignment Rules app owner sheds some light on the process:

"The idea for the app came when we wanted to try out the Forge platform - the goal was to do something useful and learn the new Atlassian platform at the same time. Thanks to Forge, the first version was done very quickly, and the Aha! moment appeared in the team. It suddenly became obvious that we had always needed it." - Michał Sztuka, Assignment Rules for Jira Product Owner

There are 6 developers in our Jira Service Management team. They look after a couple of applications (each of them has a separate project in Jira Cloud):

• Extension for Jira Service Management (cloud + server / data center)

• Actions for Jira Service Management (server / data center)

• Translation for Jira Service Management (server / data center)

• My Requests Extension for Jira Service Management (cloud + server / data center)

• Theme Extension for Jira Service Management (server / data center).

Issues:

The tickets that come down to the support team often need to be analyzed by the developer. What's important is that we don't use the division of work: 1 app = 1 developer. In practice, this means that every member of the team has great knowledge about each of the applications and performs tasks concerning different projects. On the one hand, it's a great advantage - when each developer is equally responsible for not only one app, there is always a possibility to cover for someone (in the case of vacations, sick leave, or any unforeseen situations). On the other hand - this kind of division of labor carries a risk of overwhelming a team leader with all the problems.

It's also a waste of the leader's time to manually give out the assignments to each team member. What's more, the tasks should be diverse, and one application's support shouldn't be handled by only one person. Manual tasks distribution requires private communication with each team member, which is not only time-consuming but sometimes encourages to bringing up not only job-related but also private topics.

Another issue is the number of tickets that are unevenly distributed between the apps, which is caused by an uneven number of installations, sold licenses, number of features, and apps time spent on Atlassian Marketplace. When one developer was responsible for handling a specific product, some of the team members were snowed under work, and others had too much free time.

Problems we faced:

• How to divide support tickets as fairly as it's possible?
• How to organize the team's work to make it automatic?
• How to improve the collaboration between support specialists and developers?
• How to keep the conversations public and give each team member an equal amount of information about problems?

helped us to bump into a good app idea.

Our solution:

The process of coming up with the best idea was - of course - preceded by a couple of steps.

1. Firstly, assigning the tasks was a manual process. Incoming ticket → Support team → Team leader - Developer. Advantage? The issue is assigned directly to the person familiar with a given topic. Disadvantage? A support specialist has to know which developer knows a given app best, and a team leader is always involved in the division of work. What's more, when the assigned developer is absent, it's difficult to track the task's progress, and the task's analysis isn't included in the sprint.

Our second approach shoved us towards tasks automation but nevertheless required a support specialist's involvement.

2. In this step, when a new ticket appeared, the support team mentioned the developer in an internal comment. Here, we've added the "Discussed topics" box with several options to choose from. We've also added a gadget on the dashboard to count up the ticket number. In this approach, an issue could be assigned directly to the person taking care of a given app, although - just like in the previous method - the support specialist had to know who should they assign a ticket to. Also, using only mentions made cottoning on which tasks are assigned to the specific person more difficult. Furthermore, in a barrage of mentions, one ticket could just slip by, and the ticket analysis wasn't included in the sprint. What was an advantage of this approach was that communication in Jira was public, therefore in case of emergency - any other developer could take over the issue and have full access to the information.

3. Then, we took another step into reducing the support team's involvement in tasks distribution. We've implemented drawing during the sprint planning. Firstly, we were using a crystal ball with sticky notes, then we moved to an online drawing. Information with each person responsible for a given app was pinned to the Slack channel. This method brought the facilitation for the team leader, that finally wasn't involved in the distribution process. On the other hand, the workload was still uneven. And again, the support specialist had to check on an ongoing basis who is taking care of a given application each week. Taking into account that sometimes one ticket can be resolved for a couple of weeks, one developer can be involved in it, but the information isn't reflected in any sprint board, which inhibits the communication and information flow.

4. In the next step, we've introduced a Responsible developer - user picker field, where an agent can pick a developer responsible for a given task. This person is allowed to create a filter and see the tasks that they should work on. We've also modified the filter on board to show tasks from the support project. These tasks automatically appear on the board for a particular sprint. Thanks to the Responsible Developer field we are up to date with the distribution of the current tasks. By introducing this field, we wanted to be able to place tasks on the board and have clear information about who is dealing with a given ticket. Disadvantages? Due to the diversity of apps, some developers may be involved in work more than others.

5. Finally, we went forward to developing our app -  Assignment Rules - Issue Distribution for Jira, using Forge. We used over 2 years of experience and testing different methods to realize that the best idea would be to create our own app incorporating approaches that work the best for us. This step-by-step approach allowed us to automate and improve the assigning process. In the beginning, we worked on the app just to solve our own problems, but eventually, we've decided to release it on the Atlassian Marketplace and help other teams that can be bothered with similar issues. Using Forge profited in developing the application in a blink of an eye. Some Forge's limitations forced us to resign from additional functions but helped focus on solving the problem in the easiest way.

Now, thanks to the application, we can use the set queue of users to whom tickets are assigned one by one. The workload is evenly spread and we don't need to do anything more to assign the tickets. Sometimes, we miss the thrill of drawing the tickets

Advanced Confluence Integration for Jira

In Deviniti, the majority of employees skillfully maneuver between Confluence and Jira - the two applications we probably use the most. This doesn't mean we don't like integrations that would make our lives easier, and when the right situation occurs, we go for it.

Our sales department cooperates with the technical consultants, who deal with the implementation of services: more specifically, they conduct the implementation of Jira in organizations. The cooperation is very close: in order for the sales department to be able to send the full offer to the client, they need information from consultants. Both departments use Confluence to complete the pricing template - part of the template is completed by the consultants, and part by the sales department. Then, after the technical consultant completes the template, the sales team creates an offer. 

Each subsequent valuation generates a mechanical work:

1. Finding a template,

2. Creating a new page based on a template,

3. Complementing the content.

The need to automate this process and speed up the work of both teams was obvious to us, hence the idea for the new application emerged out of pure need. The team started working on the new application: Advanced Confluence Integration for Jira.

At first, the app allowed to display the template and automatically created a new Confluence page in the previously defined Space, where sales specialists copied the template and completed it. After the team, led by Agnieszka Cichocka, expanded the app's functionalities, we received the possibility to create a Page with the template with automatically completed data from the ticket. Both sales and consultants teams, while working on one ticket, don't have to create a Page or look for a template manually.

Here's how the process runs after implementing Advanced Confluence Integration for Jira:

1. The ticket, that the Sales team is working on, goes forward to the "To be priced" status.
2. A new Confluence Page is generated in a specified space with a template prepared for the pricing, supplemented with some of the template fields.
3. When a ticket receives the "To be priced" status, the technical consultants' team can begin working on it.

What distinguishes this Jira application from others? Agnieszka Cichocka, Advanced Confluence Integration for Jira Product Owner says:

Get inspired by our customers

A roadmap of ideas

Our customer support team is a real repository of ideas for new apps. We also use our customers' questions and tips to develop our products. That was the case with Requirements & Test Management for Jira - our testing app. The application's owner and the team use several places to collect feedback and ideas from users.

One of them is Trello, where the team created a roadmap for the authors and clients to exchange ideas. The roadmap shows the progress of individual features and helps users stay up to date with the progress that they're interested in. The board is divided into several columns: About the Roadmap, Ideas, Next, In progress, Released, and Future consideration. In the Ideas section, we collect new concepts that are under discussion within the team. Users can vote and comment on the features they find useful and which they'd like to enjoy in the next app releases. This way, the app's users can be actively engaged in its development. The other columns on the roadmap present consecutive stages of features' development on which users can also comment and leave likes.

What RTM's product owner, Jarosław Solecki, says about this type of collecting feedback?

Support tickets

Support tickets are still the main source of feedback in the RTM team. Clients leave tickets usually concerning bugs or issues that users can't manage on their own, but they also write about improvements that can be made inside the application. We either support them and solve their problems in the Customer Support team or give the ticket over to a developer. Support tickets help us stay on our toes and gather current issues from our users.

Demo sessions

Demo sessions are executed mostly by our Customer Support team and are sometimes attended also by the app owner. During these sessions, our specialists show every nook and cranny of the app - they go through each interesting feature with an existing or future client. Apart from discussing how the application work, it often happens that our team receives several questions concerning the app's possibilities. Sometimes, they can firmly say: "Yes, you can do that in the app!". But other times these questions become great ideas for improvement and further development. These 1:1 conversations often are a great source of inspiration for the future and a unique opportunity to look for new usability improvements.

Inside the application

But that's not the end of gathering feedback - also Hotjar turned out to be helpful in this area. For this purpose, we collect direct, short surveys from our clients. This space has its own character, as it serves as the first point of contact with our support team. Here, if a small error has slipped through the production phase, we get to know about it in a second. Although this is usually not a source of ideas for developing the app, the surveys are also a great place to collect clients' suggestions for minor improvements and their opinions on functionalities they would like to see in the next releases.

How to find the best ideas?

While we can draw inspirations for new apps from our daily work and support inquiries, we also found challenging ourselves extremely helpful in this area. What's the secret to an idea that will end with a real product? We feel that combining our intuition and market awareness with solid research and a great dose of creativity is the perfect mix.