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.
Category Archives: Prioritization
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, ROI, Requirements, Software development, User Stories
Tagged agile estimation, agile prediction, agile release planning, cone of uncertainty, project planning, release planning
100 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, ROI, Requirements, Requirements Models, Software development, UX, Usability, Use Cases
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.
Read the rest of the article …
User Goals and Corporate Goals
When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal. You need to be aware of both. Having a positive user experience is important, and requires a user-centered understanding. Achieving your corporate goals might be in conflict with some user goals.
Read the rest of the article …
Personas Make Blue Ocean Strategy Proactive
Blue Ocean Strategy provides an interesting reactive analysis of companies and markets. Personas are used to understand your customer’s needs. Combining the two provides powerful proactive insights when positioning your product for market success.
Read the rest of the article …
Product Growth Strategy
Growth is a make or break measurement for products and companies. Investment is often determined by expected value, which is based (in part) on expectations of growth. When you create a product, there are aspects of growth – how many people can use your product, and how many people do use your product. When dealing with a freemium business model, there are two elements of use - paid use and free use.
Read the rest of the article …
Posted in Business Analysis, Prioritization, Product Management, ROI, Requirements
Tagged business strategy, growth strategy, strategy
14 Comments
Dell Cell Phone Lacks Differentiation
No cell for Dell. According to Kaufman Bros. analyst Shaw Wu, carriers rejected prototypes from Dell because the “lack of differentiation.” As product managers, we know the importance of keeping up with the Joneses, but we also know the importance of including differentiated value in our product offerings.
Read the rest of the article …
Posted in Prioritization, Product Management, Requirements
Tagged cell phone, dell cell phone, dell phone, dell smart phone, kano, Kano analysis
11 Comments
Latest Articles
Comments on all Articles
