You left engineering because you were tired of:
- PMs who don't understand system dependencies
- "Product people" who can't think in flows
- Leaders who demand random features
- Roadmaps built on hope
But what if product management was actually about systems?
"Thinking in Systems" blew my mind:
Higher order thinking
There are 2 types of thinking:
• Lower order: memorization, understanding, applying.
• Higher order: analyzing, evaluating, creating.
In simplest form, the more you connect and test relationships between ideas, the more you remember.
Many PMs struggle to explain the difference between Vision, Strategy, and Roadmap.
But those are extremely simple concepts.
So let's tackle them one by one:
-
1. Product Vision (Why)
Product Vision is the long-term mission of your product. It’s aspirational and motivates your team to wake up every morning and go to work.
For example, “Send humans to the Moon” or “Help tour operators focus on doing what they love.”
Effective vision needs to be:
- Inspiring: people who help to implement the vision should feel inspired
- Achievable: it must have a decent chance of working. Don’t dream of traveling to Alpha Centauri until you send humans to Mars
- Documented: do not let the vision stay in your head. You actually need to write it down to make it work
- Communicated: it seems obvious, yet many forget about this. The Vision will only be effective if you communicate it to others
- Emotional as well: vision becomes much more memorable when others can imagine themselves doing something practical and when it speaks to their hearts
-
2. Product Strategy (Where & How)
Despite what many experienced people repeat, Strategy is not a plan, a goal, or a set of actions.
It's a cohesive set of choices that, as you believe, will allow you to win (achieve your Vision) at the playing field of your choice.
For example:
- market and its constraints (e.g., geography)
- value proposition
- relative costs
- tradeoffs
- growth model (e.g., PLG)
Strategy should pass the “can’t / won’t test” so that competitors can't copy it without sacrificing their existing businesses.
A fantastic, short video by Prof. Roger Martin: https://t.co/nEyXM33cVj
For more information about Strategy, see my free article (no email, no paywall): https://t.co/fJvz3tvofx
-
3. Product Roadmap (What)
Product Roadmap is a communication tool that allows you to align everyone in the organization. It creates focus on what’s important right now. It should also explain the reasoning behind it.
In 3 Ways to Create 10X Better Product Roadmaps, I emphasized that it's extremely important to:
- Focus on goals, not features (an extremely common mistake)
- Do not commit too soon
- Shorten the planning horizon
Free article (no email, no paywall): https://t.co/crGQ0WbCT0
-
More information:
- Vision, mission, and purpose are often confused, and everyone interprets them differently. I use a single term. An article by Prof. Roger Martin: https://t.co/MIgMuQGlVu
- Some say that Vision is part of Strategy. It makes sense, as Strategy is an integrated set of choices. And you develop them together. But that’s not the most common opinion. So during interviews, you might want to keep it simple.
Hope that helps.
What are your thoughts?
-
P.S. In my latest newsletter, I debunked 16 other misconceptions in Product Management. Read it here by becoming a subscriber: https://t.co/QeioCUYnAh
Every PM wants to get better at strategy.
I used to love studying strategy but got lost when I tried to make my own.
Then I learned how to make product flywheels. Now I always know where to start, and how to drive alignment.
Here's a step-by-step guide to making your own 🧵
Every product manager has a unique way of thinking, approaching situations, and solving complex problems.
These unique ways are usually referred to as mental models.
A mental model: is a (mental) process that empowers us to break complex things into simpler understandable chunks.
Great product managers use many multiple models everyday. Some of them are prominent, and some are subtle.
Mental models are critical to our success. They enable us to structure our thoughts, internalise our learnings, and make high quality decisions.
Most importantly, they empower us to help our stakeholders, bosses, customers to understand the essence of the problem and to appreciate the beauty of the solutions.
Over the years, I've built various mental models.
Three areas where I benefit the most from mental models:
1. Prioritisation
2. Ideating and innovating
3. Cross functional alignment
In my next newsletter, I will share the detailed models I use (for the above areas), and how I apply them to real life.
Sign up today and be the first one to read more:
https://t.co/vQ4JAML5fF
A systems thinker...
1. Views "wholes" over "parts"
2. Discerns interconnections and feedback
3. Grasps dynamic behavior
4. Sees the system as the cause of its actions
5. Comprehends how system structure drives its behavior.
🔗 https://t.co/uERbW1gQKC
One of the highest-leverage things a PM can do with an org is:
1. Understand the mental models others in the org are working with
2. Work to change those mental models to align with reality
These mental models can be about anything from your users to your tech stack.
Be careful. Most "products" are, in fact, projects.
9 red flags (and how it should work):
1. You start your initiative by writing a large PRD.
2. Your goal is to implement the requirements (features).
3. You have an Analyst who collects them all in the "initial phase."
4. You have a time-based, feature-based roadmap.
5. Let's just Scrum! There is no need to test ideas before implementing them.
6. There is no Product Designer on the team.
7. There is no product analytics. You don't really know how people use your product.
8. There is no product strategy. You try to maximize sales by satisfying all customers and grasping every opportunity.
9. You work in a customer-vendor relationship (internal or external).
-
Here is a better way:
1. Your cross-functional team is empowered to solve the problems.
2. PM, Product Designer, and Lead Engineer perform Product Discovery together. Continuously.
3. You have an outcome-based roadmap. Preferably Now-Next-Later.
4. If you commit to a date, you do it rarely and only after the Discovery. You never commit too early.
5. You manage the value, usability, feasibility, and viability risks.
6. The riskiest assumptions are tested before the implementation.
7. Choosing, instrumenting, and tracking the right metrics is key.
8. You ship incrementally, measure the outcomes and learn from it.
9. Tradeoffs are essential. What you do, but also what you don't. You respect your market and the unique value proposition.
-
And before the launch:
1. You must define the market, unique value proposition, business model, and initial vision and strategy.
2. You should test your business idea with the help of the MVP prototype. Before the implementation.
3. You need to define the go-to-market strategy.
4. You can't rely on product analytics before the product is launched, so that you will rely more on customer interviews.
5. Product Discovery should be performed by the Product Trio. Nothing changes here. You always need a Product Designer and Lead Engineer.
6. Once you ship, use product analytics and apply Continuous Product Discovery.
-
What are your thoughts?
Drop them in the comments.
2/ Organisation Strategy
is the way for the Org. to realize its vision (..the How)
It includes clear bets + action plan to provide value to customers, employees and shareholders.
It's about asking:
How will the org. win?
What capabilities to build?
Culture?
Where to invest?
PM is not the CEO of the Product. But it doesn't stop there.
She shouldn't even dictate WHAT needs to be built.
Let me explain. In most companies, it goes like this:
1. Stakeholders decide on the high-level roadmap
2. PM refines the details and creates User Stories ("WHAT")
3. Work is waterfalled to the DEVs, who only decide "HOW"
4. Designer tries to make it prettier. It's like lipsticking a pig
That's a waterfall and stage gates. Even if you use an Agile framework, don't lie to yourself. That's a project mindset.
How to clean up this mess?
1. Company defines goals (e.g., OKRs)
It's essential to realize that OKRs are not a list of tasks. Their goal is to create focus on what's not urgent yet critical for the business's long-term growth (strategy). Select only one OKR for every team. You can sequence them if needed.
In addition, ask the team to define Key Results. This helps build a stronger commitment and sense of ownership and results in better decisions.
Recommended book: Radical Focus by @cwodtke
2. The Product Trio performs Product Discovery
Learning by delivering is expensive. According to Marty Cagan, at least half of your ideas are simply not going to work. We need Product Discovery, which answers the "WHAT to build."
Instead of building silos with stage gates, embrace a collaborative approach. PM, Designer, and at least one Engineer work together to identify opportunities related to the goal, ideate solutions, and test assumptions by experimenting. Product Discovery results in a validated Product Backlog.
Tips:
- It's a Designer's job, not the Product Manager's, to create user prototypes. She is the expert responsible for Usability.
- The best ideas often come from Engineers. They are the experts who know technology by heart and can tell WHAT's possible.
- PM is responsible for the Value and Viability risks.
Recommended books:
- Inspired by @cagan
- Continuous Discovery Habits by @ttorres
3. Deliver in iterations
While the goal of Product Discovery is to answer the question "WHAT to build," the purpose of Product Delivery is to build it. Those streams should run in parallel.
Recommended articles:
- "Dual Track Development" by @jeffpatton
- "Dual-Track Agile" by @cagan (SVPG)
-
You can find all recommended books, videos, and articles in my free notion collection for PMs: https://t.co/OSJWFLQqJt
What are your thoughts?
Share this tweet if it resonates.
The Product Manager makes $127,902 on average*
But it's extremely difficult to break into right now.
Learn more than 80% of PMs know in 9 weeks (97% of APMs) and land your dream job or keep the existing one: 🧵
*source: glassdoor, US, 2/4/2023
Product management is not about:
- Asking customers about the requirements
- Writing detailed specifications
- Creating prototypes instead of designers
- Instructing developers on what to do
- Verifying and accepting the work of others 🧵
Want to be more active on @LinkedIn but not sure what to post or say?
Just finished creating a 30 day LinkedIn posting plan - simply reply to this tweet and I'll get it to you. ⬇️
Gives you prompts on what to post, examples, and a place to add your own ideas to execute 🔥