Teams often focus on perfectly implementing frameworks like OKRs or Discovery, creating a false sense of achievement. This "alibi progress" prioritizes methodology correctness over creating value in a specific context, leading to lots of outputs but no outcomes.
When handed a specific solution to build, don't just execute. Reverse-engineer the intended customer behavior and outcome. This creates an opportunity to define better success metrics, pressure-test the underlying problem, and potentially propose more effective solutions in the future.
Instead of a universal definition, "real progress" is achieved by first defining what change you want to see in your organization. You then adapt your ways of working—strategy, discovery, OKRs—to support that specific goal, rather than just following a generic playbook.
A common OKR failure is assigning teams high-level business metrics (like ARR) which they can only contribute to, not directly influence. Success requires focusing on influenceable customer behaviors while demonstrating how they correlate to the company's broader contribution-level goals.
A powerful test for a decisive strategy, borrowed from Roger Martin, is to consider its opposite. If the opposite is obviously foolish (e.g., "we will win with a terrible user interface"), your strategy isn't making a real, difficult choice and therefore lacks focus and strategic value.
When introducing a new skill like user interviews, initially focus on quantity over quality. Creating a competition for the "most interviews" helps people put in the reps needed to build muscle memory. This vanity metric should be temporary and replaced with quality-focused measures once the habit is formed.
To get buy-in from skeptical, business-focused stakeholders, avoid jargon about user needs. Instead, frame discovery as a method to protect the company's investment in the product team, ensuring you don't build things nobody uses and burn money. This aligns product work with financial prudence.
To move beyond static playbooks, treat your team's ways of working (e.g., meetings, frameworks) as a product. Define the problem they solve, for whom, and what success looks like. This approach allows for public reflection and iterative improvement based on whether the process is achieving its goal.