Them product management links

Been bookmarking and clapping on several posts in Medium lately on product management. Thinking of consolidating them here for future reference.

What it is or what it’s not

• What’s a Proxy Product Owner anyway? by Raphael Alexis
• Agile Development: What is a Product Owner? Roles and Responsibilities? by Lazaro Ibanez

Getting started

• My first year as a full-time multitasking ninja (Or how to kick start your career in product management) by Ada Ubrezi
• How to Break into Product Management — And Grow by Berkay Soyer
• How to Get Into Product Management (And Thrive) by Lenny Lachitsky; with 7.2K claps
• The Six Questions You Should Ask Yourself Before Becoming a Product Manager by David Balsam

Taking care of the backlog

• The Fundamentals of User Stories and Product Backlogs by Nishal Narechania
• Backlog Management: Tips to Make Your Work Backlog Lean by FacileThings

Capability assessment or building

• How to be a GREAT Product Manager by Saeed Khan
• The Product Management Capability Self Assessment by Julian Connor
• How to Assess Product Management Skills and Competencies? by Eleanor Kolossovski

Trials and tribulations

• The dangerous rise of “crazy-busy” product managers by Rian van der Merwe
• The Hard Thing About Complex Products & How I’ve Grown as a PM by Erin Chan
• 15 Things You Should Know About Product Managers by John Cutler; with 6.1K claps

PO anti-patterns

• Product Owner Anti-Patterns by Stefan Wolpers
• Find out these great 20 product owner antipatterns in scrum by Luis Gonçalves

Notes from webinar: Write Better User Stories…

Last week, I attended a free webinar by Mike Cohn of Better User Stories on the topic of “Write Better User Stories in Less Time With Less Aggravation”. Right after, I shared the replay link to some colleagues along with a few bullet points of pros and cons.

(+) interesting, maayos explanation
(+) ok din yung q&a
(+) insightful naman, gives you something to think about, stuff to google further
(-) promotional, the whole course is expensive $395

Posting my notes here since the learning from the webinar is something worth revisiting.

3 Techniques

1. Conduct a quarterly story-writing workshop
2. Split stories to demonstrate progress even if the result is not truly shippable
3. Strive to add just enough detail, just in time

Technique #1: Conduct a quarterly story-writing workshop

• Deliberate, focused meeting
• Brainstorm the stories needed to achieve the period’s most important goal
• Short-term focus causes teams to give in to what’s urgent over what’s important
• Team able to step away from day to day crisis… Without that big goal, the crisis always wins

Focus on a single objective

• “What shall we build?” — Wrong question, too broad, anything is fair game
• PO selects the significant objective (SO)
• SO typically achievable in about 3 months
• MVP, sometimes overused, seems can only be used once
• MMF = Minimum Marketable Feature = subset of overall feature that delivers value when released independently, smaller than MVP

Involve the whole team in writing stories

• Time investment, pays back on time savings when team works on the user stories
• They’ll have fewer questions later, they’ll have more context
• Fewer interruptions to devs’ day
• Devs may come up with better implementation, increased creativity

Visualize user stories with a story map

• Story maps invented by Jeff Patton
• Each card = 1 user story (1 thing the user needs to do)
• Horizontally = sequence of activities (don’t obsess over combination of sequence at this point, some steps may be optional)
• Vertically = alternatives (with most important on top)

Technique #2: Split stories to demonstrate progress even if the result is not truly shippable

• 90% joke – Ask dev how done are you and he replies 90%. Come back after a week, and answer is still 90%.
• Devs are not evil or liars, Estimating how done we are with something is notoriously difficult.
• In Agile, easier, no need to estimate. Just 2 states = Not started or Done
• 5 techniques for splitting stories (Lookup SPIDR), shared in the webinar were Splitting by Interface and by Rules
• When you split stories remember the goal is to be potentially shippable — (1) high quality, (2) tested, (3) what it does, it does well

Technique #3: Strive to add just enough detail, just in time

• Too much detail, too early vs Too little detail, too late
• Bad habit – want to know all before starting — when they do that they’re not doing overlapping work (analysis first, before coding, testing…). Overlapping work is central tenet in most Agile processes (that’s why we don’t have phases in Agile). Time to market gets stretched.
• Err on the side of too little, too late — you can improve by adding more detail next time
• Question 1 (during refinement or other discussions on a user story): Do you need the answer before you start on that story? Sometimes you need it before you finish work on that story, not before you start.
• Question 2 (during retro): Did we get answers just in time in just enough detail?

Reference / links:

• Webinar Sketchnote
• Mike Cohn’s Better User Stories
• Mike Cohn’s Mountain Goat Software (I think I’ve also linked to blog posts from this site at least once in previous posts)
• Webinar Replay Link (would be unavailable after Jul 30 EST but leaving it here just in case the slight chance they forget to put it down)

Reads: On skills for Product Management

This morning’s read tried to capture the job of a PM into 4 words: “Figure out what’s next.” I think in the work we do in building software (regardless of what your role is in your Agile project), we have to do a lot of figuring out. Coming with ideas or solutions independently is so important, and so is working collaboratively to further refine those solutions. Although it’s important to differentiate when it’s collaborating from spoon-feeding or unnecessary hand-holding.

Anyways, the post also enumerates 7 core skills to build for the Product Management role (actual text from the post are in bold, elaborations that follow are mine). But regardless of what role you are in the project, I think these contribute to being a good team player.

1. Taking any problem and being able to develop a strategy to resolve it — When you’re in the business of building software, figuring things out (preferably independently, with little to no hand-holding) is a critical skill.

2. Executing, getting shit done — *in any role, this is valuable*

3. Communication — *same… in any role, you need this*

4. Leadership through influence

5. Making decisions, informed by data

6. Building great products, and having taste — As PM/PO/PPO/BA, you work closely with your designers. I think you also need to brush up on UX so that you don’t undo any of the good work your UX designers present to you for your feedback.

7. Always be prepared — *important for any role* I like the quote the author shared.

[Great PMs] say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seems to dramatically improve overnight.
— Noah Weiss

And I couldn’t agree more with his recommendations for developing your “I got this” aura. Over the years, I’ve worked with a few folks who would sound like they’re so unsure of what they’re doing. It just doesn’t bode well — it doesn’t give the team (or worse, their stakeholders) confidence that they’ll get the work done. I mean it’s OK to admit that you don’t know everything, because no one does — even “experts!” And it happens, I’ve gotten into countless of interactions where I really have no idea on what to do. But I guess my confidence (or my display of not panicking) stems from knowing that I have the capability and means to figure it out. (And that it’s not the end of the world if I don’t.)

So anyways, I’ve rambled on. Go check the post for the recommendations!

Keep the Backlog clean

I just mariekondo’d our backlog. So far, so good, I’ve removed 85 items from the backlog — 53 of which were over 200 days old! My thinking is if we won’t be touching them anytime soon or at all, I want them out of the backlog.

Idk but some lessons to share or possibly reminders to my future self here…

• Get to know your tool – Find out how you can “archive” user stories that you want shelved, and also how you can access the shelved items in the future just in case you need to. Until recently, my options in the tool was limited to either delete or mark as done (which I didn’t want to do for items we won’t actually work on). We then found out that we can do project customization in the tool contrary to what we’ve been initially told, and so I’ve tweaked the workflow to also consider user stories that I want shelved.

• Housekeeping keeps the backlog tool more usable – At some point, it was hard to move things around the backlog because of too many useless items that cluttered the list. Having a lean backlog also makes the items we actually need to work on more visible.

• Maybe it shouldn’t be a list of wishful thinking, or a place for idea dumps – And TIL, using the backlog as a storage of ideas is a Product Backlog Anti-pattern.

• Keep it aligned with the roadmap – Again, (“The product backlog is not reflecting the roadmap.”) another anti-pattern. I guess in conjunction with the previous item, a lot of the user stories that I cleaned up were raw ideas that they had wanted to build “someday”. Keep it real by keeping the backlog items as a list of things the team will actually work on.

• Avoid / minimize duplication – For some reason, if a user story has to be kept duplicated, ensure they are linked to each other. The risk of duplication is in case of refinements, updates might be made on just one of the user stories when in reality you want it to be carried out across all.

• Do periodic cleanups – This clean up is not and should not be a one time thing to keep the backlog relevant. An idea I picked up here is about setting a limit to your Design in Progress (DIP) or the number of items you have in the backlog.

• Be mindful of what you add in the backlog – You don’t want the backlog items to keep growing and growing and revert back to a state you find less desirable. And an idea I picked up here is about setting a limit to your Design in Progress (DIP) or the number of items you have in the backlog.

So there, future me, keep the backlog clean. Keep it useful not only for yourself, but more importantly, for the rest of the team.

One link leads to another

Sometimes I come across posts or material in the internet on topics that piques my interest. It could be something I want to know more or understand more about. Or it could be related to a conversation or two I’ve had within the day that makes me question certain things. So sometimes I google, and sometimes I just stumble upon them through various feeds — could be Twitter, email, Medium, IG, and Facebook even. And then one link leads to another and before I know it, it’s 2AM and I should be getting some sleep. So anyways, here’s a dump of some recent links, in no particular order. I hope someone finds them helpful or interesting as I have.

Agile Product Ownership in a Nutshell (15 minute video) – I like how the content was easy to follow. There were a lot of points worth highlighting, but I guess what hits home the most is the mention of three things that need to be balanced:

• Build the right thing (PO tends to focus here)
• Build the thing right (dev team)
• Build it fast (SM or Agile coach)

So you want to be a Scrum Master (book) – This is a Leanpub book which you can get for free, or not if you can afford to make a payment / contribution. It’s written by an Agile community of interest with the intent of sharing what they’ve learned and what they’ve seen to have worked.

The 3 most effective ways to build trust as a leader (post/article) – Got this from Rob Lambert but I can’t remember where exactly — “Three typical management activities that get poor results and three that get good results”. I’m not really a leader by title but the three ways of building trust that the post enumerates are still relevant to me and they emphasize points that I value: Empathy, clarity of intent, and follow through.

DISC Profile Types (personality test) – This is something I picked up from Rob Lambert’s webinar. For each profile type, there are recommended ways on how to better communicate with them, and inversely there are recommended ways on how to encourage others to better communicate with you. Took the test myself and got 48% Compliance, then Dominance, Steadiness, and lastly Influence.

12 common mistakes made when using Story Points (post/article) – This reminded me of something a colleague had shared wherein their Scrum Master wants them to estimate in hours rather than in story points, and also her thinking that story points can be easily translated to hours.

Agile Makes No Sense (post/article) – Let me just quote some lines (actually last 2 paragraphs) that I liked…

What is the smallest thing that could add value (and make sense)? A better standup? A better retrospective? Inviting a customer to a demo? Pairing for a day? Agreeing to get something into product in a couple days? Try that. Make one thing make sense as in “wow, I can see how that created value”.

When you take this humble approach — instead of “installing” a bunch of artifacts, tools, roles, and rituals AKA doing Agile — I think you’re embracing the true spirit of Agile.

How our team “does Agile”

Super quick background: Our project started Jan 2015. To kick things off on the Agile methodology, our Scrum master conducted a brief training (less than half a day) to the team, and we’ve been playing it by ear ever since.

Over the course of many sprints, retros and releases, we’ve made adjustments on how we’re doing Agile. I’m not sure if there are Agile Purists who would frown down and shake their heads at us for the variations we’ve made. But the thing is, despite our possibly non-canon approaches, what still matters most is the team closely working together to deliver working software.

This post might be TL;DR. But in case you’re still interested in having a peek at how our little team does Agile Scrum, go on and have a read…