Day 2 – #OneWeekPM

This was a pretty interesting lesson. The key takeaway for today was a better understanding of Agile Development Methodologies (always a key requirement in any PM Job Description). This was a new section that was added to the course. It was fun seeing Kevin, the designer of the course, iterate on his product and continuously improve on it.

Agile Development Methodologies

  1. Scrum
    • Teams run sprints (short blocks of time allocated to work on specific features)
    • Daily standup involved to communicate to team and identify blockers
    • Quite a bit of planning/meetings involved – Product Prioritization > Sprint Planning > Actual Sprint > Retrospectives
    • Allows you to forecast things like workload, product/feature completion
  2. Kanban
    • Less structure/more flexible than Scrum
    • Operates on a basic TODO list concept where there are 3 sections – To Do, In Progress, Done
    • More autonomy as developers choose which bits to work on themselves
    • Doesn’t make it easy to forecast completion of features/workload

Working in Cross Functional Teams:

Communicate, communicate, communicate. That was the main takeaway from this section. A product manager manages not through power, but through influencing and consensus therefore it is important to build trust with the various teams that are part of the product development process (i.e. Engineers, Designers, Sales & Marketing).

Another takeaway is the importance of being concise. No one has time to read novel-like emails, or listen to a long drawn out explanation. Enough said.

The main topic for Day 2 was User Personas. What were they for and how do you create them?

  1. Conduct user interviews – During these interviews, stay away from leading questions! PMs are there to listen and understand thoroughly the types of problems the user is facing and what alternatives have they tried. (Note: If a person says it’s a problem but hasn’t tried any alternative solutions, that problem really isn’t a big one)
  2. Creating User Personas and prioritising the ones that you want to build for – Common mistake is to listen to every piece of feedback and build all of them. Nothing good comes from trying to please everyone. Identify the top persona that you want to build for and focus on that. Delighting that one user persona will inadvertently result in other personas having their needs met as well.

As with the first day, there was an exercise. Conduct 3-5 User interviews and craft a user persona for the problem that you’re trying to solve. Can’t do this right now so will update when done.

Update 11/4/15:

Here’s a sample User Persona that I crafted based on a product that we we’re trying to build out at work:

User Persona Exercise – OneWeekPM