At this point in the product comparison series, you know who your customers are, which problems are important to them, and which products compete to solve those problems. It’s time to score the competing products and see how the solutions your product provides (or will provide) will stack up. This […]
Ishikawa Diagram / Product Management / Product Strategy
Posted on:
Know Your Competition – Comparing Products Part 6
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 […]
Agile / Business Analysis / Prioritization / Process Improvement / Product Management / Project Management / Requirements / ROI / Software development / User Stories
Posted on:
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 […]
Kano Analysis / Product Management / Product Strategy / Requirements / Requirements Models
Posted on:
The Value of Insights
Intellectual Property. The legal jargon definition of this term has come to effectively mean “something I’ve patented, copyrighted, or hold as a trade secret.” A more general interpretation is “an idea.” For product managers, the most valuable ideas are insights.
Business Analysis / Ishikawa Diagram / Requirements / Requirements gathering / Requirements Models
Posted on:
Everything Old is New Again
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. […]
Business Analysis / Kano Analysis / Prioritization / Product Management / Requirements / Requirements Models
Posted on:
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 […]
Agile / Business Analysis / Requirements / Requirements Models / Software development / User Stories
Posted on:
Agile Documentation
Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff […]
Business Analysis / Ishikawa Diagram / Product Management / Requirements / Requirements gathering / Requirements Models
Posted on:
Provocateurs Gather the Best Requirements
Ask someone what they want, and they’ll tell you they want a faster horse. Provoke them, and they’ll tell you they have a ‘get there faster’ problem, an ‘equine waste disposal’ problem, and issues with total cost of ownership.
Agile / Business Analysis / Interaction design / Prioritization / Product Management / Requirements / Requirements Models / ROI / Software development / Usability / Use Cases / UX
Posted on:
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 […]