By Jessica Marquez in Requirements — Sep 17, 2026

Non-Functional Requirements - ProductFTW #97

The difference between products that work and ones that work well.

At Totavi, we work on a lot of innovative projects. Currently, the team and I are building an activation experience for a new wearable payment product and recently completed our first end-to-end test. Seeing the full flow reminded me how much of the customer experience sits outside the basic functional requirements, and that felt worth talking about here.

The core activation flow worked. I received the wearable, enabled it, and the confirmation text was sent through. I love the first end-to-end tests because they give us something we hadn’t had before: real timing data.

On paper, the first test was successful, but as a user, I noticed a delay in receiving the activation confirmation. This, of course, led to a conversation between product and engineering about timing – a conversation we have often at Totavi and even in CardsFTW.

The discussion centered on a few questions: How long is an acceptable wait? Which systems contributed to the delay? What should the user see while activation is being processed in a UI we don’t control? How would we identify the source if a future activation took longer?

The original functional requirement was straightforward: A user can activate their payment wearable.

That requirement gave us enough direction to build and test the first version. The first test gave us the data we needed to evaluate and sharpen the non-functional requirements around timing, customer communication, and system coordination. These are the kinds of requirements we don’t spend enough time talking about.

What is a non-functional requirement?

I don’t love the term non-functional requirement. It sounds like a requirement for something that doesn’t function.

Functional requirements describe the product’s capabilities. Non-functional requirements set expectations for qualities such as performance, reliability, usability, security, and operability.

The functional requirement for our activation flow explained the capability: A user can activate their payment wearable.

The related non-functional requirements describe the expected quality of the experience:

The product must reflect a successful activation within an agreed period after the activation partner confirms it.
If activation is still pending, the product must tell the user that processing is continuing.
Receiving the same activation result more than once must not create duplicate status changes or confirmation messages.
The system must record enough timing information to identify where an activation delay occurred.

Graphic comparing a functional requirement, “It works,” with a non-functional requirement, “It works well,” meaning the product is fast, clear, and dependable.

Define early, validate with real data

Non-functional requirements should be part of the conversation before development begins. Product and engineering should discuss performance, reliability, error handling, customer communication, permissions, and monitoring alongside the functional requirements.

You may not have every target in the beginning. Integrations are a good example of where you may need to start with some assumptions and then fill in the gaps as you go. In our wearable test, the partner documentation didn't describe every operational detail that would affect the customer experience, including how often updated card status would become available.

That is where testing comes in. We did not need the test to tell us that timing mattered. We needed it to show us how the connected systems behaved under normal conditions so we could replace an initial assumption with a measurable expectation.

Turning observations into requirements

The activation test highlights several different types of non-functional requirements:

What we observed	Possible requirement
Confirmation took longer than expected.	The product must reflect a successful activation within the agreed target after partner confirmation.
Two processes could report the same activation.	The system must process the activation once and send no more than one confirmation.
The customer had no clear status while waiting.	While activation is pending, the product must explain that processing is continuing.
The team needs to identify where time was spent.	Record when activation was submitted, confirmed by the partner, detected by the product, and communicated to the customer.
The mobile keyboard changed the layout during the flow.	On supported mobile browsers, opening and closing the keyboard must not make the primary action inaccessible.
OTP behavior depended on the device and browser.	Passcode fields must support autofill, paste, and logical focus order on supported devices.

The exact targets still require decisions. “Within the agreed target” wouldn't actually be in your PRD. In our case, our product and engineering discussion focused on choosing a timing that reflects customer expectations while balancing technical constraints and cost.

The happy path is a starting point

Most of our product requirements focus on the ideal sequence:

The user starts activation.
The partner platform activates the wearable.
Our product receives the updated status.
The user receives confirmation.

The complete flow has more moving parts, especially when integrating with an external partner or multiple partners.

The partner platform may make status updates available on its own schedule. Our system may also check periodically for the new status. Those updates could arrive at nearly the same time. One part of the system might know that activation is complete before another does.

The happy path tells us what needs to happen. It doesn’t tell us how quickly, reliably, or clearly it needs to happen. Looking at what happens within and between each step helps us identify the non-functional requirements that shape the customer’s experience.

What the product manager owns

Product managers don’t need to design the status-checking job or decide how to prevent two processes from updating the same record.

We do need to expose the questions hiding behind the happy path:

How long might the customer wait?
What happens if the same result arrives twice?
What does the customer see while the answer is unknown?
How will support investigate a problem?
Which assumptions can only be tested once the systems are connected?

Bring those questions to engineering and the relevant partners. Record the decisions in language the team can test.

The activation flow worked. The first end-to-end test did exactly what an early test should do: it showed us what we needed to measure and decide before putting the experience in front of customers.

We should be thinking about non-functional requirements from the start, even if some targets are still assumptions. Testing helps us confirm them and see how the whole experience comes together. Customers will never know how many systems are involved. They will simply know whether the product feels fast, clear, and dependable.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.