The majority of optimal product manager activities depends entirely on the maturity and nature of the product. Product managers should be acutely sensitive to the precise circumstances of their product and act accordingly. While there are some common threads, this leads to a very wide range of day-to-day activities. What you should definitely not do is follow a fixed recipe.
I’ve explained a few examples of how the phase of your product should dictate your activities day-to-day.
1. You’re developing a new product with a hypothesis that is yet to be tested. All your activities should be focused on validating or invalidating the hypothesis as quickly and cheaply as possible.
What you should be doing:
- Working on a framework for judging the success or failure of the product. There are many forks in the road you’ll have to navigate such as deciding whether the best feedback mechanism is qualitative or quantitative and figuring the right people to expose your product to. You may end up with nontraditional metrics or feedback mechanisms.
- Designing the minimal viable product (MVP) necessary to test the product hypothesis. Different types of products require different dimensions to be fleshed out (design, functionality, etc..). You need to decide the minimum set of work necessary for learning.
- Ruthlessly prioritizing feature development. You must keep the engineering team working only on the features required to test the MVP. Everything else is waste.
What you should not be doing:
- Optimization. In this stage, who cares if you can increase click through by 5%? You’re trying to decide first whether your company should invest a ton of money in this direction.
- Guiding the engineering team through major architecture decisions. Anything you think you know about the product is wrong.
- Allowing the development team’s focus to become fragmented. Your company’s management team may become impatient waiting for your results. It’s your job to keep the development team insulated from management thrashing until the results of your experiments are clear.
2. The product hypothesis has been validated — it’s time to scale. When your key metrics are going up and to the right, your day-to-day activities will radically change.
What you should be doing:
- Optimization. From the first phase, your company should know at this point how to measure its engine (if this isn’t case, making it so should be your top priority). So while the engine is working well enough to show promise, you should squeeze every bit of value from it though becoming obsessed with web analytics and user feedback. Develop ways to quickly test your product quantitatively (e.g., A/B testing) and qualitatively (e.g., user testing). Work with your engineering team to make optimization activities increasingly fast and cheap.
- Fostering growth. If your product has been validated, you must already have proven there is a way to get more customers into the system. You need to experiment with ways to get even more people in and get more of them coming back. Depending on your product, this can lead down roads ranging from SEO, email marketing, to devising push notifications.
What you should not be doing:
- Redesigning with no clear hypothesis. Don’t let your new boss instigate a redesign just to put his/her stamp on the product. Everything you should be doing should be to maximize learning without taking on needless risk.
- Neglecting the fundamentals. Don’t let everything you’ve worked for fall apart by releasing catastrophic bugs or hosing site performance.
3. Your product hypotheses has failed — you must lead the company through formulating the next hypothesis to test. The scenarios above have an emphasis on execution. This phase, however, is different in that you’ll be more focused working sideways, upwards, and outwards.
What you should be doing:
- Structuring the company’s narrative around product failures. There is potential for your company to react irrationally in the scenario where a product hypothesis was invalidated, throwing out the baby with the bath water, so to speak. It’s your job to structure your company’s understanding of what happened and how the acquired knowledge can be applied systematically in identifying the next hypotheses to test.
- Identifying opportunities that fit your company and the market. With each product hypotheses tested, the nature of your company will increasingly emerge. What are the team’s collective strengths and passions? What components of the software show the most intriguing potential? What is the true mission of the company that binds everyone and everything together? Your job is to articulate answers to these questions and match them against understanding of opportunities in the market.
What you should not being doing:
- Allowing energy to go into the failed direction. If your company has decided to change directions, make sure that this decision is reflected decisively in how the development team’s efforts are spent.
- Allowing a pivot to take place that is too severe. You should prevent the ‘throwing the baby out with the bath water’ scenario. You should recognize the value in the company’s current knowledge and capabilities and guide management away from choosing a direction the doesn’t leverage what has been accomplished.
- Blocking a product pivot based on emotional attachment to previous development. While you don’t want to allow the company to needlessly throw away assets, it can be challenging to not become overly attached to things you have previously worked and try to force product direction around them. You must stay disciplined and recognize when it’s time to say goodbye to some things you poured your passion into.
But throughout all this variability, there are some activities that a product manager should always be doing.
- Maintain ownership of the product vision and roadmap. Depending on your place in the company organization, your ability to dictate the product vision may vary. But you should always have deep understanding of the company’s rationale for the current direction. You need to know why things are being done the way they are. Staying on top of this is a constant, daily activity.
- Improving the product development process. It will always be impossible to know in advance exactly what completing a significant iteration will entail, but there is always room, as a development team, to improve in breaking up and scoping complex projects. This takes time and requires the team to maintain steady focus on collective self analysis. So while your first several product hypotheses may fail, your team should get increasingly efficient in testing each new hypotheses.
- Connect. You are the diplomat and translator that holds together all team members and stake holders of your product. It is a daily activity to master everyone’s language and objectives while keeping the train speeding ahead.
This post appeared originally on Quora.
Product Logic 