Product Manager: An Engineer's Perspective

I recently start an online lesson on Geektime and come across an enlightening lecture from a facebook Product Manager Xiaoyin Qu. This article collects some learning & opinion that I thought useful.

General Responsibility

• The responsibility of product manager is to lead a team to effectively deliver products which match user’s needs.
• Product manager is the owner of a product. They design the product, the roadmap and strategy of the product.
• Impact people, not manage people. A basic requirement of PM is to make other buying in your idea / project.
• Primary work of A great PM is not composing product requirement document. Planing long term strategy, building up a efficient / motivated team, would take a considerable portion of time.
• Product manager vs project manager:
  • Product manager help product team make decision and deliver a product that gain love and trust from users.
  • Project manager help product team to deliver complicated project in limited resources and time.
  • Product manager do the right thing, project manager help do things right.
• Leadership / Communications / Innovation / Execution are four element towards success.

User Requirement

• Product requirement should always stands for users’ interestes and the correctness of existing pain-point. Segway / Block chain / AI for online celebrity are currently something that shines but not solving real problem.
• Pursuing user Requirement:
  • Target user group.
  • Draft some assumption of user pain-points via investigation and data analysis.
  • Deepdive data and feedback to verify the existences of pain-points.
  • Repeat step 2 & 3.
• Don’t try to design something for everyone at first. 100% problems solved for a small but specific user group out weight 50% problem solved for a large group.
• Misunderstanding of targeting:
  • Target only part of target customer group.
  • Target the surface requirement, not the core one.
• The standard user story: As a (xxx), I want to (do yyy something) to help me achieve (zzz goals).
  • xxx is the target user.
  • yyy is the user requirement.
  • zzz is the solved user problem.
• Use case framework
  • Consider entry / reward / architect reuse / example.
• Minimized Valueable Product (MVP)
  • Minimized function means minimized costs.
  • Valueable means solution to problems.
  • “In this proejct, we can modify requirement to make it compatible with current infra structure”. That’s a wise product manager would say for MVP.
• Defining OKR
  • OKR should be concrete enough (including deadline, metrics).
    • “Make user spend more time on App” is not a good metric.
    • “DAU reach 1 million at the end of 2019” is.
  • Identify key metrics. For e-commerce, population of registered user is not critical, population of ordered user is.
  • Take counter metrics into consideration.
  • Rank priorities of multiple OKRs in case we need compromisation.

Basic requirement

Writing PRD

• Describe the problem to solve (in different scenario)
• Identify existence of the problem.
• Design success and counter metrics.
• Explain detail function, including:
  • explaining the entry of the function.
  • a flow chart of function.
  • explaining any current product framework / architecture reuseable?
  • if cross team cooperation needed, deal with it in advance and make notes on PRD.
  • explain fallback strategy (when things goes out of expectation).

Requirement Discussion

• Make a reasonable deadline for decision making. People are tended to be deadline driven.
• Use kickoff meeting to form sub-groups. sub-groups leader take assignments and make it done.
• Plan meeting with an agenda and time arrangment for each item. Stick to it on the meeting.
• Argument could be settled by aligning both sides’ decision making criteria.
• Describe the purpose of meeting at the agenda seal a effective meeting.
• Discuss early and share background so there will be more chances to find an cost effective way to finish a task.
• Let engineer design the product detail is effective. (IMO, it’s true but decision should be broadcasted to PM in case there is missing context.)
• Take responsibility when some effort is wasted.

Time management

• Record 3 most important tasks today before working.

Growth

• Core Formula: Growth = Acquisition + Retention + Resurrection. Refer this formula to setup goal and plan strategy.
• Make sure everyone in team know the growth goal.
• Track every relevant A/B test (hypothesis / engineering progress / traffic portion / test duration / owner)
• Non-positive tests are also treasure for the team.
• Use dashboard / showcase to display core metrics. Monitor metrics.
• PM should train the team to be more conscious on growth.
• Workflow of growth:
  1. defining the metric to improve.
  2. understanding current product.
  3. digging out relavant odds / chances and make hypothesis.
  4. brainstorming solution to the hypothesis.
  5. executing test, find the best solution and release.
• Rules of “Understand, Identify & Execute”
  • Don’t roughly skip “Understand” even we have identified something. Simply identifing solution and starting execution, instead of understanding the whole picture of the product, might be risking of missing the best idea although the current one still bring positive change to the product.
• Make long-term mission statement. Make sure the product stick to it, no matter how aggressive the growth goals are.
• Anti metrics to mission statement are core metrics during growth. Quantitize anti-metrics, missing anti-metrics is also failure.

Execution

• Build up a result driven team, everyone has a clear responsibility boundary.
  • All people know everyone’s responsibility.
  • Working output could be evaluated.
  • If one encounter problems, he should ask for help, and the team should help him solving it. If problems keep blocking progress, report to product manager in-time.
  • Stealing credits are prohibited.
• Control duration of decision making process
  • Not every decision has to be made by everyone
  • Every decision has its own “argue time range”. Length of the range are decided by the importances of the decision. Most important one worth more discussion. For normal decision, conclusion should be made quickly for the sake of execution.
    • To settle argument, such wording might be useful: this decision is not quite important and we don’t have to spend so much time on it. There are still room of later adjustment according to user feedback”
  • Make sure everyone in team know the priority and work according to priority.