Many of my clients have large “appetites”: they want to create ambitious products with many features. Even though I recommend they start small and iterate their way to that ambitious product, these (smart people) still say they want to start with “more.” They think the team needs to see this ambitious product vision to know […]
If you plan to add a feature or create a new product, there is one overall guideline that might make your efforts more useful. That is this: Know who this feature or product is for. What does that user want to do? How does your product support that user in solving their problem(s)? If you
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
Too many of my clients confuse two specific terms: rank order and prioritization. Too often, that means the team works on too many items at the same time. That leads to high WIP, low cycle time, and low throughput. So here are some visuals and an explanation. See the image labeled “Rank Order.” When we
When I started to work in 1977, we didn’t have testers. I wrote tests for my code, code reviewed with other people, and—every so often—tested other developers’ code. We missed lots of errors, both in logic and functionality. That led to a ton of product and project risks. (Yes, plenty of late and unplanned feedback
I just tried to join a virtual conference in a new-to-me distributed meeting product. It’s supposed to be “easy” and “smooth.” Not for me. I stumbled around for 15 minutes and then left, totally unsuccessful. All the participants are supposed to have avatars—but I never understood how to set mine. (I do have a Gravatar.
Several of my clients want to plan the product roadmap and then “work to the plan.” They think the roadmap is the long-term goal. But roadmaps aren’t goals. Instead, they are tactics for achieving a long-term goal. That means we need long-term goals based on both the corporate strategy and each product’s strategy. Those are two
So much of the planning I see in organizations is way overdone. Senior leaders still try to plan the project portfolio for a year. Product leaders are supposed to “commit” to year-long or longer roadmaps. And so many teams know “exactly” what they’re supposed to do for weeks, if not months at a time. We
During a sunset sail last week (see the image), I had a lovely conversation with a guy who said he did “accounting” type stuff. I asked him more, and it turns out he works for a three-letter acronym organization. No, I don’t know which one, even though I asked. He’s trying to organize a project