Requirement Gathering Blunder: 3 Expensive Problems due to Over-Enthusiasm (and the Fix)

October 31, 2013 - All, Product Management

I thought it was my strength.

In my product manager / Business Analyst avatar, I have written market requirements and functional requirements for products & solutions. Here I want to share a habit which I thought was my edge. Looking back, I guess it was a weakness. Read on and make sure you are not on same trap. Also the ones responsible in your team for this job.

We know this about the requirement phase and how it fits into larger scheme:-

Individual user needs -> Market Requirement -> Product Requirements  -> software/hardware/mechanical/other requirements -> Design & development of respective tracks

My job was to meet/talk to customers and document the customer requirements. The requirements were to be taken up by larger technical team. Further, the system and software requirements were to be defined based on market requirements. As soon as customer speaks about his problem. I start thinking of feature and visualize. Not many I know of, can think of long term and big picture at the same time, at the depth I could.


The mistake part:

I understood the customer problem. I consider myself smart and technically sound to solve it. Mind races ahead to find a feature to solve it within fraction of a second. Instead of documenting customer requirement, I documented this feature as requirement. All happening subconsciously without me being aware of it.

Why was this a mistake? Didn’t I save some time and effort in collapsing the two? I saved time in unnecessary analysis. The requirements I drafted could be directly used in SCRUM product backlog.

Here was the problem:

1. There was a customer problem. Everyone in the team needed to know what customer wants. Not what I THOUGHT of what would solve customer problem.

Everyone misunderstood the problem. The difference is so subtle that everyone missed it.

2. My solution to the problem – yes, it is good. But put forth as a solution to the team for discussion. Not as customer requirement.

Not doing this kills the possibility of debate, identifying alternatives and choosing the best option.

3. The problem is very early in the cycle. It is very expensive because the product direction got set with the way problem was defined. And we all keep arguing that customers are asking for change request.

Juts thought this is a useful note before you create the product backlog and user stories. In my case, we did not have dedicated product manager role. Hence it was still justified in the context. However if you are a full time product manager, you might want to avoid the habit of skipping a step. This may happen especially if you transitioned from R&D and engineering leadership roles. In R&D, we are used to thinking too much.

Further, not detecting this leads to recurring problems.

If you a people manager, the chances are that the brightest mind in your team is into such jobs. You would trust the best guy always. So you wont ever know that there is a problem. It keeps repeating – unless there is huge problem which blows up on the face.

How to avoid this trap?

Here is what I am practicing when I wear marketing hat with no engineering responsibility:

1. Write down what exactly customer told.

2. Write what you think is good (feature) . Do this if the feature is immediately to your mind. Write this in order to get it out and clear your head. Else it will remain there and mix your thoughts with those of the customers.

3. Present both to the team. Some times having preliminary solution helps. By segregating the two, you can always ensure that your strength always remains a strength in all circumstances.

4. For the people you choose for interfacing with customers, give the right briefing. Make sure to include the above aspect for introspection.

If you avoid the small mistake I made, your product will be much better. So will be the ownership of R&D team towards requirement.

Leave a Reply