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.
Category Archives: Prioritization
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?
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.
Continuing the series on root causes of product failure, this article looks at the impact of focusing on the wrong user goals. Even if you have picked the right users, you may have picked the wrong goals – creating a product your customers don’t really need, or solving problems that your customers don’t care about solving.
Read the rest of the article …
Exploring the reasons that a product might fail in the market is a useful way to triage and assess what you need to do to prevent the failure of your product. Instead of taking the “do these things” approach as a prescriptive recipe for product managers, I’m approaching the exact same topic from the opposite direction. I was inspired in part to explore this approach when thinking about the Remember the Future innovation game. Instead of asking “What will the system have done?” in order to gain insights what it could be built to do, I’m asking “Why did your product fail?” in order to prevent the most likely causes of failure.
If you understand the important market problems, you can make a good product. If you understand how important each problem is, for each group of customers, you can make a great product. If you’re new to this series, go back and start at the first article, we’ll wait for you right here.
Your boss wants a commitment. You want to offer a prediction. Agile, you say, only allows you to estimate and predict – not to commit. “Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.” There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.
This is an article about agile product management and release planning.
Estimating the “value” of features is a waste of time. I was in a JAD session once where people argued about if the annoying beeping (audible on the conference line) was a smoke alarm or a fire alarm. Yes, you can get to an answer, but so what?! The important thing is to solve the problem.
Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage requirements for incremental improvement?
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements are important.