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.
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?
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.
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…
Outside Reading: Product Manager vs. Product Marketing Manager
Jeremiah Owyang, a Silicon Valley Community Manager writes about the difference between product managers and product marketing managers.
Free Webinar on Strategic Product Management
Sit back and enjoy a cup of coffee while listening to a great, 30 minute, presentation by Barbara Nelson, Pragmatic Marketing instructor. Citrix is hosting a free webinar for (well, for everyone, I guess), in exchange for contact information. Barbara presents a great overview of the strategic role of product management, and Pragmatic’s framework. For people who’ve previously attended the PPM training, this is a good refresher – for other folks – if you want to know why product managers should be doing strategic work, check this out.
Inside Out is Backwards – Feature Focused or Goal Driven
Kathy Sierra has another great post on the problems people face when using products. One of the sources of the problems is when engineers think “from the inside out” and focus on features or capabilities. People have goals, and they want to achieve goals, not use capabilities.
The Impact of Change and Use Cases
Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?
Communicating A Release Schedule With Use Cases
We manage release schedules with project management. We manage customer expectations with consulting skills. How do we manage customer expectations about release schedules? With Use Cases. Background We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use […]