I am a QA in the IT team of a big global company. Our company expects that requirements/expectations for development and QA work/stories are written by product managers/PM and/or business analysts/BA.

Most PMs/BAs seem to set the requirements well for stories where we have to develop UI, i.e. things you can see on a screen. But, for non-UI things like APIs, they either don't provide requirements or provide superficial requirements. In their stories, they don't even mention basic scenarios which most laypersons could come up with.

For example, say that an API response has a field called timeOfEvent. Our PM defined it like this timeOfEvent = Time at which event occurred. This is not helpful for us. Even a layperson would ask us what is the format of timeOfEvent? Should it be USA date format or something else? Is that just a date or do you also want the exact time down to seconds? There are many examples of how useless our PMs generally are.

As a result, the developers and QA are forced to come up with basic requirements for the stories and lose time. The management acknowledges the problem but does not do anything concrete about it. At best, they request PMs verbally or in an email to set requirements properly. But, the PMs still continue to write stories with sparse details or sometimes even no details, leaving the rest of the team to figure out what exactly needs to be developed and what are the basic/happy path scenarios to be tested.

I feel like telling the PMs to start being useful, instead of just leaving us to do most of their work. But obviously, that is unprofessional and would result in a firing. But, polite requests to PMs have not yielded any results for a long time. So, what should I do to make PMs accountable and give us proper requirements?

  • 1
    @JoeStrazzere - yeah. Its just a rant. It won't achieve anything other than getting me into trouble.
    – RemoteGuy
    Commented Aug 30, 2019 at 15:38
  • I was going to write one of those snarky answers that would get down-voted and flagged. "Not have a heart attack, unlike when a PM actually does seem to provide adequate requirements with sufficient detail as to be useful." Because that would definitely cause me to just plain drop dead. Commented Aug 30, 2019 at 22:57
  • 1
    Right now, they have no reason to work properly, because you take care of still delivering a good product with their requirements. So either annoy them without end about the specifications, until they learn to give them immediately, or follow the specifications to the letter and produce a horrific product. In the latter case, be prepared for the backlash though.
    – Dirk
    Commented Sep 2, 2019 at 14:11
  • @Dirk - The developers are very helpful and I think that they would not support us in such a move. Usually, they write the requirements and acceptance criteria. So, it looks like the PMs will never learn.
    – RemoteGuy
    Commented Sep 4, 2019 at 4:36
  • Your examples show that the problem may be more on your end than anyone else's. A time should be stored as a time, not in a particular display format. And if someone says they want the time, why would you ask if they want a time or only a date? Anyway the solution to your problem is twofold: ask more questions, and stop thinking you know better. Build a product together. Commented Sep 4, 2019 at 18:31

5 Answers 5


Most PMs/BAs seem to set the requirements well for stories where we have to develop UI, i.e. things you can see on a screen. But, for non-UI things like APIs, they either don't provide requirements or provide superficial requirements.

I've a general observation that many non-tech people do not understand detailed nuisances of technical details. It seems to me that your PM/BAs are able to give you detailed UX flows as that is something visibly testable, but not for the tech APIs.

If so, many IT companies have increasingly started having roles for Technical Program Manager / Technical Product Managers, who are basically people with technical background working on technical products, so that they can give you specs such as the ones you mention, other details like workflow diagrams etc, and also help with making integrations etc faster when you are blocked on external teams.

If you are in a position to influence hiring decisions, that is one area where you can propose changes.

So, what should I do to make PMs accountable and give us proper requirements ?

You can try getting some of your team members involved in the requirement gathering phase itself, so that your team can collaborate with product to develop proper specs. This way, you co-develop the specs.

Get leadership buy-in here, and don't get into cycles of thinking this is their work, this is our work. While it would have been good if the PM gave good requirements at outset, by collaborating, you can minimize the friction you are having right now.

  • 2
    +1 for the last paragraph. You have a high chance of looking petty and uncooperative if you handle this by complaining that some other role isn't doing their work.
    – dwizum
    Commented Sep 4, 2019 at 15:51

So, what should I do to make PMs accountable and give us proper requirements ?

The moment you or your coworkers see an unclear requirement immediately ask for clarification.

If you see such 'timeOfEvent' field and it is unclear proceed to ask the sort of questions you wrote here (what format we want the time? should this be triggered on creation? etc.). Then when you are clear you can resume working on such feature (if feedback is not given swiftly, proceed with the things you can meanwhile).

In other words, instead of asking them (or management) to provide clearer requirements proactively ask for clarification on such requirements.

  • We ask them for requirements and generally get the information we need. But, the same lack of detail keeps getting repeated. I hoped they'd learn to frame requirements better after all our questioning. Does not need to be perfect, but at least cover the basics.
    – RemoteGuy
    Commented Aug 30, 2019 at 15:40
  • "If you see such 'timeOfEvent' field and it is unclear proceed to ask the sort of questions..." - Or ask someone who has Outlook and MAPI experience. Once you get a taste for the way Microsoft screwed up calendar events and timezones you will know exactly how to handle dates and times.
    – user25792
    Commented Sep 1, 2019 at 2:39

You have a product manager who is supposed to know what customers will pay for. And that’s what he writes in his spec.

And you realise that there needs to be more in a spec to create a product that actually works. Things that customers assume “will just work”. The product manager can’t do that. So someone needs to do it who can. Similar with graphics design. You don’t let the product manager decide that, but leave it up to a graphics designer.

Since this spec will be going to developers first, it only makes sense that one of them fills out the technical blanks in the spec before work begins (or as the first step of the work if you prefer). That person might add “timeOfEvent = time when event started, stored as seconds since epoch in GMT, displayed in the user’s time zone in the format defined by the user’s system settings”.


It may not be your best example, but your example highlights an important point.

say that an API response has a field called "timeOfEvent". Our PM defined it like this timeOfEvent = Time at which event occurred. This is not helpful for us. Should it be USA date format or something else ? Is that just a date or do you want the exact time down to seconds also ?

Now, while you may feel this specification is not precise enough, in some situations it's perfectly fine.

If you API always represents timestamps at UTC with seconds, it's a reasonable assumption that this timestamp should follow this convention. Specifying the exact format every time there is a timestamp clutters up the requirements document.

While it may be tempting to give the requirements back, and many self-righteous developers feel inclined to do so, you have to decide on an appropriate course of action weighing up the cost of making a bad assumption about unclear requirements verse the time you will wait for them to get back to you.

Let's say you assume they want USA format with seconds, it would not take you long to change this should your assumption be incorrect. So, extrapolating form requirement documents is fine, provided that you document any assumptions and raise them with the product manager at some point.

This doesn't just have to be around formats, it can be behaviour too.

If there is an unclear requirement where getting it wrong will result in a lot of wasted effort, it's perfectly fine to go back to the product manager for guidance.

If there is a lot of wasted development time, people should document it. Keep in mind, the aim of a business isn't to minimise wasted development time, it's to drive a profit.

  • Thanks. That is not my best example :) I have better examples which are more related to business logic and features which I can't share publicly.
    – RemoteGuy
    Commented Aug 30, 2019 at 15:45
  • The problem with the "timeOfEvent" isn't that it isn't verbose enough - it's that it isn't precise enough.
    – gnasher729
    Commented Aug 30, 2019 at 22:18
  • @gnasher729 Fixed. Commented Aug 31, 2019 at 2:14

Couldn't you just have a direct exchange with the emitter, live or over the phone/web. This would help focus on the desired behaviour and the edge cases.

Otherwise I feel like asking for too much detail can be a burden for both parties. I would assume that the non-technical side leave out the details for you to fill out assuming that you know what is best or what is most consistent in your codebase and I feel that this is normal to some extent.

This is why I think the live exchange would be better to showcase your need and properly document and asses the case at hand and how to modulate the exchange in order to optimise things. Notably by going over the case and explaining why some specifications are helpful and what could happen without them. But you must also expect them to not be experts about all the technical details.

  • I don't expect people to come up with edge cases and understand complicated stuff. But, if someone calls themselves a technical product manager with few years of experience in a field, then I would expect them to at least answer basic questions. The developers and qa can ask the "advanced" questions after that.
    – RemoteGuy
    Commented Aug 30, 2019 at 22:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .