MAY 2019CIOAPPLICATIONSEUROPE.COM8IN MYOPINIONhe Big Bang was a bit like your typical startup. A massive amount of creative energy went in, and each was novel in its own way. But like the universe, startups grow, cool down, and spread out. They become very different, for better and worse.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 PhenomenaCompeting 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.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" SyndromeDo 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 Product RedshiftTTHOMAS BRADFORD, DIRECTOR OF ENGINEERING, BLACKLANEThomas Bradford
< Page 7 | Page 9 >