- More product management teams are interested in using purpose-built technologies, but are unsure how to best select and implement one
- Russ Hammond shares the story of his product team’s journey from “general” tools to those designed specifically for product managers
- Testing several tools and planning for future growth and changes can help product teams select the technology that best fits their needs
As we’ve previously noted on this blog, product managers historically have had few designated applications at their disposal, leading many of them to attempt to cobble together solutions based on “general” tools or technologies designed for other purposes. However, as tools designed specifically for product managers become more numerous, we know that many product management teams are thinking about making the transition to dedicated product management technologies.
I recently chatted with Russ Hammond, director of growth at SureShot Media, to hear how he and his team have made the journey to product management tools, and lessons they learned along the way.
Jeff Lash: Take us back to where you were a few years ago.
Russ Hammond: Like a lot of b-to-b organizations, we used to conduct product management tasks primarily using “general” tools. They were easily accessible, our team members already knew how to use them and we didn’t need to spend money on new technologies. Most importantly, they appeared to be serving their purpose – at least for a while.
Originally, we used familiar applications like Excel and PowerPoint for things like defining requirements. We also had a UX/UI designer on board who was developing wireframes to show what had to be done in the sprint. When we finished our work, that would be the start of the requirements and stories for development sprints. Everything would be sent to Pivotal Tracker [an agile project management tool], because that was the tool that our development team was using.
Jeff: But at some point you started to run into some issues and challenges.
Russ: Right. We were having a lot of bumps in the process. For example, we knew we weren’t doing a great job estimating, and we were delivering things late and over budget. A lot of the problems came from how we were organizing and tracking things from a product management perspective, but we didn’t know there was any other way to do it besides using a development tool like Pivotal Tracker.
Jeff: So where did you go from there?
Russ: I had been a heavy user of Trello [a Web-based project management tool] for a while, for managing things personally. We saw an article about a startup that had been running their entire process through Trello. They had different boards for development, production issues, support issues, things like that. So we asked: Could we set up Trello to do this for us?
We searched around a bit to see if other people had tried to use Trello like this, and we found that a lot of people had tried it, but from a lot of the comments it was pretty clear that we would hit a limit with Trello. It was through [the comments] that we found out that there are actually specialized tools available for product management teams.
Jeff: What tools did you try out?
Russ: We looked at several products and ended up trying out ProdPad and Aha! One nice thing is that they both have free trials, as do a lot of the other tools. We didn’t just demo them to test them out; we set them up and actually used them within our development process. So, we would set up one of the tools and then run an actual development sprint using it. It was really helpful to see how the tool functioned in real life, using it for real development. It helped us learn more about both our product management process and our product development processes. We hadn’t really documented things too well, so once we were trying to use a tool to support our process, it forced us to think about the process we were using and see where we could change or improve. We could then begin to plan and think about how technology can best support our process.
Jeff: What tool did you end up choosing, and how did you roll it out?
Russ: We liked both of the tools, but we ended up choosing Aha! We felt it was a better fit for the way we wanted to do things. When we implemented Aha!, we first moved everyone into the same system – not just all of product management; we had the product development team start using it, too. Pretty quickly we realized this wasn’t the ideal setup. Product management and product development had different areas to focus on but were forced to do everything in the same system. So, we took a step back and re-evaluated things. By this point, there were some development teams that were already using JIRA for tracking their development progress, and it made more sense to have them keep using that. We had offshore teams that were using Pivotal Tracker. We pulled product development out of Aha! and just used it for the product management and design aspects, then integrated it with the tools that the development teams are using.
It really focused us to think more about the process we use, which was good. We’ve been able to see what each team’s strong areas are and why a particular tool is the best fit for their tasks. We all now see why we’re using each technology, and we’re able to use them better.
Jeff: Of course you didn’t want to deploy new technology just for technology’s sake – you had a specific goal in mind. What has the impact been on your team and the way you work?
Russ: It has allowed us to work much faster, and our estimates are much more accurate. Communication has improved between the teams. Deploying Aha! really was a sort of forcing mechanism for alignment between product management and product development to ensure expectations for each team are set and agreed upon.
Jeff: Now that you’ve been through the process, what advice would you have for someone who is currently thinking about switching to a purpose-built product management tool?
Russ: First, I’d say that if you’re working at a company that’s going to scale rapidly – like we were – recognize what might break in that next phase of growth if you continue with the way you are operating now. The way we were doing things previously wasn’t horrible, but if we had continued working that way, it would have hindered our growth and would have become a much bigger problem quickly.
You need to look at where you’re not working efficiently first. For example, do you have multiple teams working on the same thing? Are they working within the same systems or different systems? What manual aspects of your process will not scale? Which are automated already? For us, a goal of using product management tools was to eliminate as much of the manual work as possible.
Second, I’d encourage people to try out a number of different tools. I think for most people, they won’t need to do a formal RFP – for us, we certainly didn’t. Trying out the products and putting them through their paces on real development sprints was really helpful.
Third, you need to think about what’s important beyond just the features and functionality. In our case, the vendor’s willingness and ability to work well with us was also important. There’s no product that is going to match up perfectly with how you’re currently doing things or maybe even want to do things. For us, Aha! wound up winning in part because of their responsiveness as we progressed through the early stages of better understanding our product management and development processes.
Jeff: Any closing thoughts?
Russ: This journey has been really interesting, not just in using the technologies, but in helping us understand how we are working and seeing where we can improve. My only complaint is that we did all of this evaluation on our own, before you published the SiriusDecisions SiriusView: Product Planning, Prioritization and Roadmapping 2015. When I saw that come out, I remember saying, “I wish I had this nine months ago when we were starting to evaluate which to use!”
Jeff: Sorry you didn’t have it when you were doing the evaluation, but hopefully others going through the process now can benefit!