For those of you who don’t know, @cindyfsolomon and Adrienne run a weekly Product Management Twitter Talk. We invite notable Product Management professionals to lead and join discussions that hopefully enlighten and delight.
This is a summary of the 6th Product Management Twitter Talk held on 22 March 2011 (Sydney date).
This week’s topic on Agile vs Waterfall was led by Mark Mansour, founder of Agile Bench whose knowledge of Agile is deep, his opinions sensible and his practices pragmatic.
Mark’s first question to the group was “Product Manager, Agile Product Owner, what’s the difference?”
- agilebench: Product Manager and Product Owner are two roles, sometimes occupied by the same person. Product Managers are outward (customer) facing. Channel, brand, price, the whole product.Strategic. Product Owners are inward (project) facing. Delivery, detail, focused. Tactical.
A product owners role is so intensive that they need to be in the project *all* the time.
In larger, more mature organisations, Ive seen product owner role described as a “producer”.
When the Product Manager isn’t the Product Owner they need to have dedicated time to make sure they remain in sync.
- cindyfsolomon: Product Owner tactical & works for agile team, where as the Product Manager is more the
leader and director of roadmap.
- rcauvin: One model is that Product Management is more market facing, while Product Owner is more inward
- jenniphermarie: If you do agile and have Product Managers, they should be the Product Owners.
- bill_bliss: The danger of not being a Product Owner is that if you aren’t careful you can disassociate yourself from the scrum process entirely.
- roadmapwarrior: It’s easier if you have a Technical Product Manager be part of the daily standups instead of a Product Strategist or all-around Product Manager.
- sehlhorst: With a good Product Owner, Product Management should consider attending weekly scrums instead of daily.
Question 2: “Where there are many Product Managers on single project, how do each get product objectives delivered
within the project?”
- macmyday: Never came across this scenario, but would think that you would split up the product into functions & each Product Manager looks after 1.
- wapolanco: Not just divide deliverables but also hone functions based on skillsets.
We skilled Question 3.
Question 4: “When are agile delivery methods not appropriate for Product Management?”
- bill_blass: One challenge of agile is in really big projects with new products, a re-architecture, etc. You can still be agile but it’s different.
- agilebench: The shape definitely changes as you scale up your project and your organisation.
- wapolanco: If cust wants deep, detailed documentation for every step, phase or deliverable agile may be ineffective.
- roadmapwarrior: Not sure there’s officially a time when agile isn’t appropriate, but it can get tricky, especially in
- jenniphermarie: Waterfall comes from the industrial age where you have something like a TV to build.
- KirstenLester: Product Management is the constant disciple for the vision and the product. Always speak as
Question 5: “How do Product Managers ensure the vision when agile delivery teams are focused on small pieces of work?”
- rcauvin: Employ versions of epics (large user stories) to ensure team doesn’t lose sight of vision. Don’t divide into small stories. Strive to keep stories end to end, but incrementally flesh them out. Epics preserve the big picture, the end-to-end goals, functionality, and acceptance criteria. Iterate on versions of them. Don’t need to break up into stories. Can employ *versions* of epics instead. Epics are quite manageable if you incrementally & strategically strengthen the acceptance criteria over iterations.
- roadmapwarrior: Make sure to TELL THE DEVS the long-term vision & make each small piece something that
- agilebench: Agile method does not have a great framework for ensuring the whole product doesn’t look like a picasso. Prod Managers are a bit like sherpas for the delivery team in keeping their focus
- bill_bliss: Agile can be a way of building “leaves” very quickly but if you don’t know you’re building a tree or a
bush, what’s the use? The epic (or something even larger perhaps) defines whether it’s a bush or a tree.
- sehlhorst: Slicing epics into stories is an art. Key idea – each slice must have value for someone.
Question 6: “If it all needs to be done why does it need to be prioritised?”
- sehlhorst: Prioritize because ‘it all needs to be done’ is always actually wrong. Some stuff isn’t needed, some missed stuff is.
- rcauvin: Because our knowledge of what needs to be done changes as we iteratively make.
- agilebench: Things change. Requirements are discovered, requirements are fleshed out, budgets get cut, staff members leave.
- bill_bliss: I blogged about that recently. Ex: you need food AND water AND air, but you can prioritize between them if you have to. Also, get the harder stuff out of the way first, the de-stabilizing stuff, the stuff with tricky user interfaces & requirements.
- macmyday: Priotitisation determines what is most important & can hightlight dependencies. Get one thing done really well rather than everything ‘half-baked’.
- thefairdesmondo: Just enough, just in time. If we tried to include everything, the product would never ship.
- wapolanco: If building a house you can’t install windows before foundation, external and internal walls, electric, etc. Priorities are crucial.
During the discussion, the group also talked about Product Management gaining respect from the development team. Not only do Product Managers have to be market focused, some said that we have to possess technical skills to gain the respect of developers.
- wapolanco: Respect comes from knowledge and expertise. Know the market, the product and your customer and effectively communicate it.
- bill_bliss: If you aren’t seeing as adding value, you won’t be respected OR included. That’s the tricky bit.
I think tech skills really helps with empathy actually. If you can really understand their challenges that’s a big help.
- sehlhorst: Respect is also earned when it is given.
- thefairdesmondo: Being able to discuss with development team at a reasonable technical level adds to
respect. Market focus is most important, but technical understanding helps them to ‘swallow the medicine’.
Product Management Talk is the fastest hour of the week. Its a great, effective way to keep your Product Management skills sharp.
Join us every Tuesday 9 AM Sydney time. Use Tweetchat and the hastag #prodmgmttalk. Its that simple!