September 14, 2017
Selecting The Minimum Viable Toolset for Product Managers
Recently I was attending a machine learning conference and during a break, found myself deep in conversation with fellow product managers. As is typical with these things, we were sharing best practices, battle scars, wins, what works/what doesn’t in our different industries. Topics ranged from “How do you keep your team focused?” and “How you do set priorities?” to “How do you build consensus among groups?” and “What do you do when velocity changes?”
I love these conversations and opportunities to share and learn from my peers.
Then, out of the blue, the product manager next to me asked...
“So, our tools are slow and hard to use. What tools do you all like?”
Names started flying...Someone said “Roadmunk.” Another product manager couldn’t live without “Aha!” - its step-by-step method solved all the problems in her book. Cue the unicorns and rainbows. And of course, the usual suspects appeared...JIRA, Trello, inVision, Sketch, HipChat, etc. Each colleague had a different favorite, but they all had something in common.
They were all fiercely loyal to their tools because they solved a problem - whether it was controlling a complex backlog, communicating a detailed roadmap, visualizing a customer journey, or fostering team collaboration.
When it was my turn to share, I paused and said, “It depends.” And it really does.
I’m lucky. My teams build a wide variety of products of varying complexity, in different industries for different partners, so we get to use many different tools.
We have our favorites, but when my teams start a new product…
I want my brilliant engineers, my visionary UX designers, and my focused QA engineers coming together as a unified team to analyze the problem and deliberate the best outcome,
not to wrestle with a tool.
When we start, we pause for a moment to think about “The Optimal Toolset;” the tools that will help us ship a high quality product quickly, without getting in the way.
Here are a few of the things we’ll consider:
Product Complexity: How many moving pieces are there? Do we need detailed bug tracking or can we use a faster, lightweight option? How many tools are we needing across the project and can they play nicely together? Will it save our designer time to open a JIRA ticket within his or her Sketch file?
Timeline: Are we launching our MVP (Minimum Viable Product) in 10 days or 2 months? If my team is racing to ship a simple product in 10 days, I need a very nimble, light tool because we’ll have a lot of verbal communication and “just enough” written communication...think Trello instead of JIRA.
Team Size and Location: How many groups do we need to collaborate with? Where are they located? Can I attach a video file to a ticket to walk my Romanian engineer through the interaction design so that she or he can code well while I sleep? What collaboration tools allow us to be most efficient? Will HipChat’s integration with JIRA save us time or is Slack enough? Are there data integrity issues we need to be aware of with 3rd party collaboration tools?
Product Lifecycle: Where are we in the product development cycle? What level of detail is needed? Am I at the start of a nebulous product where we’re super nimble and lean? Then our MVP will provide insight into our evolution and I need a lightweight roadmapping tool, just enough to communicate our initial MVP vision. Or if I’m post-MVP and my product has evolved, I’ll need a more robust, full suite, step-by-step roadmapping tool like “Aha!” or maybe something a little lighter but with a strong feature set like “ProductPlan.”
Preference and experience of team: This is key. If my team has to spend time on a new or cumbersome tool, they are not thinking about the best way to solve the user and business problem. That is not a path we want to go down. Ever.
Expertise of stakeholders: Does the tool offer views that are appropriate for the needs of different audiences? My engineers, QA and UX teams need a vastly different level of detail than my marketing department, content teams, investors, and executives. For example, in Roadmunk I can use the same release plan for different audiences. I can expand and collapse features to see additional details such as significant milestones. I can use color-coding to communicate the stage the feature is in. For my engineers and QA teams, in the comments field I can link to a JIRA ticket, but my marketing team doesn’t have to see that detail. One size fits all, and saves me time.
Flexibility: Can the tool grow with us through the product lifecycle? As we launch and learn how users are interacting with the product, the complexity can shrink or grow depending on user feedback and market conditions. I don’t want my teams having to switch tools midstream.
Compliance: Are there institutional rules that require strict process and segregation of duties? For example, a corporation’s process may require that only QA engineers move a ticket out of the QA swim lane and into “Done” or back to “In Development.” I don’t want my team to have to remember that. I want my tool to enforce it.
Fundamentals: Of course we’ll look at basic, must-have features such as: mobile feature set, security, integration with other tools, sharing, alerts, deadline setting, different views for different role types, ease of setup, collaboration features, cost, support, and licensing structure.
I don’t care if we’re using the most robust or popular tools on the block.
I care whether they help us get the job done without getting in the way.
I want my team to spend their time doing deep, insightful user discovery, developing thoughtful strategy, creating brilliant design, quality, well structured code and conducting thorough QA tests.
The tools are there to support my team, not to get in their way.