When building software, what is Product Definition? I've found that there's a large focus on prioritization, planning, and process (on the product management side) and design and development (on the software engineering side). But the product requirements get lost in project management software or locked away in a code base. How can we capture and preserve those requirements? Maybe the first step is to define Product Definition. Here's what I've identified so far: 1. Actors - The people using the system 2. Actions - The business processes, workflows, etc. 3. Resources - The things operated on (objects, files, etc.) 4. Rules - The policies that govern the system (conditions, access controls, etc.) Anything you'd add to this list? #productmanagement #productdefinition #productrequirements #technicalrequirements #softwareengineering
Ala Stolpnik
7mo
Tim Kleier I 100% agree that product definition needs to exist. However, I don't think there is one definition. Each person participating in the process has their own perspective on what the product is and all of them are true. A few examples: - PMs care about the customers, how the product is affecting the business and driving ROI - Designers see user experiences, user personas - QA see functionality that can be validated - Engineers see objects, actions and data flows These are just a few examples, but the secret is to be able to describe the same product to all the stakeholders from the perspective they care about. What do you think?
Product Management, data analysis, and product community organizer
7moThere is a construct used by many organizations, the "Product Requirements Document" or PRD. It can also be called the "Product Definition Document" or PDD. Such documents have fallen out of favor as artifacts of the waterfall process. And since they can be long, the ROI of creation vs. those that have read and made use of the contents in today's fluid environment is small. I'd posit that capturing and preserving the "requirements" in project management tools or codebase is poor practice and indicative of software development maturity level. I'm not a "maturity" level expert by any means though. However, there are ways to break the longer PRD elements down into bite size portions that can be captured in parallel to the design and development work. Just like an Architecture Decision Record captures the context and alternative solutions, the decision, tradeoffs considered and consequences, bite sized portions of a PRD can be captured for posterity. This way the "product team" (PM, Eng, Design) are not retreading worn paths.