A lot of people have asked me what my job is. I gave this talk at Maker's Academy in London to a group of student devs who wouldn't have been exposed to the concept of the role prior to having to go out and get a job.
15. Pivotal Labs Confidential
IPMs
Review unfinished stories in
current sprint
State goals for next sprint
Review stories
Estimate*
*Lots of different ways to do this
Everyone is in the room
16. Stories
As a _______ I want to ______
because ______.
Requirements in Gherkin
Acceptance criteria
Design Mock-Ups
17. Team Culture
Kent Beck taught us in Extreme Programming that:
Courage to speak truths pleasant or unpleasant fosters
communication and trust
Courage to discard failing solutions and seek new ones
encourages simplicity
Courage to seek real concrete answers creates feedback
These are the challenges PMs face
Pivotal Labs Confidential
18. Some things PMs are Not
Your Mom
Your Secretary
A Fascist Dictator
A Superhero
We are the Glue.
. A lot of people hear me say Product manager and then repeat it as project manager.
The two are not the same thing and I’ll try to illustrate why:
Project Managers’ priority is to deliver as much of the states business requirements as possible within the states time and budget constraints.
Product Managers main concern is delivering the right set of features in the correct order in order to maxmize understanding, which leads to greater business value.
We sit at the apex of a lot of different groups, and we care about each group a lot.
Because of this, PMs can come from a lot of different backgrounds.
Some are a lot more technical, some come from UX/Designer backgrounds, some are domain experts in a specific field, etc.
We are a neutral force between all of these groups, or as some call it, the scales of justice.
We bring together information from each one of those stakeholder groups and merge it into the overall vision.
One of the pitfalls of Pming is getting too close to any one group. I often make the mistake of advocating too much for my user. Case Commons story.
There are a lot of potholes, gullies, canyons, hurdles, rivers, when developing products.
PMs are here to pave the way, build bridges, smooth down rough edges so that others can do their job as effectively and quickly as possible.
It’s our job to both write stuff on a page, and then get everyone on that same page.
Occassionally it’s a process not unlike a séance. But you do what you can.
Sometimes business can be very attached to a specific idea
Sometimes designers really want to create an offline experience to augment the product
Sometimes devs really like the idea of creating a totally automated system that doesn’t need human input (this is happening to me now)
It’s my job to find the risks, explore costs, talk to users, and then make sure everyone knows the potential outcomes of certain courses of action.
We are the telescope.
We watch where the product is going in long view, while trying to stay firmly planted in where we are today.
We have to release VIABLE software as quickly and as often as we can
I’ve worked with some devs who have a hard time with this concept.
The YOU AIN’T GOING TO NEED IT concept. In certain cases it works better than others. But getting stuff in front of REAL users in as REAL situation as possible is imperative.
That means you need a fully realized product that lets someone accomplish something. MVP
- Be able to articulate why we are doing what we are doing