- Will talk about the most common mistakes that companies make when they move to this new model of product.
- At SVPG we like to share how good teams do good products.
Most Common Problems
Thinking your job is product owner rather than product manager
- The average skill level of PMs over the last few years has dropped.
- Most companies have moved to agile, but they knew they needed product owners for this. So they took project managers and business analysts and made them product owners. They then trained them on a scrum certification.
- But becoming a product owner does not make you a product manager. That is the biggest problem I see today.
- A product owner is an administrative job, not a product manager job.
- The PM should also be a PO for the team. The PO part is about 10% of the job. It’s a small part.
- The biggest issue I see out there is when a PO has been trained as a PO, and think they are a PM.
You need to be trained as a product manager
- The best way to be trained as a PM is to work with a proven PM. Somebody who has been there and done it, and committed to coaching you. It’s the best way. It takes 1-2 years to build the skills to be a strong product person.
- The tech industry has grown so fast, that many of the managers have no idea how product should be done.
- This is the problem so many companies have: not having the right PMs.
Table stakes for a PM
- Deep knowledge of your user and customer
- Deep knowledge of the data customers generate
- Deep knowledge of your business
- Deep knowledge of your industry
On data aspects
- User analytics to see what users are actually doing
- Sales data
- Data warehouse to see data changes over time
- These three things give the PM a picture on the customers and the state of the product
- A data analyst might be there to help, but the PM needs to know it themselves
Not tackling risks upfront
- This is the heart of how we do modern product
- We need to discovery a solution that is valuable, usable, feasible and viable (PM and design is responsible)
- we need to deliver a solution that is reliable, scalable, performant and maintainable (engineering is responsible)
- The model below is not a process, but a conceptual model.
Not thinking enough about ethical risks
- A lot of concern about this in Europe right now, and also in San Francisco.
- Think about Uber. Every morning thousands of Uber cars flood into the city and make things worse for travel.
- We can build it, but should we build it? PMs need to start thinking more about this.
Gathering or defining “requirements”
- A lot of issues we have in our industry today comes from the legacy of how it’s been done before, in industries like big banks.
- If you think your job as a PM is to gather or define requirements, it’s not. This is at the core of the difference now.
- The way we solve problems today is collaboration: between PM, design, engineers.
- So many key products we admire today have come from engineers understanding the customer problem and bringing the perspective of what is now possible with the tech to solve those problems.
- If you think your job is to define requirements, you really want to rethink your job.
- You have to describe problems that need to be solved. You have to show your designers and engineers your customers pain.
- But the solutions come from the give and take of the three roles.
Shipping features rather than solving problems
- Releases aren’t even a thing anymore, we release with continuous delivery, possibly many times a day.
- The purpose of the team is to solve problems in ways that our customers love, yet work for the business. This is really the only requirement we have.
Acting as “Gatekeeper”
- The team views themselves as the gatekeeper for all of the ideas coming in from stakeholders.
- Instead of fending off all of the ideas that don’t work, your job is to understand the problems and try to solve them for the customer and the business, not just spend your time validating ideas from stakeholders.
Not considering alternative solutions or approaches
- A team will get excited about a particular approach, and spend too much time just on that one way of solving the problem.
- Should be testing 15-30 ideas a week. Lots of ways to do that.
Spending most of your time on value capture rather than on value creation activities
- Both of these activities are good.
- Value capture is optimisation work, and tweaking pricing.
- Value creation is expanding into new markets, or tackling new problems.
- Meet so many teams that are just going after the low value tweaks, for small gains. You should do this, but it’s really the easy work that goes on in the background. The majority of your work should be on value creation.
- Apple: make sure you are always creating more value than you are capturing.
- Those companies focusing on value capture are scared, they are fearful of taking risks. Optimisation is avoiding risks.
- Discovery is all about taking risks, but doing it in a smart way.
Not spending most of your time prototyping
- Teams spend too much time on prioritisation, and it’s usually thinking about things we cannot know, like how much money it will make – we just don’t know at this point.
- Stop worrying about prioritisation and start trying out a lot more ideas.
- We should be trying out 50-100 ideas a month. This sounds a lot but it is not hard if you just use modern prototyping techniques.
Not leveraging both qualitative and quantitative learning
- Apple and Google are doing both of these all the time, even though you might think Google is well known for quantitative and Apple for qualitative. You need to do both to answer different questions.
Not managing your time / playing project manager not product manager
- To really do this job well, it takes about four hours a day. This is really working on the problems, working with designers or engineers, testing ideas with customers or stakeholders.
- Getting those four hours is really tough for many PMs, because they feel they also have to play project manager.
- You can do both parts of the job. Know many who do this. But those people often have to get their four hours in after hours.
- PMs often feel this need to be there when anybody is talking about their product – but really you don’t. Try to get past that.
- When coaching PMs, tell them they must get these four hours in. It still leaves some time for all the other stuff, like meetings and project management type work. But the product work must come first. You have to coach the mindset.
- Jeff Bezos: you want to hire people that think like owners, not like employees. That’s a mindset thing.
Just to be clear, all teams should be running some form of agile as a minimum. But if you’re running SAFe, that is not what I mean, none of this is relevant if that is what you’re using.
Tim Woods 