Product Definition¶
An editable version of the Product Definition is available here. Download a copy before continuing.
Product definition is the process of documenting the proposed solution in broad terms. The purpose of a product definition is to align expectations, formulate broad concepts, clarify roles, and establish a development timeline. In the next step, Product Specification, you will have a chance to provide more specifics. At the product definition stage, you still have considerable flexibility in how you will deliver the final solution.
Use the guidance below to complete the product definition. The product definition for this website is available here as an example.
Solution Description¶
Provide a 1-2 sentence description of the proposed solution. If you'd like, include a positioning statement:
For [User Name], who wants/needs to [statement of need or opportunity], this [product category] will [primary value proposition]. Unlike [next best alternative], this tool [primary difference].
Goal & Objectives¶
Goal¶
The goal statement should describe the desired impact of the project. It should relate to your conservation targets. It should be observable. Optionally, it can be measurable and time-limited. The goal is not "to implement the solution", the goal is what happens if the solution is implemented successfully.
Objectives¶
- Objectives describe a desired outcome for the project
- Objectives are not an outline, list of features, are set of use cases
- Try to have at least two and no more than five objectives
Users¶
Primary¶
Primary users are the subset of your boundary partners who will directly interact with the tool or solution. Think of these like your customers. You might want to group users with personas. For each primary user identified, complete the table below. If you've already completed the scoping exercise, you will have a starting point.
Provide specific examples of each user group and describe their perspective to help put yourself in their shoes.
| Problem Scenarios | Alternatives | Value Propositions |
|---|---|---|
| What is the problem, need, or job to be done? | What are they doing now? | Why is your solution better? |
Add a row to the table for each problem scenario.
Secondary¶
Secondary users don't directly use the tool or solution, but are affected by it. They may provide data inputs or make decisions from the outputs. Repeat the process you went through for primary users.
| Problem Scenarios | Alternatives | Value Propositions |
|---|---|---|
| What is the problem, need, or job to be done? | What are they doing now? | Why is your solution better? |
Uses¶
Uses describe the conditions under which the tool is used and the purpose for using the tool in that case. They should be fairly broad and together encompass the list of uses you envision for the tool or solution.
If you're familiar with user stories, you can think of a use case as an 'epic' user story. During product specification you will enumerate more specific user stories to motivate development of features. However, if it's helpful, you can frame use cases like user stories as "As user X, I want to Y so I can Z." This helps you think through each use case (Y) as specific to a user (X) who is motivated to achieve some outcome (Z).
Workflow or Product Sketch¶
Describe in general terms how the tool will integrate with existing workflows or create new workflows (be careful in creating new workflows, without sufficient motivation, it's unlikely your users will fully adopt the tool).
A journey map can be particularly effective in visualizing the users' workflow without the tool (before) and with the tool (after). Visualizing can really help you avoid pitfalls and identify necessary features. Be sure to jot down any insights you had. You can move the sketch to the back if breaks up the flow of the document too much.
Related Products¶
List any products that will integrate with, inform, or be informed by this product, especially products that produce data used by the tool, products that receive data from the tool, or products to be replaced by the tool. You'll probably have identified a few of these products in the workflow section above, here is your chance to be thorough. Add links to existing products if possible for easy reference.
Considerations¶
List design principles and constraints. Consider integration, hosting, support, adaptive management and deployment but don't get into details yet. Your client may have constraints related to software licensing, budget, etc. Listing them here will make sure you don't come back with a solution that isn't feasible.
Conditions of Satisfaction¶
Set expectations for the tool by clarifying how you will know this tool is successful.
Approach¶
Provide a general description of the proposed work plan. Discuss roles, timelines, and resources required.