The practical side of Product Management like gardening
You have met Faye before here. She's the seasoned Product Manager (PM), whose story on mentoring more junior PMs introduced a few fairly universally applicable patterns for effectively and sustainably taking care of products, including the metaphor of product management like gardening.
While in both previous posts I have given some insight on what that means and entail, it's always better to get more practical on how that can look like. For that, you need to know about Emily, one of the PMs mentored by Faye.
Emily is a super-sharp and bright young lady, who has grown into product management from the grounds, having started as an analyst in the same product team she now works with, to evolve the products she owns. Emily reached out to Faye because of some challenges she's having with a new tech lead who joined the team recently.
He keeps surprising Emily and the team with sudden technical items that are not known sufficiently upfront. They seem reasonably relevant, so Emily tends to go along, but that imposes challenges because she has to compromise on product adding-value items to accommodate those technical items. In some cases, at the cost of going back to stakeholders with unpleasant news of a likely commitment for the next iteration that gets pushed back somewhat last minute.
Emily is looking for practical guidance from Faye, who after hearing the story, plays it back to confirm understanding with an analogy:
Well, it seems to me that what's going on is that there are two gardeners trying to take care of the same garden, and nothing necessarily wrong with that. But only for as long as both are keeping each other on the loop or better yet, are regularly working together to define next steps, even though there could be some "dividing and conquering".
After some back and forward in tuning what to do next, Emily goes back to the tech lead pitching the patterns that Faye taught her about, and they agree as a next sensible step in the right direction to start by providing visibility: literally combining and listing out all the ideas and demands from all the angles they know about, but also categorizing them into meaningful buckets for the sake of clarity, e.g.:
New product features (structural work)
Improvement to existing features (incremental work)
Other kinds of improvements (processes, non-functional…)
With that, they are also recognizing that it is often foolish to think about priority as stack-ranking when it comes to those different kinds of work. A more powerful idea is to think about that as managing complexity via managing the portfolio and the associated risks. For instance, incremental kinds of improvement are a perfect thing for the team to pull up when they have some slack or are waiting to be unblocked for proceeding with more structural kinds of work. To still keep a focus on finishing work rather than starting, they also decide to define WIP limits while attempting to have a buffer for unplanned work as well.
After doing that for a while, things got more stable and there wasn't a challenge to manage stakeholder's expectations anymore. But as they got into a mode of continuous improvement, they started asking themselves whether they were being strategic enough in prioritizing the technical-linked items. It often felt rather arbitrary, like just being reactive to (technical) debt.
What if we could be more proactive and even avoid (technical) debt as much as possible? And whatever that comes as a matter of time and how things evolve (i.e., couldn't be foreseen), be deliberate about following some principles to deal with it?
Emily and the tech lead make an attempt to articulate that with a short narrative:
First things first, an enabling realization: quality* and speed is not a trade-off; rather the former enables the latter. *Quality is fit for current known purpose.
Then, keep our debts in check, proactively. If we're going to break it (change meaningfully), we might as well rebuild it according to current standards, tech stack and practices. A.k.a., no “cutting corners”, “duck-tapping” or “putting lipstick on a pig”.
And because we are more wrong than we think, we should strive for simplicity. No adding complexity in favor of a (unlikely) possible future. This isn’t the same as “cutting corners”, rather accepting and leveraging the (high-pace) evolving nature of software.
There’s one more thing… Since ‘what we build will own us’, we better excel at change.
While evolving their ways of working, Emily and the team strived for making things transparent. It wasn't always an easy conversation with stakeholders, particularly when they had to consciously put more effort in taking care of underlying conditions to ensure sustainably evolving the products in the long run. Over time though, stakeholders started seeing the advantage, which from their perspective was perceived as clarity, stability and trustworthiness.
You could often hear impromptu comments from stakeholders which would be in the lines of (which included Emily's influence with developing a common language):
They surely know what they are doing, and it's the right thing to do for the product and the organization, that much we can trust. Sometimes we need to slow down to accelerate next, after all: it's a marathon, not a sprint.
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.