Best Practices

Connecting the Dots Before You Need Them


Starting out as a PM, I became very good at finding what I thought was a perfect answer to a problem. Should we continue to support Firefox? Yes, there is precisely 1/3 of our customer base using it today based on the data I just researched. Correct answer, says my director! It was the most comfortable way for me to function right out of college, where you only get asked a question once on a test. And it felt good, simple and the right way to do things. Doing just enough research to answer questions as they come, just in time, was my initial interpretation of being Agile and data driven.

In other words, I’d wait for questions, and present a single point of data – the answer to the question.


This worked great for a while, but soon it became clear that situations change (and our decisions get retested, unlike in college). In product development, we answer similar questions repeatedly as situations change. I began to understand why when presenting answers, it’s valuable to associate and document the original why — the reasoning and data. Makes the inevitable revisiting of your choices much less painful.

Q: Should we continue to support Firefox, 6 months later? A: Well, let me check my thought process and that data again — wow the customer usage profile is now only 25% but that’s still enough to say Yes. Sounds right, says my director!


After getting in the habit of connecting the why to my choices, it becomes rapidly clear that questions and answers are not one-to-one. To truly prepare for revisiting a choice, there are probably multiple directions you could go. My world looked like a one-to-many graph of roadmap drivers, and decisions.

Q: Should we continue to support Firefox, 8 months later? A: As a rule, we support browsers that are over 10% of our customer usage. So far that includes Firefox, Chrome, and IE. Sounds right, says my director!


The way I thought and operated became more and more strategic. But I was still not anticipating most of the questions from my leadership team. I was nimble answering known lines of inquiry, but not so great a navigating related but not exact questions quickly. I had all the environmental data I needed to create an answer, and I had a documented strategy, but tying the pieces together took a lot of work. More senior decision makers on my team had a system, that I soon realized was one more iteration on my mental model of decisions. Capturing many-to-many data relationships between our strategy and tactical plan was essential.

Q: Should we support Firefox? What’s the impact of not updating our support? How much does it typically cost to add support for the latest updates every 6 months?


With this more complex map of what’s happening, deeper questions can be answered because of the connections. It looks like a “5-whys” root cause analysis, but ahead of time. This is the power of tracing data together as you work. I appreciate now that keeping data around for why you did something, as well as why you didn’t, saves wasteful revisiting of choices. The trick with all of this is actually keeping data in a form that serves many purposes, and to avoid creating a ridiculous burden up front. To keep track of a simple 1:1 relationship of task to the why is very possible in a standard task management tool (JIRA, Trello, checklists on etc.). However, once you are PM for a product shipped more than a few releases, that backlog of work is driven by many forces. It’s not a dynamic list with multiple data types as inputs (market research, customer conversations, product vision). Rather than manipulate such tools designed to enhance productivity and focus on live tasks, once you have enough complexity that you revisit decisions it’s time to bring in something a bit different. For me, that tool has (perhaps obviously 🙂 ) been Jama. It holds that conversation that happens BEFORE you decide to build, and it saves the decisions you made long AFTER your product ships.