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?
Category Archives: Ishikawa Diagram
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.
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.
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.
You start with a point of view about what makes a minimum viable product. When your product launches, it is your customer’s point of view that matters. You must understand which problems your customers care about solving, and what solutions are available to your customers today. You need to understand your competition to make informed decisions about your product. This is the latest in a series on comparing products – jump back to the beginning of the series to catch up, we’ll wait.
Read the rest of the article …
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?
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.