My clients all have too much work to do. So they ask the product or project leaders to write a business case for each effort. The clients claim this information helps them decide which work to do and not do. However, everyone knows each business case is at least partially fiction. That’s because the writer […]
We use product roadmaps to see where we want to go and the options we might take to get there. Yet, so many of our roadmaps offer only a single and certain destination. If we don’t see options, we reduce our innovation decision points—and possibly disappoint our customers. Worse, we create products that don’t fulfill
In Part 1, I said that product roadmaps are not like car roadmaps. But even car roadmaps showed places of interest—options—for the driver and passengers. If I stretch that analogy a little, managers need to see where we are predictable for the next bit of time, and the options we see for the future. We
In Part 1, I said that customers need a different kind of roadmap than teams do. Teams need the focusing details now and a way to look forward. But, depending on where your product is in the market, your customers might want or need different information. Let’s start there. One thing to remember: you might
As I said in Part 1, teams use backlogs and roadmaps to know what’s now and what’s next. Teams use backlogs for the day-to-day tactical decisions. And when teams can see what’s next, they can keep the strategic decisions in mind. What do teams need to know about the product now to focus their work?
Several of my clients have various roadmap problems. They want a single product roadmap to serve all these purposes: Focus the team’s work for this specific product for the short term. That includes some look-ahead to see the next bit of upcoming work when the team has more capacity. Show customers where the company thinks
We often think that finishing a story from the backlog is “just” tactical. However, the more often we deliver in short feedback loops, the more often we can make strategic decisions. Finishing a story creates a new decision point, for both the product and the corporate strategy. The more often we iterate strategically, the more
Do you ever struggle with knowing if you should split stories? Or wondering if you have a valuable minimum? Jeffrey Frederick and Squirrel offered a signal for a too-small minimum in their podcast, MVP Cubed. That signal was when people became bored with the work. Let me add some additional tests: When the team can’t
The larger your product, the more likely you have components teams. I often see component teams because of the architecture of the product. In this first image, the Integrated System Program, the rest of the product uses the Platform of Common Services as components. Also, the teams find it tempting to think of the common
Continuing the series on dependencies… Maybe you don’t have the problem where the team creates internal dependencies with their process. And you don’t have to wait for someone outside the team to approve your work—an organizational process. But you do have a combination of platform/component teams and feature teams. I see this most often in