I’ve been quieter than usual on all the socials and in my writing because I’m deep into finishing the Effective Public Speaking book. (I’m proofing that book today.) That’s because I’m stuck between the tension of finishing this project and starting a new project. I love starting projects. Once I decide to start a project […]
In my first post, Why We Have Too Much Pressure and Planning & Too Little Delivery, I discussed the issue of too much planning and how that reduced delivery. In this post, I’ll address how to increase delivery by planning less. (I have a draft post of the system view of how too much planning reduces
I work with many teams that have extensive product backlogs. Each iteration has a backlog of more items than the team can typically finish. Worse, some organizations want many quarters’ worth of backlogs, as in the image in this post. There are several problems with long and extensive backlogs: They tend to be wishlists of
As a consultant, I create many kinds of information products: both writing and speaking. I use the ideas of experiments and finalization to decide what to ship and when. That allows me the most flexibility in my product development. However, too many organizations don’t differentiate between what they need to ship as experiments and when
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
Agile product leaders (product managers, product owners, and business analysts) all have one goal: How do I support the team in their quest to deliver better and faster? Product leaders do this by helping the team plan with minimums and continually replan. These two workshops help you do that. I offer two versions: for teams,
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