When you’re digging into what users actually need, it’s rarely something concrete and explicit. There’s the old Ford line — “if I’d asked people what they wanted, they’d have said a faster horse” — but once you get to actually building the product, you still have to land on something concrete: specific features that satisfy the underlying need. So what I mean by “requirement analysis and management” here is the whole chain: start from a surface-level ask, dig into the real need underneath it, evaluate it, land on a specific solution, and hand that off to engineers and designers to turn into an actual product. B2B and B2C products differ quite a bit in how this plays out.
Software requirements split roughly into functional and non-functional. Functional requirements are the concrete things the software needs to do — registration, rollback, and so on. Non-functional requirements cover things like stability and how well the system handles high concurrency. Requirements need priority and they need numbers attached. The important ones get built first, and they need to be quantified — you tell engineering “response time needs to be under X ms,” not “make it faster.”
1 Requirement Analysis
1.1 Who’s Involved
Users — the people who actually use the software. Clients — the people who commission the company to build it. Market analysts — people who study the market and simulate the client’s perspective. Leadership — the people issuing top-down direction.
1.2 Requirement Changes
Requirements change — because the original analysis missed something, because the client’s environment or business process shifted, or because the market moved. That’s not necessarily a bad thing: yes, it means more work, but it can also push the product forward. Two things help you handle it well. First, any change should go through a review and comparison before it gets implemented — don’t just rubber-stamp whatever the client asks for or whatever idea comes up; push back on the wilder ideas so you’re not doing pointless work. Second, when you’re writing the requirement doc in the first place, think in terms of modules and future growth, understand the business details fully, sketch out the product’s overall structure up front, and leave room to handle both the expected and the unexpected. Thinking it through early makes the later work go much more smoothly. Take a registration flow: beyond the happy path, you need to cover every failure mode and edge case — account already exists, password too weak, required field left blank, invalid format, bot protection, verification email never arrives, the link in the email doesn’t open, and so on.
1.3 Where Requirements Come From
- Leadership direction: goals handed down from the top. A PM’s job is to evaluate those goals and, once they’re confirmed, break them down and prioritize them.
- Industry knowledge: a PM needs to track where the industry is heading — new technology and new concepts bring new requirements, or clash with existing ones, and it’s on the PM to judge that using their domain knowledge. For example, the AI wave might mean your product needs new AI-related features or an upgrade to existing ones; if a competitor gets there first with some advantage and markets it heavily, that’s a real competitive threat.
- User base: requirements users raise directly, or that come out of analyzing them. A product’s users are rarely a uniform group — different roles, different cultures, different org structures produce different needs, and you have to sort through that carefully to build something that actually fits.
- Operating environment: changes in user scale, or regional infrastructure like network conditions, can force the product to adapt.
- Organizational environment: for B2B products especially, policy, company culture, workflows, and org structure often drive custom requirements.
1.4 Gathering Requirements
- Experience it yourself — sit in on the actual business work, use the product yourself.
- Workshops — bring the relevant people together, plan the discussion flow and questions ahead of time, and keep good notes.
- Ask domain experts — talk to people who own that part of the business.
- Brainstorming — one-on-one or in a group, cast a wide net, then filter down to what’s actually useful.
- Surveys — send questionnaires to users.
- Desk research — go through internal documents and data to find requirements hiding in there.
1.5 Models for Requirement Analysis
1.5.1 The Kano Model
Kano splits requirements into five tiers:
- Basic (must-be): what users consider table stakes. Missing it tanks satisfaction; adding more of it barely moves the needle.
- Performance (expected): the more you deliver, the happier users are, and vice versa.
- Excitement (delighters): features users didn’t expect. Deliver them and users are thrilled; skip them and satisfaction doesn’t drop.
- Indifferent: users barely notice either way.
- Reverse: most users actively don’t want this — give it to them anyway and they’re unhappy. (Airing a boys’-love drama on state TV would obviously backfire — and would never happen in the first place.)
When prioritizing, satisfy basic needs first, then performance needs, then delighters — and skip indifferent or reverse ones. Sometimes you’ll still build something indifferent, just to round the product out or keep a client happy. In user research, people tend to voice performance needs on their own; basic needs and delighters are the ones you have to dig out and infer yourself, because users take the former for granted and can’t imagine the latter. Over time, delighters and performance needs tend to sink down into basic needs — camera quality used to wow people; now a flagship phone with a bad camera is simply unacceptable.
1.5.2 Maslow’s Hierarchy — the Y-Model
Maslow’s hierarchy points at the deep, underlying human needs. When a user raises a request, the Y-model lets you trace it back: what goal is the user actually trying to reach by getting this? What motivation sits underneath that goal, and which level of Maslow’s hierarchy does it map to? From there you design the feature to serve that human need directly. Generally, features that map to the lower rungs of the hierarchy are more foundational and more utility-driven — think maps, food delivery apps — and those needs should be prioritized.
① is the user’s stated request — the starting point, the surface, the first layer of depth: what need, in what scenario, for what user, doing what. ② is the goal and motivation behind that request — the second layer: why is the user actually asking for this, and what’s the underlying motivation? When thinking through the user’s goal, you also have to weigh the company’s and the product’s goals. ③ is the product feature — the solution you land on after digging through the layers above, described in a way the implementation team can act on. ④ is the human need — Maslow’s need, the third and deepest layer: values, human nature itself.
The real value of the Y-model is that it won’t let you skip step ② and jump straight from ① to ③. Going deeper into the user’s actual need helps you: avoid being misled by fake requirements, resolve conflicting requirements, uncover goals you hadn’t seen, hold onto what’s constant about human nature, and find openings even in a mature, crowded market.
1.5.3 User Journey Maps
Requirements tend to come in scattered. A user journey map turns them into a story and a picture — pulling everything together to help shape a coherent experience design. Mapping out the journey step by step also makes requirements easier to spot, and layering in the user’s mood or cost at each step surfaces pain points in the product or service flow.
A user journey map needs a clearly defined user, the business scenario, the actions/mindset/emotions at each step, the touchpoints and channels (when and where the user interacts with the product or service), and the insights and ownership (what’s going wrong at a given step, and who’s responsible for it).