Lawyers can teach a simple rule to product managers and marketers that will serve them well. It’s an evil sounding rule- one you might not believe at first. But bear with me.
Never Use One Word When Two Will Do.
Well, not all the time, but getting to specific meaning is very hard in most business environments.
Words are fluid and have multiple meanings. Said a fancier way, words are connotational, not denotational. That is, their meaning is tied to other meanings and context in very subtle and not-so subtle ways. Context matters, and when you capture requirements, you are removing those ideas from their living, operational context. There is no human mind in a job function, interacting with other humans, with lots of surrounding context.
For instance, in any company that does product development the meaning of the word product changes per department (merchandising, design, development, testing, sourcing, manufacturing, support) or per lifecycle stage (ideation, development, sourcing, testing, commercialization, etc) or combination of both.
Or even better, when making changes when is that product no longer that product? Some departments use form/fit/function- if it’s the same, it’s the same product. But if a purchased component would it it still be the same product if from different vendors?
Often, from a design perspective, yes. From a manufacturing and quality perspective, no.
All these departments use the word “product”, and never suffer from ambiguity or confusion in their day to day operations. Context is king, and the human mind is marvellous.
But all hell breaks lose once that context is gone, and requirements are put to paper. I’ve seen arguments rage for hours, and then repeat every few weeks, all due to ambiguity arising from this brave new paper reality.
Not convinced? Let’s look at an example using concise, well written English:
“There shall only be one product per product number. Product numbers shall not be reused”.
System is built, rolled out to designers. Or if lucky, they are brought into a requirements meeting before building the system.
“What? Are you nuts. We do 70 prototypes per final product and you are saying we can’t link them all to a final intended product number? And that we can’t change the product number to the final number?”
(BTW- this is one area where Agile methods start falling down- when slight increases in complexity tend to completely make over your domain model)
Okay. We see the problems. Let’s bring in our lawyer-mind, and revise the requirements using our new almost-evil rule:
“There shall only be one Manufactured Product per Manufacturing Product Number. Manufacturing Product Numbers shall not be reused”.
“Designers shall generate a unique Design Product Number per Design Product. There can be any number of Design Products per Manufactured Product, but only one released design. Once the Manufacturing Product is released, the design product can’t be changed without a change management process.
The new requirements make each domain object a compound term, and add time context such as “released” and control contexts such as when change control is required.
Now the problem with writing like this is that it can get carried away, and become unclear by it’s very complexity. This is where you need to match your approach to the problem you are trying to solve. Lawyers need to solve for provability in court, to the point of moving way past clarity into a unique language all it’s own. Similarly, requirements analysts need to ensure clarity, communication and the ability to be translated into specifications and features. If there is no effective communication, then the requirements can’t be validated.
The other issue to watch out for is the separation of requirements from design. Just because you call something “Manufactured Product” in requirements analysis DOESN’T mean you call it that in the software. Unlike written requirements, software introduces context back into the equation. Manufacturing is using the manufacturing tools, or only seeing the manufactured products. You can design the software to say “Product”. You just can’t analyze it that way.
PREVIOUS POST: Should You Trust a Blogless Marketer
ANOTHER POST: Do You Need Obsession-Driven Marketing?
MOST POPULAR POST (LAST 60 DAYS): Why Marketing is Becoming Like Software Development
2ND MOST POPULAR POST (LAST 60 DAYS): Is Sales Becoming Marketing Technical Support?
{ 0 comments }
