Product management has seen many shifts in approach — personas vs JTBD, LEAN, Scrum, etc. — but among the most transformative has been the shift from celebrating output (release feature X) to celebrating outcome (move metric Y). Allowing teams to focus not just on moving fast, but also own business outcomes shifted the way both individuals and organizations operate. What goes into how well we succeed? We know speed matters, and measure it as throughput, we know individual releases matter, and we can measure by A/B testing. How do we know if the problems we choose to solve are the right ones? And more importantly, what can we do to make sure the inputs to those choices are the best we can do?
Let’s take a look at how ideas flow through our organization, what inputs determine the problems we solve, and how to reshape those inputs to yield better outcomes.
Imagined vs Actual Flow
We like to think of our flow of work something like the image above.
- Clear company mission and vision, paired with strategic understanding of the market and core capabilities, yields a small set of objectives, which break down into user problems to solve, then down to some releases, and finally you have your resulting outcomes.
The above image is a simplified view but gets the point across for the most part. In reality, at most organizations, our work flows something more like the image below. Sprinkle in a couple “urgent” issues, some “low-effort” features to land or retain a client, and your strategic prioritization is cut at the knees.
What happens when our process looks like this?
- We slow progress toward our long term goals.
- Our product becomes more fragmented and less cohesive.
- Long term progress toward mission is de-prioritized in favor of short term wins.
- Problems you choose to solve become less strategic, less focused, and lose sight of “why”.
- People become unhappy with lack of progress and stagnation.
What are Product Inputs?
At your typical organization, there are plenty of bad habits and ways to improve what goes into your product — stakeholder communication, research, a/b testing, engineering velocity, go to market, etc. These are all essential to success, and you need to focus on them. Sometimes in all the hustle, we forget that we will only get out of the system what we put in. Your engineering velocity isn’t what determines whether the work was valuable. Additionally, an A/B test can only tell you if you solved a problem well, not if it was the right problem. It’s time to look at the inputs — a product input is any factor used to determine the what, why, and when of items in the above flow. Refining inputs will shape your objectives, how you decide to solve them, and what outcomes you ultimately drive. Here are some common examples of product inputs:
- Company Mission: Why does your product exist?
- Company Vision: What should your product solve for users in the future?
- Strategic Position: What do we do as a company, what don’t we do, and why?
- User Research: What have you learned from users /can you learn from users?
- A/B Test results: What have we learned about how users interact with different versions of our product?
- Quantitative Evidence: What have we learned about how users interact with our product as a whole?
- Sales Input: What insight does sales have about the market and our customers?
- Customer Success: What have we learned about gaps in our product / what we do well?
- Executive Input: How are we performing as a company? What do we need for investment? etc.
More often than not, your inputs will look very different than the descriptions above. For example, you’d hope your stakeholder inputs look like this:
Hey, these 5 sales leads are asking about X, we dug deeper and it turns out they’re struggling with problem Y, so we should invest in solving that problem in the context of our product.
In reality they might look more like this:
We can close a million dollar client if you just build this very specific feature in the next 2 weeks.
As a product organization, we care deeply about user inputs, but we must understand how to reshape and refine identity and stakeholder inputs into useful insights into the varying needs across the organization.
Better inputs, Better outcomes
We all want a focused, aligned, and strategic-thinking organization, poised for growth and success. Moving toward that is easier said than done, but you can employ a few steps, all aimed at one key goal:
Reframe each product input as an insight into needs of different groups. Don’t dismiss sales input, for example, instead reshape it into a need and evaluate it properly.
If your inputs that determine the problems you solve are poor, your outcomes will be poor, no matter how quickly you move.
1. Explicit short vs long term goals
Separating your short and long term goals for your company can help reshape others’ view of your roadmap quality. This step strengthens and formalizes your Identity inputs to make them more resilient. You can then more easily defend the potentially less immediate value you gain from working toward long term goals, keeping you focused and able to put strategic value on the work you are doing based on your company’s mission, vision, and ideally, from user input.
Examples from Strong Product Organizations
I really like a couple examples of how companies ensure they maintain the long term picture. Intercom and Facebook come to mind.
Explicitly writing this down and sharing is a good way to remind everyone what the company and product should aspire toward. Pick your timelines appropriately. For example, if you are a brand new startup, maybe don’t jump straight to the 20 year mark, but pick a realistic timeframe in years, not weeks, in a way that is detailed enough to maintain focus, but still problem focused.
Good example of a long term goal:
In six years, we will be the number 1 consumer finance platform to help middle class Americans’ understand and make informed financial tradeoffs.
Bad example of a long term goal:
In six years, we will have an AI powered recommendation app. to balance your mortgage payments, 401k contributions, and HSA spending.
These may not be bad ideas, but by tying too closely to specific features, you leave no room for market changes, technology changes, and generally for refining your stance.
How to leverage your new long term and short term roadmaps
Like any roadmapping exercise, your goal is to retain focus and share out direction for the company. If you have a clear and strategic long term goal for 6 years from now, you can clearly defend the roadmap items that build toward it. This shifts the conversation from
“Hypothetically, we’ll work on vision after X, Y, and Z”
“We want to be X in a few years, and these are the problems we need to solve now to get there.”
If you build out a long term vision for the company while also generating consensus among stakeholders, you can defend and explain the importance of each item. You can now ask :
“Does this get us closer to our 6 week / 6 month goals? Or does this move us in the direction of our 6 year goals?” If not, do we need to rethink them?”
- Build a long term roadmap with an explicit goals based on user problems.
- Use that long term roadmap to communicate value of strategic work.
- Weigh that strategic value against stakeholder inputs as they come to you with requests.
2. Focus on the why to reshape stakeholder inputs
For sales and executive inputs, and to some extent, customer success inputs, we often see them come in the form of a feature request:
Can you build feature X for our users?
The best way to dig down into this is to do some due diligence and take an honest opinion about where it fits. You need to take a few steps to reshape this stakeholder input:
- Clarify the stakeholder input into a problem statement
- Tie your problem statement to an outcome.
- Raise competing priorities.
For more detailed insight into how to redirect shiny object syndrome, read here. If you’ve done your work on clarifying problems, you can then have the conversations
When you have clarified the problem and tied to an explicit outcome, you should add one extra layer in. Now that you have a roadmap with long and short term problems to solve, you can start asking a key question:
Does <request X> move us toward short or long term goals? If we push <roadmap item Y> out, are we still moving toward our short and long term goals, and will the balance between the two be appropriate?
This grounds the conversation so everyone is speaking the same language. PMs typically know when we’re sacrificing work toward our mission, but stakeholders are coming from one specific view. Don’t blame sales for wanting to close deals — instead, have an honest discussion about what that really means.
- Clarify the problem, Tie to an Outcome, Surface Competing Priorities. Once you are talking apples to apples, then determine next steps.
- Explicitly talk through the balancing of short and long term problems— use your long and short term roadmaps defined earlier to ask “Are we moving toward our short and long term goals”.
3. Explicitly Track Inputs And Outputs
At this point, you have two assets at your disposal:
- A clearly defined roadmap for both short and longer term problems.
- The tools to clarify problems, communicate competing priorities, and a clear and explicit way to ask “are we moving toward our long and short term goals?”
Now you need to figure out how to track your performance over time. I like to use tools I’m already using, and augment them. The goal here is to have something trackable, mutable, and designed to keep your goals in mind. I am assuming in my example that you track a few things:
- User Stories with Story Points
- Epics that contain User Stories
- Sprints (or Kanban) that contain stories.
Let’s now add in a layer to track the “why” of our work at an aggregate level. Create initiatives for each of your objectives, along with some “distraction” type initiatives. For example, if you get a lot of requests from sales for custom client requests that don’t fit into another objective, create a “Sales Request” initiative. Here’s how to use this:
- At the end of every sprint/month/quarter, we can see how much we redirected toward these distracting requests.
- We can see if we are trending up or down — more focused or less focused
- You can track when you are being over-distracted. If your boss says for the 4th time this sprint “I know it’s not good process, but you just need to get this one thing done,” you now have recourse to respond: “we’ve already committed 55% of our sprint to non-Objective work. Do you want to increase that to 75%?”
- Categorize your objectives into initiatives, and tie all strategic work to them.
- Categorize buckets for distractions, and tie distraction work to them.
- Track investment into each.
- Use that to communicate when the system is broken / imbalanced.
All things considered, we want to make sure that the inputs going into how, when, and why we solve user problems are getting better, not worse. You can start to move your organization towards that with a few key steps, making the inputs to your work more focused, while also reducing distractions.
- Create explicit long and short term company goals.
- Reshape the why of inputs, and ask which goals this moves toward?
- Track what you are doing towards each goal, and how much we commit to distractions from those goals. Raise the issue when imbalances arise.