Now I’ve been working alongside many customer proxy team members (e.g. business analyst, product owner, product manager) over the years. I’ve learned how to create testable, executable, deliverable user stories in a real-world setting. I wasn’t going into this talk blind. I just haven’t always focused on the Product role.

This time, I looked at the role with the mindset of what it would take for me to check all the boxes in the “good” list. As each slide appeared, my list of TODOs lengthened. I started to feel overwhelmed by the number of things I wanted to improve…

“How you doin’, honey?” “Do I have to answer?!?”

I walked out of that talk thinking I’m not sure I want to sign up for this epic journey. The vision of the idyllic end state was more daunting than inspiring. How could I possibly succeed at this enormous task? Would I want to sign up for that? My initial reaction was no! How could I take on all the technical debt of stretching into a new role like Product? How long would the roadmap to “good” take?

Analysis

When I evaluate things off the cuff, I often consider good-bad-indifferent. Maybe knowing what “good” and “bad” look like wasn’t helping me. I knew I didn’t want to be merely “indifferent”… maybe what I really wanted to know was this:

What does a minimum viable product manager look like?

One of my big takeaways from Problem Solving Leadership (PSL) with the late, great Jerry Weinberg was limiting work in process (WIP) or “one thing at a time” (as close to single piece flow as possible) improves effectiveness. If I take that approach to a PO/PM role, I’m afraid that I would completely fail. So I will reduce the practices to as few as I possibly can without completely losing the value of the role. I want only the *critical* path skills or capabilities! Everything else can be delegated or collectively owned or done without. So what can I discard?

In this thought experiment, I’m proposing finding the least possible investment in each essential aspect of the PO/PM role that would move from bad past merely indifferent to viable (but only just!). I needed to reduce my expectations! If I allow minimum viable to rest somewhere in my default scale, then it fits between indifferent and good. That means I deliberately do *not* attempt to inject all of the good practices at once. So let’s revisit the axes of expertise and the lists of behaviors that are good and bad…

Style of leadership

Minimum viable: leads by example (models behaviors for others without trying to modify their behaviors) + doesn’t worry about respect + consultative decisions + experiments/loosely decides + sometimes available to the team but not constantly + flexible + defaults to already available metrics

For me, this one slides a bit too far toward indifferent… I’m not sure how little I could care about customers and still get away with being acceptable at PO/PM…

Relationship with engineers

Minimum viable: physically co-locates when convenient + T-shaped when it comes to the technical domain (i.e. aware but not trying to develop that skill as an individual contributor) + attends standup + shares business/customer/user information at least at the beginning of every epic + champion for the product & trusts everyone on the team to protect their own time

Approach to continuous improvement

Minimum viable: default timebox + takes on at most 1 action item from retrospective, just like everyone else + plans on an ad hoc/as needed basis (pull system) allowing engineers to manage the flow of work to match their productivity + prioritizes necessary work to deliver value regardless of what it’s called (bug, chore, enhancement, etc)

Product lifecycle perspective

Minimum viable: tweaks customer onboarding in a small way to improve each time + cares about whole cross-functional team (agile, DevOps, etc) + asks questions about impact of changes + allows lack of value in an existing feature to bubble up over time

Sourcing backlog items

Minimum viable: occasionally talks to customers + cares about whole cross-functional team (including Support) + backlog is open to whole team to add items that can be prioritized + intake system emerges + tactical prioritization

I do have twinges about the lack of strategy here, so I guess I’m looking at this part of minimum viable Product *Owner* (i.e. the mid-range focus that Richard points out in his 10th slide).

Decomposing work

Minimum viable: progressive elaboration (i.e. I need to know details when it’s near term work and not before) + thin vertical slices and willing to leave “viable” to the next slice in order to get a tracer bullet sooner + trusts the team to monitor the duration of their work & to self-organize to remove dependencies (including modifying story slicing)

Running through a sprint

Minimum viable: doesn’t worry about timeboxes (kanban/flow/continuous/whatever) + focus on outcome of each piece of work (explores delivered value) + releases after acceptance (maybe this is just continuous delivery instead of continuous deployment, depends on business context)

Meeting involvement

Minimum viable: collaborates with team members to plan as needed (small things more often) + participates in retrospectives + ongoing self-study of PO/PM

Approach to roadmap

Minimum viable: priorities segmented by theme + roadmap includes past delivery/recent accomplishments + adjusts communication as needed/updates for new info + flexible timeline in a living document + published roadmap accessible to all stakeholders on self-serve basis

Surveying/user testing – chat program that both team & user can access

Analytics – NPS score informally collected from customer conversation

Product visioning – I think this goes in with Roadmap for me?

So I’ll agree that the PO/PM role is critical and necessary. I would like for creative problem solvers to fill the role – and to be fulfilled by the role! In order for that to be viable, for people to grow into a Product role, there needs to be education on how to begin – and it can’t be spring-fully-formed-from-the-head-of-Zeus! Christening someone PO/PM doesn’t endow them with sudden wisdom and insight. Skill takes time to develop.

Set realistic expectations for beginners. Help teams to welcome people to grow in the role by offering both challenge and support from all the team members. As with any team need, the agile team has collective ownership to solve the problem, not relying on a single point of failure in the role specialist. Having a beginner PO/PM is an excellent time to reinforce that!

If I were a Product Manger, I would definitely prefer to be a full-featured representative of that specialization! However, I encourage you to revisit Richard’s presentation and do your own decomposition of the Product role. What is absolutely essential? What can you do without?

Something is different.
– Good or bad? (Rita)
Anything different is good…
but this could be real good. (Phil)
— Groundhog Day

I’m a relatively young ScrumMaster, so I adopted a retrospective pattern that a colleague suggested to me at the beginning of my tenure. We have been using that same approach for sprint retros for 6 months and it gets the job done. Still, I found myself bored with doing the same old thing for our release retro this month and was concerned about not getting the desired benefit from the process. So I grabbed a promising technique from the Agile Retrospective Resource Wiki called the Four L’s, which Mary Gorman and Ellen Gottesdiener of EGB Consulting developed as a variation of the World Café since they “wanted some variety in eliciting feedback, collectively sharing that feedback and exploring action possibilities.”

The wiki suggests using the Four L’s for “iteration and project retrospectives as well as for retrospection of training and conference events” with a duration of 30 minutes to 2 hours. My 6-member cross-functional team used this technique to reflect on a release and limited our time to an hour, though that wasn’t a hard cutoff. In the context of our release retrospective and the hospitable space of our team meeting room, we gathered our diverse perspectives to explore questions that mattered about how our release went. I titled each of 4 large sticky notes Liked, Learned, Lacked, and Longed For, hanging them side-by-side on a single wall, which was a variation of the suggestion to move around the room. We set a timer of 15 minutes to generate initial feedback for all 4 categories simultaneously and began scribbling madly on uniformly yellow stickies with our Sharpies. Our team ran dry of serious contributions before the time was up, but I think time-boxing activities tends to drive us to get ideas out more quickly.

We read each sticky note’s single idea aloud and then clustered the notes around themes when there was overlap, listening together for patterns and insights. Then, we discussed the whole category among ourselves, hearing out each person’s comments with understanding and humor (we don’t take ourselves too seriously) since we encourage everyone’s contribution to the conversation. We were happy with our technical skills and technologies, but more importantly we have jelled as a team, or made it through the Norming phase of Tuckman’s model. Characteristically, my team identified our successes but did not dwell on them as much as our areas for improvement. We decided we might use the gathered data to satisfy the lacked or longed for items. We posted the following collective discoveries prominently in our team room: