I came across this great quote from Steve Jobs while reading “The Lean Product Playbook” by Dan Olsen to describe “outside-in” product development and to describe not necessarily relying on customers to provide you groundbreaking ideas, but to know the problems your customers have well before a vision or product direction can be established:
You’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it….As we have tried to come up with a strategy and a vision for Apple, it started with:What incredible benefits can we give to the customer? Not starting with: Let’s sit down with the engineers and figure out what awesome technology we have and then how we’re going to market that. And I think that’s the right path to take.
For every product manager, there are 3 artifacts that are in nearly every job description: product vision, strategy, and roadmap. They build upon one another, where if the vision isn’t right, the strategy likely won’t be totally right, and then the roadmap will be even further from “right”. Then when it comes to iterative development of a product, the direction and metrics will be off and that introduces risk and waste into the development process.
Also, it seems there are often different definitions of these words at different companies. That is OK – take any components you find valuable based on what’s made sense for me, and what allows you to produce a clear sequential alignment to take in a product.
Vision
The main job: to explain to your team and stakeholders why this product deserves to exist. In many ways you are providing a glimpse into a future you find compelling (this is where some of your own personality, experience, and intuition come into play). You can present customer segments, trends in the industry, and specific user pain points to paint this vision.
A vision answers:
What is the driving purpose?
Why would the users prefer that over the status quo?
Strategy
The main job: provide a way to “score” success of the product with KPIs. It gives us a framework to reason about progress in the direction the vision establishes.
A strategy answers:
How do we measure success/what does winning look like in a measurable way?
How does that change over time? (eg: are there milestones we can associate with metric changes? For example, in the beginning of a product, the strategy metrics may be favoring adoption and growth; and as the months pass, retention and continuing engagement metrics may be more heavily favored.)
Roadmap
The main job of the roadmap: to communicate prioritization of features to stakeholders and the team with some time basis around completion. It will be the next logical step from the strategy. Based on the direction set in the vision, and the focus and measurement from the strategy, what specific features are you taking on?
Roadmaps, once created, are not constant. They are snapshots and could change anytime the PM becomes aware of new information, which may happen frequently so it’s usually necessary to have regular communications/reviews of the roadmap. It is a communication tool to the team, and to the stakeholders of the product for what’s important now, next, and in the future.
A roadmap answers:
What milestone are we aiming for next? (A good transition from the strategy)
What features are we working on to get there?
Why? (What buckets do they fall into: metric movers, customer requests, delights?)
Is there an expectation of timeframe for delivery?
I get asked this question a lot by newer TPMs, often coming from an engineering role. TPMs are really just PMs with strong technical backgrounds that build products for technical folks. But, at the end of the day we are PMs. This allows us to pivot the question:
As a PM, how well do I have to know my product’s domain?
At this point, it just kinda seems obvious, doesn’t it? You have to know it really really well. TPMs often are engineers first, so it’s difficult for us to think of ourselves now as product managers first, especially when we were just building software in the domain we now manage products within. However, the complexity in this problem is rooted in that as an engineer, technical == writing code. But, as a PM being technical == understanding the technical domain well enough to make better economic trade-offs for the benefit of the product. Specifically, what are type of technical competencies?
The best TPMs are deeply technical, often seen as SMEs – subject matter experts – within their technical domain. They were often experienced engineers first. Here are common behaviors:
Staying aware of the “cutting edge”/developing technologies and approaches. Am I aware of how technology is changinging in my domain? How would that benefit the users? Am I overdelegating the understanding of capabilities offered by the technology to my engineering team?
Knowing the design/architecture well enough to determine general technical cost-benefit analysis of product changes. If my technical lead were out, would I be able to have rational design discussions with our engineers?
Dogfooding their product for their own work/breakable toys. Am I staying as technical as the users? Or is their world changing in a way that makes understanding mechanical sympathy more problemattic? Am I able to empathize sufficiently?
Extra Credit: Enganging the broader community via speaking or writing.
Example
Highly technical (co-creator of GraphQL) and demonstrates using the tool. He leads by showing it working.
Worked closely with product teams to define pain points they had, leading to GraphQL. Identifying customer segments, pain points, prioritizing, then executing on that prioritization. It’s unclear if that would’ve been possible without closely working with the technical product teams.
Able to tie the pain point use cases from users to the larger concepts GraphQL uses or solves (eg: why static type systems were included, why declarative styles are good – all to solve the pain of predictability and efficiency)
Showed deep knowledge of other related concepts, like what a graph actually is and how it relates to GraphQL
I won’t get all of it, there is much more. But, I think this is a great example of a TPM.