Epic Problem Statement

Agile, Organizations, Product Management, Product Strategy

When solving complex problems at scale, we use epics, features, and stories to align, focus, and coordinate the work of multiple teams to achieve the objectives of our organizations. 

An epic represents the investment decision to solve a tangible problem; a collection of epics together represent a broader investment decision to advance the organization’s strategy.  Most of the teams I’ve worked with in the past few years initially think about their epics in the wrong way – and once we change together how they write problem statements, it unlocks their potential to achieve great things on their own.

Continue reading Epic Problem Statement →

Motivated Reasoning and Validating Hypotheses

Uncategorized

In our continuing series on managing the risk in your backlog, we look at the risk of kidding ourselves. Specifically, we use cause and effect and hypotheses to identify the assumptions in our plans, but if we don’t do it the right way, we will lie to ourselves by validating our assumptions instead of responding to the truth when we see it.

Continue reading Motivated Reasoning and Validating Hypotheses →

Market Problem Framing Example

Business Analysis, Kano Analysis, Marketing, Prioritization, Product Management, Product Strategy, Requirements, Requirements gathering, Requirements Models

picture frames photo from Jessica Ruscello

As Steven Haines first told me, “strategy first, roadmap second.” There is a step between the two – deciding which problems you will focus on solving with your product. Strategy defines the context for product strategy, and your product roadmap is a planning (and communication) tool for executing your product strategy. Understanding how problems are framed in your market is critical to developing a successful product strategy.

Continue reading Market Problem Framing Example →

Progressively Elaborated Users

Business Analysis, Personas, Product Management, Requirements, Requirements Models, UX

partially assembled humanoid robot

Understanding your users is critical to developing good products.  A “complete” understanding is sometimes required, and always comes at a cost.  A contextualized understanding is valuable but less so, and costly but less so.  Even a shallow understanding of your users provides value by preventing some dysfunctional behaviors.  You do not always need to develop personas before developing products.

Continue reading Progressively Elaborated Users →

The Potential of Agile

Agile, Product Management, Software development

silver bullet

The pop-culture concept of a silver bullet – a simple solution to a hard problem – is a dangerous idea.  It can be used to over-promise, and doom a team to under-delivery.  When an executive, too far removed from what makes creating products hard thinks of “agile” as a silver bullet it becomes difficult to manage expectations.

Continue reading The Potential of Agile →

Agile at Scale – Outcome Driven (or Broken)

Agile, Prioritization, Product Management, Product Strategy, Project Management, Requirements, Requirements Models, Software development, User Stories

thousands of monks

Taking agile, a process otherwise optimized for small, cross-functional, collaborative teams and making it work at scale is fascinating. You have to change some elements, and retain others, as you redefine the context. Being outcome driven, is one element you must retain – or even elevate in importance, or you fundamentally break the system of delivery

Continue reading Agile at Scale – Outcome Driven (or Broken) →

Playing Whack-A-Mole With Risk

Product Management, Product Strategy

Man playing whack-a-mole carnival game

Assumptions are interesting things – we all make them all the time, and we rarely acknowledge that we’re doing it.  When it comes to developing a product strategy – or even making decisions about how best to create a product, one of these assumptions is likely to be what causes us to fail.  We can, however, reduce the chance of that happening.

Continue reading Playing Whack-A-Mole With Risk →

Outside-In User Story Example

Business Analysis, Product Management, Requirements, Requirements Models, User Stories

thumbnails in a messaging app identifying conversation members

Being “outside-in”, “outcome-based”, and “market-driven” is particularly important for creating successful products.  The problem is that just saying the words is not enough to help someone shift their thinking.  For those of us who are already thinking this way, the phrases become touchstones or short-hand.  For folks who are not there yet, these may sound like platitudes or empty words.  I know many people who want to switch their roles from “do these things” to “solve these problems.”  They have to change their organizations.  This example may help get the point across.

Continue reading Outside-In User Story Example →