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: Prioritization
Posted in Interaction design, Interface Design, Ishikawa Diagram, Kano Analysis, Prioritization, Product Management, Requirements, Requirements Models, ROI, Software development, UX
Tagged Agile, elastic users, expert users, learning curves, novice users, personas, prodmgmt, user personas
67 Comments
20/20 Vision – Innovation Game in Action
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.
Posted in Interaction design, Interviews, Prioritization, Product Management, Requirements, Requirements gathering, Uncategorized, UX
Tagged 20/20 vision, agile product management, customer centric, customer experience mapping, customer journey mapping, innovation games, market driven, Prioritization, Product Management
19 Comments
Why Do Products Fail? – Picking the Wrong User Goals
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 …
Why Do Products Fail? – Picking the Wrong Users
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.
Read the rest of the article …
Important Problems – Comparing Products Part 4
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.
Agile Estimation, Prediction, and Commitment
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.
Posted in Agile, Business Analysis, Prioritization, Process Improvement, Product Management, Project Management, Requirements, ROI, Software development, User Stories
Tagged agile estimation, agile prediction, agile release planning, cone of uncertainty, project planning, release planning
104 Comments
Don’t Prioritize Features!
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.
Use Cases for Iterative Development
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?
Read the rest of the article …
Posted in Agile, Business Analysis, Interaction design, Prioritization, Product Management, Requirements, Requirements Models, ROI, Software development, Usability, Use Cases, UX
Tagged agile development, agile use cases, incremental development, iterative development, satisficing, use cases
17 Comments
Atomic 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.
Most Engaging Articles of 2009
Engagement – that’s what this whole product management blogging thing is about. Check out what Tyner Blain readers found to be the most engaging articles in 2009.
Latest Articles
Comments on all Articles
