How We Use JIRA and Aha! to Build Great Products
In addition to developing super snazzy web apps for our clients, did you know that we also develop our own products here at Ricochet? While some of these applications are used exclusively by our internal team to improve how Ricochet functions as an agency, some actually end up getting launched as standalone products (such as Pushpin Planner, FunnelCake, and TripVerse, with a few more in the works).
Anecdotally, I was surprised to learn that most agencies have dreams of developing their own products - but in a way, I also kind of wasn’t. It makes sense that a software development agency, a team that builds stuff for a living, would want to develop their own apps for a multitude of reasons (scalability, creativity, etc.).
However, one thing consistently gets in the way. It’s just plain hard to do! Building a product is challenging on its own, but building a product while you have another business paying the bills can become nearly impossible. This additional workload tends to gobble up the resources and focus of your team. When it comes down to it, your product never gets the attention it deserves because it always plays second fiddle to client work, the priority. I discussed this priority issue with Karl Sakas at Agency Firebox last year and, if the topic of product attention is the monkey on your back, I encourage you to take a look at the interview.
While that’s certainly an important conversation, today I want to focus on the more pernicious problem: how to get your product the mental space it deserves. Short of having cash to hire people to focus only on your product — which, to start, is definitely not going to happen -- you’re going to deal with pushing the peanut forward with several half-brains rather than one or two full-brains. The way we’ve solved this problem at Ricochet is to formalize three important roles (Product Manager, Project Manager, Product Owner) and we distill down the responsibilities for each so that the brain doesn’t spend too much time figuring out what to do next. As a result, the individuals on our team know exactly what they need to do each week to further the product and can focus on doing those things with creativity, passion, and a clear mind.
Project Ricochet is a full-service digital agency specializing in Open Source.
Is there something we can help you or your team out with?
The Three Roles: Product Manager, Project Manager, Product Owner
**Be warned: Everyone treats these roles a little differently and we’re no exception**
Product Owner
The Product Owner is the product’s champion. This is the person with the vision, dream, excitement, and energy. She is usually the team member who came up with the idea or the idea simply spoke to this individual from the start. She sets the course or strategic vision for the product, much like a ship captain would tell the first mate to chart a course for a new country.
Product Manager
The Product Manager is focused on executing the vision of the Product Owner. He knows where we’re headed and is tasked with researching competition, users, potential markets to focus on, and generally filling out all of the details of strategic vision. He also comes up with the problems we are trying to solve with the application (through work with the Product Owner) and develops a feature set that will become our Minimum Viable Product (MVP). He organizes these features into releases and plans around the assumption that features will go out when he schedules them. He also oversees the validation of these problems once the development has been completed and formalizes the learnings from users as they actually use the application.
Project Manager
The Project Manager is concerned with coordinating resources to complete the tasks created by the Product Manager. Essentially, the Product Manager sees tasks magically appear in the PM software and schedules those tasks in Agile sprints. He also snags resources in our resource planning meeting in order to hit the deadlines set by the Product Manager. He is the dude on the ground getting his hands dirty with the nitty gritty of transforming all these features into code through his development team. If something can’t be done for whatever reason, he informs the Product Manager who can then change course in light of the shifting reality.
Onward to the tools
With that basic terminology out of the way, let’s now discuss the two most important tools we use in this process.
Atlassian JIRA
The Project Manager uses JIRA to make a given release happen in an Agile manner. We assign point complexity to tickets in the backlog via Planning Poker, then drag in however many tickets we can complete in a weekly or bi-weekly sprint. Sprint after sprint, all the tickets in the release get completed and the Product Manager can then work at validating the assumptions that went into creating the features in the given release.
JIRA is incredibly effective and we at Ricochet have invested a considerable sum on integration so that all the tools we’ve built make it even more powerful. But even with all its greatness and power, JIRA unfortunately falls short in a few places. First, it is a bit clunky and too "engineer-like." Second and most notably, backlogs maintained in JIRA can very quickly get out of hand and unwieldy, which can make it quite hard to manage strategically and to make sense of it all.
In a nutshell, JIRA is good at executing tickets, but it’s not good at setting a strategic course for the product. It also becomes troublesome when you have both the Product Manager and Project Manager in the same tool trying to organize their own worlds, which can produce some occasional conflicts.
With that being said, this brings us to the tool that does do this well: Aha!
Aha!
Aha! was a godsend for us. It allows the Product Manager and Product Owner to collaborate and set a strategic course for the product. The best part? We can organize, organize, and organize some more until both have control over the strategic universe. It also allows the team to submit ideas for the product without muddying up the feature set before they should. This is especially useful in the case of duplicates, things that are already in the works, or just plain silly items.
When the Product Manager is ready, he then ships off his features to Jira (there is JIRA integration) and he knows he’ll hear back if they can’t all get done. Ultimately, we’ve found that a key part of retaining mental space is finding a tool that does exactly what it needs to do while giving the relevant person a “flow" to do their work without interfering with others. Together, Aha! and JIRA do just that.
Here is a list of what Aha! allows our Product Managers to do:
- Develop a flow for processing new ideas from the team whereby new potential features can be considered and rejected/deleted or promoted to an actual feature for future release.
- Organizing features into Releases so that plans can be made around when things will be live.
- Categorizing features according to strategic importance, even when what is strategically important changes over time.
- Assign a “score" to a feature based on a scale and criteria that you define. You can even do things like assign a negative score for certain attributes, such as, “give this feature negative points based on it’s complexity," which means that complex features will have a slightly lower score. This is HUGE because you can then sort features by score and find those that deliver the biggest bang for your buck.
- The Product Manager can organize to his heart’s content without muddying up the JIRA backlog or making it impossible to make sense.
Follow us on Twitter for news and updates.
The Aha! Checklist
As you can see, both JIRA and Aha! working together is the cleanest way to separate these roles and allow for work to get done efficiently in each team’s universe. Now, let’s dig deeper into how we specifically use Aha!. Below I’ve outlined a checklist you can go through within Aha! to ensure that your product development is on track.
Perfect state to shoot for:
- No “ideas" in needs review
- No features in “unconsidered"
- No features in “needs discussion" and *not* in Icebox Release
- All features have a score using a relevant custom Aha! Scorecard
- All features have an initiative
- All features have a goal
- All problems are ranked in order of importance
- All features can be tied back to a specific problem (using tags or initiatives).
- All tickets are in a Release
- Active release: Planned to be released
- Parking Lot: Waiting to be planned
- Icebox: Probably won’t happen right now or for a while, if ever
- All tickets in a Release are in Jira
- You don’t have to sync every ticket, just the release once it’s ready to get shipped to Jira
Tasks to be done as team:
Ideas:
- Review any ideas in “needs review" status
- Assign to new status:
- -> Future consideration
- -> Already exists
- -> Will not implement
- -> Planned
Features -> List
- Review any features in “Unconsidered" status and update status to appropriate status (most likely “needs requirements")
- Review features in “needs discussion" and *not* in Icebox Release
- Review any tickets without a score and assign score
- Sanity check: ensure that all tickets have a problem tag, feature and initiative (bearing in mind that the assignment process should take place without the team)
Roadmap:
- Review roadmap, see if there are any blockers
Strategy:
- Vision: review any updates
- Review Goals and tickets within
- Review Initiatives and tickets within
Problems:
- Review Problem ranking
Tasks for product manager to do without team:
Ideas:
- Review any ideas in “Future consideration" status.
- Update status accordingly if the time is right (for instance, to “will not implement")
- Change any that need to be discussed to “needs review" to discuss with team on next weekly review
- Alternatively, if the time is right, change status to “Planned" and promote to a feature
Features -> List
- Ensure that all tickets have a goal
- Ensure that all tickets have an initiative
- Ensure that all tickets are tagged with a problem
- Ensure that all features in an active release have a “Jira Key"
- Just need to sync release
- Define requirements for any tickets in “needs requirements" status and move to “ready to develop" when done
Releases:
- Create releases of tickets in “ready to develop" status that have had requirements specified from “Parking Lot" release.
Problem List:
- Prioritize the “problem listing" based on customer feedback / reality “from boots on the ground"
Strategy:
Updates to Vision:
- Customer challenges
- Strengths
- Market
- Competitors
- Weaknesses
Quarterly:
- Purge any tasks in Icebox that are no longer relevant
In conclusion
Of course, the steps above could be elaborated on endlessly. While some of what I outlined may work for you too, you’ll certainly have your own take on how to use it effectively for your own situation and I suggest to simply begin using the tool and see how it works for you. The most important thing to remember? Make sure you define a system which allows the overhead of the process to become so automatic that your Product Manager and Project Manager can apply their energy as they have mental space and make iterative progress on each herculean task.
As a team that has been through the arduous process of giving our own product the mental space it deserves, we at Ricochet know it can be daunting and challenging. So, remember, we’re happy to help with any questions that you may have. We hope to make this process easier and, ultimately, very successful for you and your team!
Curious about how much it might cost to get help from an agency that specializes in Open Source?
We're happy to provide a free estimate!
