Forbes quoted Steve Jobs as saying “I’m as proud of what we don’t do as I am of what we do.” This is a really enlightened perspective – and a way to enforce focus from the top down. Before you can drive a “this goal is more important than that goal” focus, you have to make sure you’re actually focusing on the goals.
Continue reading Why Not What – An Example
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.
Continue reading Why Do Products Fail? – Picking the Wrong User Goals
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.
There are many reasons that a product might fail in the market. One of those reasons is that your product solves the wrong problems. There are many ways to solve the wrong problems. This article continues the series on sources of product failure, exploring the idea that your product may be trying to solve the wrong problems.
Continue reading Why Do Products Fail – Solving the Wrong Problems
The first step to comparing products is understanding your customers. This may seem counter-intuitive, but your product’s capabilities are meaningless unless you are comparing them from your customer’s point of view. This article is part 2 in a series on comparing products. Check out part 1, then continue with this article on the first steps of comparing products.
Continue reading Who Are Your Customers – Comparing Products Part 2
Recently, the gadget-reviewer crowd has caught on to something we’ve known for a long time. Comparing products is not about comparing specs, it is about comparing how well the products solve problems that customers will pay to solve. That begs the question – how should you compare products? Read on to see the product comparison technique I recommend.
Continue reading Compare Products Not Specs – Comparing Products Part 1
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.
Continue reading Agile Estimation, Prediction, and Commitment
Requirements Management – I’m embarking on a journey to help several teams manage their requirements with their existing systems and tools. This is the first in a series of articles, where the rubber meets the road. I’ll look at both the theory and the realities of what works (and doesn’t) in practice. I hope you’ll come along for the ride.
Continue reading Requirements Management Journey – Part 0
Nokia, the Finnish mobile phone manufacturer, is getting clobbered as their market rapidly moves away from them. Recent analyst reports show that Android and iOS (Apple’s platform) based phones are rapidly gaining market share. Nokia sells neither. Nokia has a major press event in a few hours, where they will announce their smartphone strategy. I think a maximin strategy is both likely and correct.
Continue reading Nokia’s Smartphone Strategy – Maximin
A lot of teams that I’ve worked on and with get hung up when thinking about defining requirements for “migration projects” and “system upgrades.” There’s some intangible barrier to being market focused when it comes to improving existing internal systems. Every new product represents a solution to an existing problem. Why do so many projects move forward with teams that are blind to the actual requirements?
Continue reading Everything Old is New Again