Especially when we use agile approaches, we want to be close to our customer. If you’ve ever had a chance to sit with a customer, you’ve learned how effectively (and fast!) the team and the customer learn from each other. And, too few teams have any access to any customers. Most of their customer information […]
Last August, back at the Agile 2018 conference, I had a chance to record a podcast with Howard Sublett. Howard is a terrific interviewer and a good friend and colleague. We spoke about Making Roadmaps More Agile. We had a blast. Several times, I surprised him with some of my thinking and experience. (Since I’m
Many product owners and customers believe they know the problem they want to solve. That fake certainty causes them to define solutions, instead of solving the problem at hand. John Le Drew and I pair-wrote an article describing this problem and how to solve it. See Eliminate Fake Certainty and Solve the Real Problem. Yes, I’ve
Many organizations plan to create certainty, guarantees of some variety. What if we thought about agile planning as a way to manage uncertainty? When I look at long roadmaps with all the “must-do” feature sets and the pressure managers put on teams to commit to delivery, I wonder about this question: How well do we
We, as people who create products, often have big, audacious ideas. That’s great. The problem is this: How can you make minimum, bite-size stories that the team can deliver on a frequent basis? You might need these minimums: A minimum marketable feature A minimum viable product A minimum viable experiment All of these minimums are
I was on vacation last week, thinking about value. Depending on my role, I might think of value as: Delivery of a feature or story, assuming it’s the right level of quality and when I want it. Information about the story. This might include information from the team about what they think about this story,
Let me summarize what I’ve been talking about in these posts. The problem I’m seeing is that too many teams and organizations plan too much in too much detail too soon. Instead of architectural BDUF (Big Design Up Front), it’s project planning as BDUF. They expect one single person (a product manager or a product
You’ve started thinking in feature sets. Maybe you’ve experimented with rolling wave plans inside one quarter, so you can change and replan as you need to support your project or program. You’ve discussed flow-based roadmapping as a way to create MVPs and MVEs, release smaller value more often so you can make better decisions. You
If you need to plan more often than once a quarter, how do you know how to replan? Instead of incurring the time and cost when you bring everyone together, consider the Product Value Team. (In past writing and presentations, I’ve called this the Product Owner Value Team. I am trying to change my term
One of my clients was trying—valiantly—to make their quarterly planning sessions work. They prepared, getting the big hotel room. They had plenty of supplies. The planning even went well. However, within two weeks, their plan had no relation to reality. That meant that for the next ten weeks, the product owners were “on their own.”