When a client asks for a capability or feature – is it a want or a need? How do we prioritize them?
Communication / Design / Prioritization / Product Management / Requirements / ROI / Software development / Usability / Writing
Posted on:
Goal Driven Upgrades
Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.
Communication / Design / Interaction design / Requirements Models / Use Cases / UX / Writing
Posted on:
Use Case Driven Documentation
Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.
Product Management / Software development / Writing
Posted on:
Goal-Driven Documentation
Why do we write documentation? Because someone told us to write it? Because our competitors have it? Or because we want our software to be easier to use? It should be the third one, but often, writing documentation is an afterthought, and it is deprioritized, and we just get it done, instead of thinking about the goals for doing it in the first place and doing it right.
Product Management
Posted on:
Follow the Product Leader
We all remember how to do it – both following and leading. Product Managers do not have corresponding authority for all of their areas of responsibility. We have to manage somehow, and what better way than follow the leader?
Slightly off-topic
Posted on:
21 Dysfunctional Definitions
Twenty-One dysnfunctional definitions of things we encounter every day as part of the software development lifecycle. Check ’em out and add to the list!
Business Analysis / Product Management / Requirements / Software requirements specification
Posted on:
Writing For The Purpose of Reading
The reason we write is so that someone can read it in the future. Duh. When we’re writing requirements documents, or documenting processes, how often do we stop and think about who will be reading our documents? We need to make sure our writing will be easy to read for our audience.
Product Management
Posted on:
Superhero Product Managers
Product managers are the leaders in organizations that lead by unfluence, adapt to changing circumstances, understand domains and markets, and communicate effectively with executives, customers, and development. They set scope, understand value, prioritize and define direction. They leap tall buildings in a single bound…
Software development / Testing
Posted on:
Rinse, Lather, Repeat – 10 Reasons to Repeat Tests
Why run a test more than once? If it passed the first time, we don’t need to run it again – or do we? James Bach provides ten good reasons to run the same test more than once.