“Agile” is a term that has been abused by organisations to such an extent that its original meaning is all but forgotten. Here’s a reminder of what it should mean.
All about writing and prioritising requirements: commercial, market, technical, functional, non-functional. Whatever you call them, this is the place for you
If one were to heft a half-brick down Old Street in London, there would be high probability of hitting someone currently engaged in building a minimum viable product (MVP) of some sort or another. There’s also almost as high a probability that they’re doing it wrong. Allow me to explain.
I recently read the question on the difference between the product manager and product owner on Quora and ended up sharing my opinion – at length. So I’ve decided to publish it here for posterity. Needless to say, there are other answers and other opinions, all equally valid.
Last time I published an article explaining why I thought roadmaps were a little like DVD box sets. DonorDrive product manager Kasey Marcum (@kaseymarcum) asked in the comments:
“Always enjoy your posts, Jock! I really love the high level idea of this. What does this actually look like in the wild?”
Imagine your roadmap and sprints being as engaging as a hit movie – just think how much easier they’d be to “sell” to your stakeholders and customers! Let’s see how you can do this.
Over the last few weeks I’ve mostly been investigating the variety of tools available to help product managers at different stages of their product’s lifecycle. For me, the emphasis has been on speed and ease of use because my project is short-lived and I want to show some results.
An intriguing and nonintuitive aspect of customer satisfaction is that sometimes the feature that provides the most satisfaction is one that customers didn’t know they wanted until they saw it. – Mike Cohn For how long have you been prioritising …
I was discussing recently the importance of getting a product installation or upgrade process right for customers. Here are some guiding principles from a usability perspective that you may wish to consider when defining your product’s requirements.
I strongly believe that all software companies should have a manifesto or a set of guidelines which set out in practical terms how they will ensure that their products are intuitive for the types of user for which they’re intended.
For product managers, even if your company or development team doesn’t “get” usability, you can build these into your product requirements and use your Quality Assurance team to check the requirements have been delivered.
If you want to succeed in global markets with a ‘one size fits all’ approach, you may want to reconsider that strategy. Pay as much attention, if not more, to getting the local details right.