Just thinking- Product discovery, planning, predictability and efficiency? hm.
When you get started, naturally you want to solve a very specific problem optimally and differently. That’s clear.
But it’s a step towards a vision, which is the solution to a much bigger problem for one or more personas. And if you could figure out the ingredients and quantities, you may end up with something interesting.
As a product manager, I spend most of my day planning/prioritizing “opportunities” into a roadmap. But there are three other needs to I am concerned with, that are not addressed today. I’d like to propose that a product management tool should consider those as portfolio expansion.
Continuous Discovery- Opportunity/Solution tree
If you’ve been following continuous discovery, product managers ensure incremental value delivery through ongoing exploration of user problems/needs/wants, and ensuring the right solution is delivered. The opportunity/solution tree is the prioritized list of problems the product managers wants to address, which feeds into the backlog.
Interestingly, product management tooling vendors haven’t caught up yet on this topic, at least not that I’m aware, and not at scale. That said, I believe that a tool that will not have CDH support in the next few years will be lacking.
Predictability of delivery
As we get closer to delivery, as a product manager, I want to create communications aligning my users and stakeholders around timeline and expectations. If you think about the last time you’ve gone through that process, it involved some guesswork by the dev lead. There’s no linear way to translate story points into an accurate timeline. Guesswork, with lots of padding, nobody wants to take a hit.
Well, what if you could do a little better with some data-driven statistical analysis?
The Atlassian control chart, for example, lays out the distribution of story lifetime, with an average, standard deviation etc. Could this help increase confidence in the story delivery? probably. Could this aid the dev lead? could this data show up in the product management tool? YES.
Dev team efficiency
One of the ancient discussions between tech and product leaders, and dev teams, is how quickly a team can deliver certain functionality. In the absence of data, you could quickly conclude that the dev lead detects the question mark thrown on their competency as a leader, the discussion quickly becomes emotional and confrontational.
More recently there’s been innovation around collection and analysis of metrics, reflecting common patterns pertaining team efficiency- DORA. For example, a common pattern is to stack a number of commits before deploying to production. A matter of developer confidence, the efficiency of the build pipeline (or lack there of) etc.
A direct outcome of queuing code changes is that, the larger the code change, there’s less visibility into the root cause if something went wrong. If the build fails, it will take time to pull and correct the issue. Even worse, if the change made it to production and caused an outage, now that same timespan to resolve the issue is very expensive. This topic is just scratching the surface of DORA, there’s so much more to it.
Now, for example, a tech leader can guide the team to, for example, make deployments at double the frequency, try to deploy every fewer changes. Create better resolution for each change and, if needed, a faster path for recovery. This discussion now is data driven, not emotional, not personal, and typically raises morale in the team.
How do product managers get involved?
Let’s go back into why the tendency to bundle changes in each deploy- fear and lack of good tooling. Fear that frequent deployments can cause carelessness and increase the number of defects released. Poor tooling- build, test, deploy, can cause delays and poor code coverage. For example, if a common build takes 3 hours and cannot be done in parallel, would you deploy each change or each 50 changes?
Good product managers assist their teams into success. Frequent deployments can take risks with build flags. You deploy something, if it fails, you revert the build flag, reduce risk. Improving the tooling (build, test, deploy) to allow frequent deployments requires investment, that always comes at the cost of application innovation. Investment that returns value in dividends.
There’s one more reason. Frequent deployments of smaller changes drive agility and earlier user engagement, and that’s something good product managers REALLY want.
Good product managers should be aware and take part in the dev team efficiency in an empathetic and supportive way. Imagine the DORA metrics appearing in the product management tool, not only to aid the conversation, but also demonstrate acceleration in response to user needs.
An aligned, informed and supportive product manager is a successful product manager.
As the world of software delivery becomes increasingly continuous, we need to find new ways to optimize our tooling and process, our data and perspective, and the decisions we take.
The vision described here increases the scope of awareness and responsibility for product managers. Which they will need anyway. Let’s put it all in one place, pretty please.
