Requirements
Your requirements create a shared understanding of the problem being solved, what needs to be built, and how you’ll know it worked. These activities run from testing whether the problem is real, through who has it and what they’re trying to get done, to what to build first and what to measure.
Your requirements live in the repository as continuously updated docs, and the user-facing ones determine whether real people can use what you build. Before running any interview-based activity on this page, read the Mom Test cheat sheet, because it steers an interview toward what people have done rather than compliments on your idea. Then check the Shipping guide to see where your requirements work is heading.
“The hardest single part of building a software system is deciding precisely what to build.” (Fred Brooks)
OSU Advantage Accelerator’s Iterate Program
Section titled “OSU Advantage Accelerator’s Iterate Program”Attend the OSU Advantage Accelerator’s Iterate workshop to pressure-test your project idea as a venture. It’s a one-hour interactive virtual workshop covering what separates a startup from an idea, how to identify a problem worth solving, the Value Proposition Canvas, and how to pitch clearly. Sessions run periodically over Zoom; check the page for the next date and register.
Check some of the Accelerator’s other resources.
Attend as a team. The canvas and the pitch are the workshop’s artifacts, not yours: what you take away is which of your riskiest hypotheses the session changed, and the conversations with real users you scheduled as a result. Take those straight into Hypothesis Testing below, which turns each one into interviews.
A good output is the list of hypotheses the session changed, each with the user interviews you scheduled to test it.
Lean Canvas
Section titled “Lean Canvas”Complete the Lean Canvas with as much detail as you can.
Problem
List the top 1-3 problems your product or project aims to solve for your target customers.
Solution
Describe the key features or approaches that address each problem identified.
Unique Value Proposition
Summarize what makes your solution unique and why customers should choose it over alternatives.
Unfair Advantage
Identify something that cannot be easily copied or bought by competitors (e.g., insider information, unique team, patents).
Customer Segment
Define your target customers and users. Who are you creating value for?
Existing Alternatives
List current solutions or competitors your target customers use to solve these problems.
Key Metrics
Identify the key activities or numbers you will measure to track success.
High Level Concept
Describe your idea in a simple, memorable way (e.g., “YouTube for teachers”).
Channels
Explain how you will reach your customers (e.g., social media, direct sales, partnerships).
Early Adopters
Describe the characteristics of your ideal first users or customers.
Cost Structure
List the main costs required to operate your solution (e.g., development, marketing, infrastructure).
Revenue Streams
Explain how your project or product will generate revenue or value.
Something unclear? Look up explanations and some examples online.
To go further, detail each section of the canvas in a separate document.
A good output is your completed Lean Canvas with any additional information that might be useful to understand it.
Hypothesis Testing
Section titled “Hypothesis Testing”Most of the information in your Lean Canvas is hypotheses. Identify five of the riskiest hypotheses in your plan’s customer segments, problems, and competition.
For each hypothesis:
- Construct a fail/pass test.
- Interview at least five members of the relevant customer segment (enough to suggest the hypothesis holds or not) and produce anonymized data about the customer interviewed. Run the interviews with the Mom Test cheat sheet in hand: ask about past behavior, not hypothetical enthusiasm.
- Write a clear and professional summary of the results of the test (insights, etc.)
- If your initial hypothesis is false, propose a pivot hypothesis.
If working on this activity as a team, have each person focus on a different set of hypotheses. The interviewees you recruit here are the first candidates for your user access plan: the named people who will try the thing once it exists.
A good output is five riskiest hypotheses, each with its pass/fail test, anonymized data from at least five interviews, and a written result including a pivot wherever the hypothesis failed.
Jobs to Be Done Theory
Section titled “Jobs to Be Done Theory”The Jobs to Be Done (JTBD) Theory is a framework for understanding the underlying tasks or “jobs” users are trying to accomplish with your product. Instead of focusing solely on features, JTBD helps you uncover the real motivations and desired outcomes of your users.
- Identify a primary user segment for your project.
- Interview or observe users to understand what “job” they’re hiring your product to do.
- Write at least two JTBD statements in the format:
“When [situation], I want to [motivation], so I can [expected outcome] without [pain point].”
Capture your JTBD statements and a brief explanation of how these insights will influence your requirements or design decisions. Interview with the Mom Test cheat sheet in hand.
A good output is the job statement for your primary user segment, backed by what you heard in interviews or observation, and the features it reprioritizes.
Current vs. Ideal Workflow
Section titled “Current vs. Ideal Workflow”Analyzing the current workflow versus the ideal workflow helps you identify pain points, inefficiencies, and opportunities for improvement in your project’s domain.
- Document the current workflow for your target users as a step-by-step process.
- Identify bottlenecks, frustrations, or areas for improvement.
- Describe or diagram the ideal workflow that your solution aims to enable.
A good output is a comparison of the current and ideal workflows (as text or diagrams), highlighting key differences and how your project addresses the gaps.
User’s Emotional Objectives
Section titled “User’s Emotional Objectives”Look past your users’ functional goals to the emotional objectives behind them, since those shape whether people choose your software and keep using it.
- What emotions is the user seeking when using the software?
- How does the software impact their relationships or self-perception?
For example, a peer resume critique website might meet the functional goal of reviewing resumes, but the emotional objective is to ease job search anxiety. Similarly, in the auto industry, messaging focuses on emotions: a car might make someone feel wealthy or adventurous. How can your software address these emotional needs?
Write an analysis of your project from the perspective of the user emotional objectives, explaining which user segment or audience you’re targeting. Share it with your team.
A good output is a written list of the emotional objectives behind your users’ functional goals, and one design decision each one changes.
Define your Personas
Section titled “Define your Personas”Read/browse Personas: Study Guide then create 2-3 personas relevant for your project and explain how they are being used to ideate or prioritize features. Consider splitting the content of the article between team members.
Some ideas to define personas:
- What is your ideal user’s current behavior?
- What do they want to achieve?
- Define the demographic profiles, goals, and a scenario use case.
A good output is 2 to 3 personas with demographics, goals, and behaviors, plus a note on which features they caused you to prioritize or drop.
User Story Mapping
Section titled “User Story Mapping”Read the Nielsen Norman Group’s User Story Mapping article, about ten minutes, then map your project’s main user flows and write the initial epics and user stories under them. The map defines your use cases and scenarios; it grows later, so map the main flows rather than every edge case. About an hour and a half as a team.
If working on this activity as a team, have each person focus on a different set of stories. Indicate whether each user story is high or low level.
INVEST Criteria
Section titled “INVEST Criteria”When writing user stories, ensure they meet the INVEST criteria:
- Independent: Stories should be self-contained, allowing them to be developed and delivered independently.
- Negotiable: Stories aren’t contracts; they should be flexible and open to discussion.
- Valuable: Each story should deliver value to the end-user or customer.
- Estimable: Stories should be clear enough to estimate the effort/time required for implementation.
- Small: Stories should be small enough to be completed within a single iteration or sprint.
- Testable: There should be clear acceptance criteria to determine when a story is complete and meets expectations.
Optionally, run this a second time with an AI agent and set the two outputs side by side, noting where they differ, because the comparison shows what the tool changed; either version can be the one you keep.
A good output is a user story map with epics and written user stories, each marked as in or out of scope for the project.
Domain Model
Section titled “Domain Model”Create a Domain Model that represents the key entities and relationships within your project’s problem space.
- Identify Entities: List the main objects or concepts relevant to the domain (e.g., users, products, orders).
- Define Attributes: For each entity, specify key characteristics or properties (e.g., name, ID, status).
- Establish Relationships: Map how entities interact with or relate to one another (e.g., “User places Order”).
- Draw the Model: Use diagrams (UML or similar) to visualize the domain.
A good output is a diagram along with a brief explanation of the entities and their relationships.
Is / Is-Not
Section titled “Is / Is-Not”The Is / Is-Not analysis helps clarify the scope and boundaries of your project by explicitly stating what the project is and is not.
- Create a table or list with two columns: “Is” and “Is-Not”.
- In the “Is” column, list characteristics, features, or goals that are in scope for your project.
- In the “Is-Not” column, list items that are out of scope or explicitly excluded.
An explicit “Is-Not” column makes it easier to state accurately, later, what you committed to ship.
A good output is your Is / Is-Not table or list, with a short explanation of how this analysis will help keep your project focused and aligned.
Prioritization
Section titled “Prioritization”Turn your backlog of requirements or tasks into a ranked list with a reason next to each rank, so that sprint planning pulls from the top instead of re-arguing the order. Forty-five minutes as a team, then a few minutes after every project partner meeting.
- Pick one method from the guide: MoSCoW for a first pass, impact-effort or cost-value when the argument is about return on time, Eisenhower for tasks rather than features.
- Estimate before you plot: put a rough effort in hours on each item first, or the matrix becomes a vote on enthusiasm.
- Apply it to the whole backlog: every item gets a bucket or a quadrant, including the ones you’d rather not discuss.
- Check dependencies: an item is only ready when nothing above it blocks it. Move blocked items down.
- Write the reason: one line per item explaining its rank, readable by a teammate who wasn’t in the room.
A good output is your prioritized list of requirements or tasks, the method you used named, and a stated reason for each item’s rank.
Identify Success Metrics
Section titled “Identify Success Metrics”Decide what “it worked” will mean, in numbers, while you’re still far enough from the deadline that the result can’t sway you. About an hour and a half as a team, once when you first commit to what shipping will mean, and again when the deadline is close enough to check the number.
Every project commits to 2 or 3 metrics, and what makes a good one differs by project, so start with the subsection closest to yours. Product and game teams can borrow from the PMF question, AARRR, and HEART in the guide.
Four rules hold whatever you build:
- Write the metric and the decision rule together: which value is success, which is failure, and what you do in each case.
- Commit it, dated, before you measure. A metric chosen after seeing results can be picked, even unintentionally, to fit whatever the data already shows.
- Name the instrument: analytics (Plausible, Google Analytics, Hotjar), database counts, benchmark output, interviews, surveys.
- Beware vanity metrics. Downloads count people who tried it once; retention counts the people who came back. Ask what number would make your partner call it a success.
New Product or Game
Section titled “New Product or Game”Usage and retention are the point, so measure people, not code:
- Downloads or sign-ups, monthly active users, churn rate
- Average session duration, task success rate
- Net Promoter Score, positive mentions or up-votes
AARRR’s activation and retention and HEART’s task success are good first picks; ProductPlan’s metrics list has more.
Research
Section titled “Research”Your metric decides what counts as a result, so it’s a hard-to-reverse decision: change it late and every earlier run stops being comparable.
- The primary metric, and why it’s right for the question rather than easiest to compute.
- The comparison: against which baseline, on which data split, over how many runs, with which seeds.
- The decision rule: what value supports the hypothesis, what value refutes it.
- Secondary metrics you’ll report regardless of outcome, including the ones that could make you look bad.
Pair this with Reproduce Your Baseline; a metric only means something next to a number you’ve reproduced.
Your success is measured in someone else’s repository, so read what the project itself tracks:
- Patches submitted, reviewed, merged, and still merged a month later
- Review turnaround, and whether maintainers start assigning you work
- Issues closed, and whether your changes appear in a tagged release
A trivial patch merged early is a stronger signal than a large one still unmerged at the end; it proves the pipeline works.
Consultancy
Section titled “Consultancy”Your top rungs describe actions the partner takes, so measure their adoption rather than your output:
- Is it running in their environment, and whose environment is it
- How many of their people use it, and for what task
- Has it cleared their security or IT review, and when
- What would have to be true for them to call it production
Optionally, run this a second time with an AI agent and set the two outputs side by side, noting where they differ, because the comparison shows what the tool changed; either version can be the one you keep.
A good output is 2 or 3 metrics with their decision rules and a named instrumentation method for at least one, written down and dated.