Learnings as a Product Manager
A product manager is very less of a manager. As a PM you have no authority to tell somebody what to do or what to work on. The role is to empower and steer your team towards a positive outcome.
You can’t decide without understanding something completely. So ask questions and get things clarified. As a product owner understanding why things are the way they are and by questioning the reasoning behind everything allows you to take informed decisions.
Being proactive is one of the key qualities in product management. When you are into product management, you act as a mediator between different teams, so the sooner you take initiative, the sooner others can get their work done.
Being a mediator means your work becomes less orthogonal with others and more people start waiting for you to complete so that they can proceed. So complete things right away rather that putting it off for later.
One of the important tasks in product management is managing risk. What worse than a feature that fails, is a feature that you wish never shipped. As rightly said shipping is a one way street. Its is very hard to take back things once released.
By being a person who drives the product direction you are exposed to hearing a lot of feedback, new ideas, features and changes. But remember that you are responsible for every feature you put in your product. You better have a reason for why it’s there in the first place. Don’t just ship features because you have enough bandwidth.
You would have attended meetings where everyone agrees for a change but when you ask why have we gathered here, no one seems to have a clear definition of the exact benefits the change would bring. These are clear indications of risky features.
One way to deal with these situations is to always have a couple of low risk items on hand and push these risky ones for later which would buy you some time to do your research, understand the exact the demand side struggle and come back with a solution that clearly depicts how it would provide better results in a particular situation where users are struggling right now.
There can be situations when you have a lot of uncertainties associated with the project you are working on. This is one of the reasons why you are hired for. It is your responsibility to bring clarity on the table.
Guide your stakeholders and help them in figuring out what to build. Every stakeholder has their own perspective of what’s valuable and everyone has different expectations of what they are going to get in the next release. Its your job to dissolve this ambiguity and keep everyone on the same boat.
Its easy to get attached to solutions and jump straight at building them. But if you think about it, solutions are cheap. So focus more on figuring out if you are solving the right problem instead of acquiring more resources to build out the solution.
Invest more in identifying the current situation where your users are struggling, instead of working backwards from a solution to the problem.
Anyone who does product design has to switch between looking at the world from two different perspectives - Demand(what people want from the product) and Supply(features to be built).
Many times when we think we’ve identified demand, what we have really identified is just supply-side thinking. Next time when you sit for customer interviews or in a backlog grooming session listen closely for the problems and be skeptical about the solutions.
If you aren’t investing in identifying what the true demand is, then it’s really not any different from having somebody who is higher up in the company walking in and saying, I wan’t you guys to build this, like this.
Designers and product managers are usually considered as the wise ones in the room who always have answers to customer problems at their fingertips. And when you say I don’t know people look at you in a strange way. But product design is not about knowing the right answers. It’s about finding them.
So the next time you’re asked a question that cannot — or shouldn’t — be answered, just say: I don’t know. But make sure you go back and find the answer.
When you have an issue in the project it is easy to chose to be ostriches emulating the famed Ostrich behavior of dunking heads in the sand. If I can’t see the problem, the problem will disappear. This will take you no where.
When you have a blocker in the project you are working on, don’t just give up and call it done. Work with your team and find out a way to reduce the scope. Look for ways to solve a problem with whatever you little you have available.
Stick with your design process it will take you a long way, don’t skip it. Design thinking framework combines the problem-solving roots of design with deep empathy for the user. More than just empathy the framework encourages you to move through product iterations at a design level, saving engineering time. In this way you get to learn, solve disagreements and test hypotheses quickly even before you launch.
It can be hard to employ the tradition waterfall approach to design in agile sprints. One good solution I’ve found is to use the time boxed activities from design sprint. You can read more about this here.
There is no go to strategy for setting up analytics. Every time I talk with another product manager what I have come to realize is that collecting and analyzing data is still experimental. Its hard to decide what to measure and how. But just because it hard, don’t skip this.
Constantly keep looking for tools that helps you measuring value and find out how helpful your product/feature is. Make hypotheses, validate them and see how they affect your users.
With data there are so many variables that can into play. Even simple things like your founder attending a conference abroad, tweet from you customer, issues/bugs etc can easily skew the data and make it difficult to understand what is happening.
When you take decisions based on data, know what the data exactly means. Making decisions on incorrect data and false assumptions is worse than deciding on a healthy gut feeling.
You should have regular O3 meetings not just with your line manager but with everyone you work with. By having one-to-ones, you can receive & give feedback to catch possible issues early. Use these meetings to decide together on how your day to day work can be improved.
The goal is to listen more and talk less. One of the strategies to keep the discussions in these meeting going well is what I call the RIC(Remove, Improve, Create) framework.
- Remove - Things that can be removed from the current process
- Improve - Things that can be improved in the current process
- Create - New things that can be added to make it better