The other day, I was flying to California to visit my customer. On the plane, I was seated next to a gentleman who worked for a small engineering firm in the Silicon Valley.
We quickly struck up a conversation about work and when I began to explain what I do), he got this perplexed look on his face. Seeing the confused look, I decided to try and explain in greater detail what I do as a product manager.
The gentleman quickly explained that he understood the idea of requirements but did not see how there would be enough demand for someone to do this for a living. Then he said “So, tell me what your company does that is so different from what I might do.”
I briefly began telling him about requirement work and when I got to modeling he just laughed. “How and why do you model a requirement?” he chuckled. “A requirement is just a statement that says what functions you want the software to do.
I compared Use cases to an assembly instruction for one of his mechanical devices, and an ERD to an exploded view of one of the fully assembled parts that he might design. We discussed benefits of modeling in opposition to just creating a lot of “System Shall” statements.
I summarized things this way:
Requirements Models Allow Us to Organize Our Data in Multiple Ways.
There are only so many ways to say that someone needs a log in screen. But who needs it? And why?
By placing information into models, such as context diagrams or organizational charts, we can see information from angles that we wouldn’t normally have. We can use the images to gain perspective that we wouldn’t normally have.
Models Help Us to See Things That Might Be Missing.
When you’re sitting down with someone, it’s pretty easy for them to take a first stab at telling you everything they want.
But how many times have you had someone say, “Yep, that’s it,” when you asked them if you’ve covered everything only to find out that that there were, in fact, a few pieces missing.
Putting things down on paper helps us arrange information visually so that we can see the gaps that we normally wouldn’t see in a long list of requirements.
Models Create a Visual Representation of What’s Expected.
Ever tried to describe a web page without building a wireframe?
You’ve probably discovered by now that even if you scratch out a design on piece of paper and hand it to someone it’s more effective than writing 1000 words.
Plus when you put a wireframe in front of your customer, you can get them to say, “Yep, that’s what I was looking for,” or “Nope. That’s not it.” In either case, you’re able to get their feedback on something solid before you give it to development.
As we continued talking, I saw the light go on.
Models aren’t just fancy drawings that product managers use to eat up time and paper. They are an effective and powerful tool that helps us communicate with our users and developers. Don’t get me wrong, you need to be able to write up functional specifications clearly and concisely.
But do yourself a favor. Add a few models to your toolkit.
