Last month, Mike Smart of Egress Solutions and I gave a webinar for Pragmatic Marketing on product roadmapping when working in agile environments. We had a great turnout of over 1500 people in the session – with not nearly enough time to answer all of the questions.
One attendee asked, “Please explain how a prioritized list of features is not a roadmap?”
A fantastic question, which we did not see in time to answer during the call.
Continue reading Features do not a Product Roadmap Make
We hear a lot about building products which are “good enough” or “just barely good enough.” How do we know what “good enough” means for our customers? No one really tells us.
Continue reading Good Enough
Your product roadmap is a view of what you are building right now, in the near future, and in the more distant future. Or is your roadmap a view of why you are building whatever you’re building right now, in the near future, and in the more distant future?
Your roadmap is both – but one is more important than the other – and product managers need to be able to view the roadmap both ways.
Continue reading Opposite Views of a Product Roadmap
“Agile” is something most teams do wrong*, without realizing they’re doing it wrong. A good 2×2 matrix acts as a lens, helping to convert information into insight. Let’s apply this lens to agile as applied within a company, and see if it helps people decide to do things differently.
Continue reading Agile Through a Matrix Lens
Agile is not magical. Changing from a waterfall process to an agile process changes how your team works, and helps eliminate inefficiencies. . What makes agile powerful is also makes it dangerous.
Continue reading Agile Cadabra
How can Theodore Levitt’s classic Whole Product approach help with defining a product roadmap? I’ve been revisiting his concepts and their use recently, thinking about how to revise them for some exercises I’ve been doing with product teams.
Continue reading Whole Product Game
Wrapping up the your product failed because you didn’t enable your users to realize value branch of the root causes of product failure, is this article on the context in which your user is using your product. If you ignore your user’s context, they won’t be able to realize the value you provide – or won’t be interested in solving those particular problems at that particular time.
Next up in the series on the root causes of product failure – products that fail because you have ignored the user’s level of experience. The first time someone uses your product, they don’t know anything about it. Did you design your interfaces for new users? After they’ve used it for a while, they get pretty good at using it. How much do you think they like being forced to take baby steps through a guided wizard now?
This article continues the series exploring the root causes of product failure. Even when you target the right users, and identify which of their problems are important to solve, you may still fail to solve the problems sufficiently.
Continue reading Why Do Products Fail? – Incomplete Solutions
Having an outside-in bias as a product manager is important – you need to understand how your customers (or your customer’s customers) would value capabilities you might build into your product. When running a workshop to collect that information, playing some “serious games” is a great way to get more and better information. We ran a few 20/20 Vision games last week, to great effect.
Continue reading 20/20 Vision – Innovation Game in Action