So far, I’ve addressed how a project charter can help a team start a project fast and well. That’s why the project charter must clarify product vision, the various project risks, and product risks. And, it’s equally important to know what done means. If the team does not know how little they can do to […]
In Project Charter Part 2: Clarify the Project Driver, Boundaries, and Constraints for This Project, I explained how project risks can affect the team’s approach to the work. But project risks are not the same as product risks. Product risks are about the need for product innovation. The more innovation this product needs, the more
Let me set the context for this post about the project charter: By now, the team knows what it has to accomplish because they have a product vision. The next question is: How will the team manage their risks to achieve those outcomes? That’s where I recommend a team define its project driver, up to
I have options for all kinds of work I want to do today: The creative work, which includes a wide variety of writing (articles, blog posts, and yes, more books) and more workshops Paperwork. Yes, I have accounting and all kinds of spreadsheet reconciliation. Client preparation work for when they return from their summer vacations.
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
This is Johanna Rothman’s June 2025 Pragmatic Manager newsletter. The Unsubscribe link is at the bottom of this email. All my clients are dabbling with AI. They’re using it to think about more, such as generating more features in a backlog so each person can do more. Or more code with vibe coding. Or even
This is Johanna Rothman’s May 2025 Pragmatic Manager newsletter. The Unsubscribe link is at the bottom of this email. Have you noticed that some teams seem to be more effective than others? Most of the time, they manage their WIP (Work in Progress). They learn together. Often, they collaborate across the organization. But the big
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
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
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