Requirements

figuring out what people actually need

Learning Objectives

• Distinguish between a feature request and an underlying need.
• Conduct a short requirements conversation and extract a concrete specification.
• Prioritize a backlog using a two-axis framework.

Before

The email arrived on a Tuesday: "Hi Jess, I love the simulator but I really need to be able to add notes to my data. Can you add that?" Jess's first instinct was to open a GitHub issue titled "Add notes feature" and start thinking about the database schema. Her second instinct, shaped by a bad experience adding a feature that nobody ended up using, was to reply with five questions before writing a single line of code.

1. "What kind of notes?" The user meant short labels, not paragraphs.
2. "Are they shared with other people?" Yes, which changed everything about the implementation.
3. "Can you search for them?" No.
4. "Can you change them?" Yes, but old versions don't need to be kept.
5. "Who sees the result and what do they do with it?" The notes go into a report that goes to a regulatory agency.

The "shared" answer turned a one-afternoon feature into a two-week project with access control implications. The "regulatory agency" answer added a requirement for audit logging that the user hadn't mentioned because it hadn't occurred to them that software could provide it. Neither piece of information was in the original email.

Digging Deeper

Users describe what they want in terms of their current workflow, not in terms of what would actually solve their problem. The product manager's job is to surface the real requirement, not to implement the stated one. The key to doing this is to manage the requirements conversation:

• Ask about problems, not solutions: "What takes the most time?" not "What feature do you want?"
• Ask about frequency and severity: "How often does this happen?" and "What do you do instead?"
• Ask about the downstream decision: "Who sees this result and what do they do with it?"

Crucially, write down what they say, not what you think they should have said.

Prioritizing the Backlog

Once you have translated users' needs into features, place each one on a 2x2 grid whose axes are "impact" and "effort". This grid has four quadrants:

• Quick wins (high impact, low effort): do these first.
• Strategic investments (high impact, high effort): plan carefully.
• Fill-ins (low impact, low effort): do during slack time.
• Money pits (low impact, high effort): just don't.

The money pit is the one to watch. It is often technically interesting, which is why it keeps coming up in planning meetings, but this doesn't justify building it if few users will notice when it's done. (The sad truth is that most features are never used by most users, and that adding features makes maintenance harder for everyone who uses the features you already have [Perri2018].)

After

After the notes conversation, Jess applied the same five-question approach to the four oldest items on her backlog. Two of them turned out to address needs that users had already solved in other ways, so she could close the issues without writing code. One was a money pit: it would give her and her team a chance to play with 3D visualization, but would help less than 5% of users The fourth was a genuine quick win that she'd been avoiding because it seemed unimportant; it turned out to be the most useful thing anyone had asked for once she asked the right questions.

The LLM can simulate a user making a feature request. It cannot simulate what your actual users have tried, what workarounds they've built, or how they feel about the software they've been using for three years. The LLM conversation is useful practice; the human conversation is where you learn what actually matters.

Exercises

LLM Requirements Conversation (8 min)

Prompt the LLM like this:

Play the role of a postdoc in ecology who uses [project name] for their data analysis. You want to be able to [feature request from your real backlog]. Answer my questions about your needs in character. Don't reveal your real requirements immediately: let me ask the right questions."

Ask at least five questions before proposing anything. Stop when you can write a one-sentence requirement in the form: "When [situation], [user type] needs to [action] so that [outcome]."

Human Requirements Conversation (10 min)

Switch to a real partner. Pick a different feature request from your backlog. One person is the user, the other is the product manager.

1. (7 min) Ask five questions before proposing anything. Write the requirement sentence.

2. (3 min) Compare the two conversations. What did the real person tell you that the LLM couldn't? What did the LLM simulate well?