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
Several of my clients have internal struggles about how to internally see the future of the product. The teams want to use an agile approach so they can incorporate learning. The managers want rigid roadmaps. Why? Because the managers want to “know” the teams will deliver it all. However, the managers create a roadmap similar
I’m struggling to write several posts and I realized I need to define my terms. I keep seeing managers confuse the strategic and tactical. That leads to large and unchangeable roadmaps and a lot of emphasis on predictability. I don’t know how to offer the level of predictability they want for large and unchanging work.
I spoke with an agile coach whose team works in flow, similar to this board. They don’t use iterations—they plan on demand. The column on the left, “Stories to Workshop” is their backlog refinement column. Recently, the team decided they need “minimum” WIP (work in progress) limits. Especially on the Workshop column. Why? Their product
I’ve been working at the intersection of the project portfolio and the product roadmaps. (You can tell because of the various posts about information persistence.) Here’s what I find when I work with my clients: They have years worth of projects in the project portfolio. They have years worth of ideas in various states of description in
Many people in the agile community promote a product orientation over a project orientation. That’s possible because an organization has product or feature teams. That works until you have more products than teams. That’s when you might still need projects to accomplish everything. If you keep teams together, you can still use projects in a
In an ideal agile world, the team would work directly with a customer. When you have a small product that serves maybe three types of customer (new, expert, admin for example), and that customer is down the figurative hall, you might not need any product people. You can create short feedback loops with your customer.