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,
Acme’s project portfolio team was stuck. Three months ago, they’d funded five experimental projects at $150k each. The portfolio team hoped those projects might offer the organization new customers and revenue streams. Now, the project teams reported several concerns: The technology was more complex than anyone had expected. Instead of the teams’ typical 2-4 days
Dan, a VP, knows he needs more people to get the work done. Suzanne, one of the directors, starts to hire and realizes she has several problems. First, their salary bands are too low—candidates want more money. In addition, the people want to collaborate more than the existing people seem to. She meets with Dan
The larger your product, the more likely you have components teams. I often see component teams because of the architecture of the product. In this first image, the Integrated System Program, the rest of the product uses the Platform of Common Services as components. Also, the teams find it tempting to think of the common
Does your organization have an enterprise architect or Chief Product Person? We create these positions to check that the teams don’t try to implement something “wrong.” However, a single person in this position creates bottlenecks and dependencies. (A committee might create even tighter bottlenecks.) Those dependencies slow the work. If a person delays the work,
Even when managers try to create cross-functional teams, the teams still have dependencies. Dependencies slow and make finishing the work more difficult. Too many teams have a built-in dependency creator—code review. When we take time to perform code review after we write the code (or the tests), we create dependencies between the people on the
Here’s a scenario I see in all kinds of businesses. Your team has product-focused work. And, the team also has “fast” response-required, ad hoc work: Production support, when something breaks. You need to fix this right away. Provide technical support when people have questions. The team needs to answer these questions on a “timely” basis.
You need a senior person at a meeting. The meeting is supposed to start at 2 pm. The leader strolls in at 2:15. When leaders act this way, they show their power. When I’ve asked why the person is late, they often say, “I had another meeting that ran long.” While that’s what occurred, people
You’re a leader in the organization. And you’re supposed to be at another meeting, that started 15 minutes ago. Your previous meeting ran long, so now you’re late. But the conversation you just had? That conversation prevented a bad product decision. (Or, it prevented a customer meltdown. Or something equally important.) At least, the decisions