Skip to main content

Understanding requirements as a product manager



The worst thing you can do as a product manager to your customers is to expect them to be able to explain everything.

Let's consider this from the perspective of the consumer. You are an expert at turning their concepts into software, websites, or tangible objects. Without turning them become product managers or engineers, you are there to help them with their problem.

Let's examine this story:

We'll address him as Mr. Product Manager. Bob welcomes "Mr. Customer, Mr. Product Manager here. I'm here to simplify your situation. What do you require of me?

Mr. Client, we'll give him a call Hello, Mr. Product Manager, I need this computer to finish my daily worksheets so that I don't have to waste valuable time doing so, Bill responds.

How do these reports get finished now, Bob wonders?

Bill responds, "I use the daily scale receipts to enter the figures into this spreadsheet, which I then print."

Then Bob queries, "Those scales there? those who aren't linked to a computer?"

Bob continues, "Well, obviously, this is a hardware issue because you need those receipts to go into a database so that you can import them into your spreadsheet," with a sense of deep comprehension.

Bill, who comes out as both disappointed and dejected, approaches his IT department for the umpteenth time to try to persuade them to address this "Hardware" issue, only to find out that it is once more refused.

Except for his workflow and the implications of his data, Bill is not an expert in anything. Bob, though, offers solutions. Providers of solutions should gather all the data to see what has been debated, attempted, and rejected. Additionally, learn the reasons behind any rejections.

After further research, we learn that the request was denied by IT since the scale is a network-attached device that is already recording data in a queryable log. That was something that Bill was unaware of, thus he didn't know it. He thinks all of this technology is gibberish.

Further examination reveals that Excel is only used to construct tables that are filled out in forms that are then used to generate PDF files that are electronically attached to the billing and sales order records. If Bob truly wanted to lessen Bill's workload, he could just create a straightforward desktop executable that reads the data in accordance with straightforward criteria, fills out the report, converts it to PDF, and sends it to the other departments so they can finish the task. A large number of these applications are finished in less than a week.

What did this teach us, if anything?
  • You are an expert at comprehending the true request.
  • You are the one conducting the investigation into the real problem.
  • You serve as the departmental bridge by translating.
  • You can't just assume that the person you're speaking to is an expert in the integration you're working on. Assume you NEED to converse with more people.
  • Only what the end product must accomplish in their eyes in order for them to be content is known to your customer. Profit from that and launch your research.