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: Requirements
Market Problems – Comparing Products Part 3
Comparing products without an understanding of the important market problems by which to compare the products is a waste of time. This is the third in a series on comparing products - jump back to the introduction if you haven’t already read the previous articles. Go ahead, we’ll wait, then come back.
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
Requirements Management Journey – Part 0
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.
Read the rest of the article …
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.
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. Why do so many projects move forward with teams that are blind to the actual requirements?
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.
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 earned a spot as one of the pillars of agile. How do you avoid over-reacting when changing a culture of over-documentation?
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.
Read the rest of the article …
A Prototype is Worth a Thousand Lines of Code
A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.
Posted in Agile, Business Analysis, Business Rules, Interaction design, Interface Design, Product Management, Requirements, Requirements gathering, Software development, UX, Uncategorized
Tagged agile interaction, Communication, process prototyping, prototypes, prototyping, uml as prototype
28 Comments
Latest Articles
Comments on all Articles
