Do people in your organization claim that the organization is product focused?
Do they mean it? Aren’t sure how to tell?
Just because you have a stable, dedicated team that works on the same product over a period of time–that good start alone does not make you product focused.
Organizing those teams into a multi-level hierarchy of lines and families does not alone make you product focused. It can be helpful, but when you’re in an internal product situation, it can also lead to potentially unnecessary overhead. Especially if you don’t have a clear idea of what you define as a product.
Having people with titles of product manager and technical product manager does not make you product focused. Especially if the people holding those titles are doing something other than what most people view as product management.
Being product focused means you use an understanding of the outcomes you are trying to deliver in order to determine which outputs you do and do not provide.
Being product focused means you measure success based on delivering those outcomes, rather than strictly on how much output you produce.
Being product focused means you deliver maximum outcome with minimum output.
You still care about outputs. They are, after all, how you bring those outcomes to fruition. Just don’t create a feature factory without any clear guidance of what the feature factory should produce.
This week’s resources take a look at outcomes and outputs and provide a more nuanced view of the relationship between those two ideas. It’s not an either/or, it’s a both/and.
Rethinking outcomes over outputs
The product management world has recently been torn asunder by the idea of prioritizing outcomes over outputs.
For once, the big debate isn’t about the brand of Post-Its or Sharpies. It’s not personas versus Jobs-to-be-Done. It’s not even about what should be a roadmap and what shouldn’t be. It’s about this idea that there’s a core difference between the output of a product team and the business outcome generated.
In this episode of the Inside Intercom Podcast, Des Traynor and Paul Adams discuss the five inputs that guide Intercom; how to think about the relationship between inputs, outputs and outcomes; and how to frame projects as customer problems instead of business problems. You can listen to their full conversation above, or read a transcript of their conversation.
Great PMs don’t spend their time on solutions
Over the past few years, the folks at Intercom have learned a lot about building product.
Some things have worked really well, some less so. To try and learn how to replicate their product successes as they scale, and teach new people what is working, the folks at Intercom been doing a lot of reflecting on how we work.
Paul Adams believes that deeply understanding the problem each project sets out to solve is a major factor in contributing to their progress so far. In this post Paul describes how his team goes about understanding the problem they are trying to solve.
The benefits and pitfalls of outcomes over outputs
I often suggest that you focus on outcomes over output, but never explained why. Here’s a look at the benefits and pitfalls of a focus on outcomes.
How agile business analysts discover outcomes
A look at how agile business analysts discover outcomes in a measurable way to help guide them in determining the scope of their effort.
Feature injection clarified (hopefully)
Feature injection helps you treat outcomes and outputs in the appropriate manner because it drives you to use an understanding of the outcome you hope to accomplish to drive which outputs you deliver and which ones you postpone, or don’t deliver at all.