Key Points:
- Criticism of SAFE framework – it’s absolute nonsense. Banks and finance companies use this. Recommend to stay away from this.
- Find the best techniques used by the best companies and share them. Over time this builds up a body of knowledge we have at SVPG.
- People want a silver bullet. Something that works every time. None of these things work for every situation though. When is it appropriate or not, that is the question for each technique.
- Don’t recommend OKRs to product teams in most cases, because most teams are feature teams, not actual product teams. You need to have the empowered teams model to make it work. You get a complete mess when applying OKRs to feature teams. OKRs worked at Google because of empowered teams.
- The weak link in most companies is not the engineers or the designers, it’s usually the product manager.
- But I never blame the product manager. It’s really the fault of the managers of those product managers.
- There are so many people trying to tell PMs how to do their job. But they’re basically telling them how to be a project manager. No – that is not the job.
- Marty tries to give guidance based on what the successful teams do.
- Very smart people who know how to get things done. This is what Google originally looked for in PMs.
- APM programs are a good way to coach people. Define what it means to be a competent product manager. Being customer focused is key. The litmus test: your CEO should believe you as a PM know as much about the customer as anybody else in the company. This is critical. If they believe the sales people know more than the PM about the customer, they’re not going to listen to you.
The four most important aspects to the PM role:
1. Deep knowledge of the customer is always first.
Example when Marty was learning as a PM – his superior wouldn’t let him make a single decision until he had visited 30 customers face to face. 15 in the US, 15 in Europe.
2. The PM needs to become an expert in the data that’s generated.
It’s great to have a data analyst on the team. But it’s not enough. The PM needs to be an expert on how the product is used.
3. PM needs to understand your business.
Not your customers business (that’s no.1), but your business. A PM needs to know all aspects of the business. How it generates income, how marketing works, legal issues, ethical issues, etc. The PM really understands your business.
4. Understand your industry.
The trends, the landscape, the competitors.
It’s your managers job to get you competent on these four things before you can really make decisions.
Working remote can be OK. Lots of tools to enable customer testing and interaction. What is challenging is being remote from your engineers. You end up reverting to sending the engineers specs.
The four risks PMs should focus on:
- Value risk: would somebody even buy this product?
- Usability risk: could they figure out how to use this product?
- Feasibility risk: can our engineers figure out how to build this product?
- Viability risk: would this product be legal in the EU (for example)?
When thinking about prototypes, you have to ask which risk is it trying to address?
Empowerment means: who gets to decide?
In a feature team, management decides. The team is really just there to build.
In an empowered team, the team gets to decide.
Consensus model: I hate this model. Everybody has to agree to decide. It comes from people who have a good heart, they want people to feel included. But it goes wrong, I never advocate it.
The opposite end, the dictatorship model. The PM just says I decide. This is no good either.
The middle model is the collaborative model. The person who has the expertise makes the decision. If it’s technical, engineer lead decides. If it’s business viability, the PM decides. If it’s design, the designer decides. And run tests to prove it as much as you can.
An experienced PM can move between different industries. We’ve learned that domain expertise is less important than what people thought. It’s usually much easier to take a PM from a good team, who knows how to do product than to take a domain expert who doesn’t know product. Good product people love to learn new spaces.
There are some domains where the PM will need access to a subject matter expert though. Example of building a product for surgeons, you don’t have to be one yourself, but you need access to them to learn.
The most common reason people leave their job is because of their manager.
Tim Woods 