#product

Teams can tackle increasingly ambitious initiatives if they learn to challenge risky assumptions with proofs-of-concept, research, and other forms of experimentation.

A common anti-pattern in the world of software development is the over-operationalisation of the research and development process. In moving away from traditional ways of working, companies will spin up long-lived teams, working to sprint cycles, but still find a way to cram an inordinate amount of upfront planning into the system, causing a significant amount of waste. This can feel like a big step in the right direction but often comes with very little benefits compared to the old way of working, as the way the team works doesn’t change.

A playbook I’ve used to describe the responsibilities of a software engineer for hiring and professional development purposes.

To make effective decisions when developing products, engagement with customers is critical. Building this into your way of working should be the priority of any product leadership. Along the way, data should be captured and analysed.

Product Manager might be the least standardised role in startups. Across different org profiles (e.g., startup, scale up, corp tech, big tech), PMs do very different things. Even within those profiles, the PM role can be incredibly diverse. Here’s a playbook I’ve used to describe the responsibilities of a product manager for hiring and professional development purposes.

When starting an initiative, it is important to focus on the desired outcome before jumping to solutions. A simple first step towards becoming an outcome-focused organisation is to change how you define initiatives. Many companies define initiatives in an output- or idea-centric manner, where the focus is on the specific desired scope. This can lead to confusion around why we’re actually tackling an initiative. It also limits us to only think about the suggested idea, rather than alternatives. Better and simpler ideas are often waiting to be found.