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
The good news is most sites realize we, the users, need nudges to create strong passwords. The bad news is too many of those nudges reject strong passwords from password managers. (I use and am happy with 1Password.) Worse, too many sites still ask horrible, terrible security questions instead of asking for two-factor authentication. Your
You’re a busy product person, a Product Owner. You have information the team needs, and you want to meet. A lot. You see the need for these meetings: Standups Backlog refinement Iteration planning Strategic updates, so the team knows what’s going on. Sounds reasonable. Except, the team thinks you want to meet too often. What
Michael Mahlberg taught me something cool last week. We’re writing an article together. Part of the article is about forecasts. I was ranting and raving about how to help people see their confidence levels. He pointed me to this slideshare: Lightweight Kanban Metrics (in German). (Don’t worry about the language.) Go to slides 24, 25,