A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.
Blacklane
Product Redshift
As the universe expands, the enormous energy that was concentrated becomes diffused and diluted. Novel mass-creation events like the Big Bang are replaced by more local, incremental, and less dramatic events, such as the birth of a star. While impressive, we’re not creating universes anymore.
As an organization grows, we observe similar dilution in creative energy. We increment slowly, we optimize conversion, and we tweak. But the creative process mostly stalls. We become satisfied with breeding a better horse to till our fields, rather than invent the tractor.
Observing the Phenomena
Competing theories diverge about the fate of the universe. One assumes that its internal gravity will reverse the outward acceleration and eventually a big crunch will set the stage for repeated mass-creation events.
A competing theory says the universe will expand forever, becoming colder and darker until we no longer see the stars, and there will be nothing left to wish upon.
The first theory sounds better -- less depressing. So what are some actions we can take to set up our product universe for repeated mass-creation events?
Throw away your Backlogs!
How many product backlogs do we have? Is there one for each team? Is our organization growing in such a way that we split teams so each can take some sub-portion of the product? How soon will we have to split them again?
As soon as we split a product into multiple backlogs, we declare that we don’t know how to manage our product properly. If we’re genuinely introducing a new product, then, by all means, we should create a new backlog. Otherwise, it’s a process smell rather than an intelligent strategic decision.
When it comes to KPIs, we’re looking for major improvement at the end of the pipeline, where costs and negative effects of the previous KPIs are fully considered
We craft backlogs only to find that emerging requirements and customer feedback deprioritize much of that work. So why did we bother when our customers told us what they need?
Throw away the backlog! If we don’t think we’ll get to it in six months, we’ll likely never get to it. Every story we only ‘think’ we have to deliver is a story that keeps us from collaborating with other teams on the big stuff. It keeps us from listening to our customers. It’s a story that adds to our escape velocity.
Dealing with “My Team” Syndrome
Do we refer to the developers we work with as “my team” and mean it? When we treat a team as our personal black box of work, the dynamics shift from the product manager working hard to establish shared understanding to the rest of the team working hard to understand the product manager.
Are developers breaking down epics into user stories for us? Are they missing stakeholder meetings because we’re the only one who needs to understand stakeholders’ desires? Are we swooping in at the end of the sprint, pointing out where developers screwed up and complaining about their velocity?
Divorcing us from “my team” is one way. If we can’t change how we feel about our role, the next best thing would be to extricate ourselves from development teams altogether, severing the affinity between a single team and a single product manager, and thus a single product fragment. Thereafter, development teams will choose projects whose value is best communicated, requiring us to change our approach and “up our game.” If we are peddling work that lacks value, clarity, and purpose, we either have to learn how to do that or to coalesce our efforts into larger projects that are capable of doing so.
KPI Cannibalization
How familiar are we with other teams’ KPIs? Familiar enough to care about them? Do we judge our team’s success only against our own KPIs or do we seek to influence shared, aggregated, or north star KPIs positively? Do we understand how improving our KPIs might negatively affect the KPIs of other teams or the organization as a whole?
When it comes to KPIs, we’re looking for major improvement at the end of the pipeline, where costs and negative effects of the previous KPIs are fully considered. We also want to avoid prematurely optimizing KPIs that may act as inhibiting factors for subsequent improvements. Therefore, earlier KPIs must act as multipliers for later ones, and they must be measured based on their benefit to the whole rather than as a local optimum or cost reduction. Product redshift competes with these goals because every ‘product’ is treated as an independent stream rather than as a potentially beneficial tributary to the overall river.
What’s getting in the way of our organizational gravity? What’s keeping us from engaging in deeper collaboration? Is it compartmentalization? Is it processes introduced primarily for the sake of enforcing rigid hand-offs? Is it overly-defined roles and responsibilities that allow individuals and teams to claim “not my job” easily or to shift blame to others? Is the ground beneath our feet composed of excuses and designed to cover our own backs? If we want to defeat product redshift, we need to identify those things that are holding us back and promptly demolish them. .
