There’s all kinds of hype every single day about AI taking the place of programmers. That reasoning infers that typing is the hard part of product development. Nothing could be further from the truth. Here are the hard parts of product development: Understanding what the customers want. Often, the customers don’t know until they see […]
I recently learned that the Hudson’s Bay Company in Canada has closed all of its retail stores. This is a big deal, because they’d been in business since 1670. But it’s an even bigger deal for risk management. That’s because the Company pioneered the use of the “Hudson’s Bay Start.” That’s where they encouraged the
I’m a huge fan of team-based collaboration to complete small stories through the architecture. (The image above shows three small stories implemented through the architecture.) More collaboration means lower WIP (Work in Progress). That lower WIP allows the team to increase their throughput (finished features) and lower cycle time (release something useful faster). (See how
This is the April 2025 Pragmatic Manager Newsletter, from Johanna Rothman. The Unsubscribe link is at the bottom of this email.Early in the agile community, people referred to the Product Owner as the “single wringable neck.” Somehow, if the product owner didn’t define the stories well, or create acceptance criteria, or even represent what someone
When I wrote Manage It!, I included an idea called a Hudson Bay Start. I wrote an article about that later, in How to Use Iteration Zero—Or Not. Hudson Bay Starts are not a new idea. However, you might not know what they are. Here’s the idea: the team chooses one item from their backlog.
When I started working on projects, we thought we could use a serial/waterfall approach to project management and product development. While we were wrong, one very good thing happened in the 1970s and 1980s: We took the time at the end of each phase to do a little retrospective. Yes, even for a serial approach,
In my work with project and program managers (see all the various titles below), I always recommend they clarify their project or program boundaries: drivers, constraints, and floats when they start the effort. But in a recent coaching call, I realized there’s another question I use a lot, especially with sponsors: When do you want
In a recent conversation, I realized that very smart and experienced project managers do not always know the difference between activity-based plans and deliverable-based plans. While activities might result in an interim or internal deliverable, activities do not result in a user-focused deliverable. The team might make some progress, but not progress users can see.
When Mark, my husband, and I moved into this house a decade ago, we faced the problem many other people face: what to keep and what to toss (or recycle, etc.). Mark had a particularly difficult time with the kitchen drawer that held all the old baby dishes and utensils. I wanted to toss everything
Susan, an experienced senior leader, wondered what to do. Her company’s market was on a roller coaster. Increased revenue meant a lot more customers, who clamored for more features. So, the product leaders pressured the teams to deliver faster. But she’d been in a roller coaster situation before. After two years of stupendous growth, revenue leveled off in just one