product-management

Recently, there’s been talk in my organisation of shaping a new function to own an end-to-end user journey that is currently spread across multiple teams. It’s broadly considered a good option. The problem is clear enough; a slow, fragmented oexperience that’s kind of designed around multiple policies owned by different teams. So users essentially have to navigate the internal org chart as they move through the product. They have to deal with four or five different teams, each owning a different slice, with no single person responsible for how the slices connect.

One of the most useful things I’ve learned in product is that it;s not always yes/no; not every strong opinion needs to be either accepted or resisted outright. Sometimes what’s really needed is to faciliate a space to explore the opinion safely — to understand what’s behind it, and whether it holds up when you bring it closer to users and outcomes.

When joining a new team or having a new product to manage, you want to get up to speed quickly and be able to start creating impact. I’ve found that by embracing vulnerability and learning by doing I have been able to navigate multiple new domains throughout my career and become the go-to person for the product.

Kotahi is a peer review platform in the Coko ecosystem. When I joined the team there was a well scoped set of project milestones and a large backlog for delivery. This is a good approach when you are working to specific, well scoped deliverables and you know the capacity you will have in the team for the work, but the world doesn’t stop turning when you have outlined all your outputs.

The product management lifecycle is typically visualised as a loop of activities that take place in broad areas of Discovery and Delivery.

One of the most challenging balancing acts in Product Management is maintaining product quality while still being focused on delivering value. The question of “what do we do about this bug?” can create tension in outcome focussed teams. If you are working towards driving a particular metric or goal, should bug fixes be prioritised over achieving that goal?