Blackblot^® Product Management Expertise™

push mode (feature factory) is a viable option for companies

A quick guide to requirements, what they are, types, and who writes them.

This review outlines the types of requirements for which product management is responsible.

The general structure, timing, and nuances of writing use cases from PMTK's product management perspective

Question: "Are user stories a substitute for requirements?"

Question: "In the PMTK Product Requirements Document (PRD), section 1.4, we are requested to outline the product concept. Can you please elaborate on what is a product concept and what the difference is between a product concept and a product vision?"

Question: "How do you differentiate a capability from a feature in a product context?"

Clarity in Product Management Series: "Requirements Misconceptions"

Question: "What is the difference between product teams and product groups?"

Question: "We are examining ways to prioritize product features. What is the recommended approach in PMTK?"

Question: "Are product managers responsible for discovering valuable products?"

Question: "I think that we are in a perpetual state of scope creep with a never-ending stream of tickets. My colleagues say I am wrong. I need your help to better articulate my position."

Question: "Which discipline is more difficult, product planning or product marketing?"

There are various misconceptions regarding requirements documents, particularly the Market Requirements Document (MRD) and the Product Requirements Document (PRD).

Question: "How does a product manager manage a product?"

Question: "In the product requirements module of the Strategic Product Manager course I had attended there is a slide about the 'Chevrolet Cavalier Anti-jacking Devices'. Could you please expand and provide more information about this example?"

Question: "The PMTK includes a product requirements document. Why is this so if the PRD is not the responsibility of a product manager?"

Question: "I keep running into confusion about the 'use case' within the MRD. The problem is that my colleagues have an entirely different idea of a 'use case.' They use it as what I would describe as a design tool. They get into the details of step by step action-result, which looks to me like a work flow analysis developed by UI designers."

Question: "Writing product requirements strikes me as a product manager's responsibility as long as they stay in the problem space. Is this correct?"

Question: "I am recruiter and in the process of evaluating candidates for an open product planner position with a client (global software company). Which professional and personal skills should I be looking for in candidates for product planning positions? How can these skills be evaluated?"

Question: "We have just completed the training. How much time and effort should product planners devote to the different tasks in their role?"

Question: "My company is in the process of adopting the Blackblot format of writing MRD's and we are seeking some tangible metrics to help us verify that we are properly implementing the methodology.

Question: "We are back from the training and I need a tool or table to quickly explain to a work peer the key differences between a Product Planner and a Product Architect. Can you help?"

Question: "Quite frankly, so called product management is really all about having some good old fashioned common sense. For example, why do we need an MRD if with Agile we can just build the product as we go and suffice with a Product Backlog?"

Question: "In a separate article you listed the skills that Product Planners and Product Marketers require to be successful. What is the similar set of skills for a Product Architect?"